Patent Application
20120259998
1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to an improved system and method for translating network addresses.
2. Description of the Related Art
There are currently two forms of the TCP/IP networking protocol, referred to as Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6). IPv6 is designed to succeed Internet Protocol version 4 (IPv4), which is currently in widespread use across the Internet. IPv6 is also largely incompatible with IPv4, utilizing a different addressing space and connection protocol. Consequently, as illustrated in
Various IPv6 transition mechanisms have been specified to facilitate the transitioning of the Internet from its IPv4 infrastructure to the next generation addressing system of IPv6. Two such transition mechanisms are NAT64 (Network Address Translation 64) and DNS64 (Domain Name Service 64). NAT64 performs network address translation functions to allow an IPv6-only host to communicate with IPv4-only hosts. As illustrated in
For example, in
However, the above mechanisms fail if the IPv6-only client has an “IPv4 address literal”—i.e., an IPv4 address that it received via a mechanism other than a DNS lookup. By way of example, certain peer-to-peer (P2P) clients such as Bittorrent™ clients and Skype™ clients may receive IPv4 address literals from other clients in response to queries. In these cases, the clients are unable to use the IPv4 address literals if they have no IPv4 interfaces.
Several approaches have been proposed to address these problems but all are deficient on one way or another and may require changes to the NAT64/DNS64 (at a minimum) and/or changes to client operating system network stacks. For example, several proposals are described in Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix, Behavior Engineering for Hindrance Avoidance (BEHAVE) (Oct. 17, 2010). One proposal described in Section 4.3 of this document is of particular relevance to the present patent application. This section describes how an IPv6 host with an IPv4 literal may send a DNS query for an AAAA record of a Well-Known IPv4-only Fully Qualified Domain Name (FQDN). If the host receives a negative reply, then there are no DNS64 or NAT64 services on the network. If the host receives a reply, then the network must be utilizing IPv6 address synthesis. After receiving a synthesized AAAA Resource Record, the host examines the received IPv6 address and attempts to decipher the network specific prefix (NSP) used by the NAT64 and DNS64 (e.g., by “subtracting” the known IPv4 address out of synthesized IPv6 address). Once the NSP is known, the host may synthesize its own IPv6 addresses using its IPv4 addresses.
Because various different encoding techniques may be used to embed the IPv4 address within the IPv6 address, however, it may not always be possible to “subtract” out the IPv4 address to determine the NSP. Consequently, additional techniques are needed to translate IPv4 literals to IPv6 addresses for certain clients and/or server.
An apparatus and method are described for translating between IPv6 and IPv4 addresses on a computer network. For example, one embodiment of a method for generating an Internet Protocol Version 6 (IPv6) IPv6 address from an Internet Protocol Version 4 (IPv4) IPv4 address literal comprises: constructing a host name for a domain name query at a first host by combining the IPv4 address literal with a domain name of a first domain name server, the first domain name server configured to interpret the host name containing the IPv4 address literal to generate an A record including the IPv4 address; wherein the A record is usable to generate a synthetic IPv6 address, the synthetic IPv6 address including a first portion identifying a network address translation (NAT) 64 server and a second portion identifying an IPv4 host associated with the IPv4 address literal; and receiving the synthetic IPv6 address at the first host, the synthetic IPv6 address usable by the first host to connect to the IPv4 host through the NAT64 server.
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention described below. It will be apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the embodiments of the invention.
One embodiment of the invention addresses the limitations discussed above by using specially-crafted DNS queries in conjunction with a specialized DNS translation server operated by an application provider (or other third party) to allow a NAT64/DNS64 to provide synthesized mappings for any IPv4 literal addresses that may be on hand as a result of other application functions. For example, in a peer-to-peer (P2P) implementation, these literal addresses may be returned in response to a query from other clients or servers on the P2P network. It should be noted, however, that the underlying principles of the invention are not limited to a P2P implementation.
In one embodiment illustrated in
In operation, the query 172.16.254.1.nat64-discovery.example.com is initially received by the DNS64 server 202 which queries the specialized DNS translation server 201. The DNS translation server 201 responds with the A record 172.16.254.1 which the DNS64 server uses to construct a synthetic IPv6 address (an AAAA record) which it then returns to the IPv4 literal address processing logic 204 on the client 200. The client 200 may then open a connection to the remote client 220-221 or server 222 identified by the IPv4 address 172.16.254.1 through the NAT64 device 115 (i.e., identified by the synthesized IPv6 address).
The IPv4 literal address processing module 204 may be implemented in a variety of ways while still complying with the underlying principles of the invention. For example, in one embodiment, the IPv4 literal address processing module 204 comprises a component of a larger peer-to-peer (P2P) application program (e.g., such as a Bittorrent client or Skype client) or other type of application. Alternatively, or in addition, the IPv4 literal address processing module 204 may be provided as a component of an operating system executed on the client 200 (e.g., as part of the networking stack provided with the operating system). It should be noted, however, that the underlying principles of the invention are not limited to any particular implementation of the IPv4 literal address processing module 204.
Note that the query generated by the IPv4 literal address processing module 204 may result in a failure if there is no NAT64/DNS64 present. Consequently, if a failure is detected (or if a specified number of failures are detected), then no further attempts may be made. A flag may be set noting that NAT64/DNS64 is not present and that IPv4 literal addresses cannot currently be used (assuming there is no IPv4 interface available).
As discussed in the background section of the present application, it is not sufficient to attempt to extract a synthesized IPv6 prefix resulting from a single query because the exact mapping scheme cannot be determined based on a single response. For example, the mapping scheme may not be linear (in which case a simple bitwise substitution will not work) and/or multiple NAT64 devices may be in use with the DNS64 doing load balancing and/or other techniques may be in use to optimize which NAT64 is selected for a given IPv4 destination.
However, it may be possible to decipher the mapping scheme by heuristically analyzing multiple responses to IPv4 literal address queries. Consequently, in one embodiment of the invention illustrated in
One embodiment of a method for determining whether a host is within a NDS64/NAT64 environment is illustrated in
At 501, a query is generated resulting in one or more IPv4 literal addresses. By way of example, a P2P client (e.g., a Bittorrent or Skype client) may receive one or more IPv4 literals in response to a query. At 502, the IPv4 literal addresses are converted into a network name using a pre-specified coding scheme. Returning to the previous example, the network name may take the form <IPv4 address>.<server-name>.<application-provider> where <IPv4 address> is the IPv4 literal address and <server-name>.<application-provider> identifies a specialized DNS translation server. At 503, a AAAA query is issued using the network name and, at 504, the DNS64 forwards the query to the DNS translation server (e.g., identified by <server-name>.<application-provider> in one embodiment). At 505, the DNS translation server generates an A record in response to the query (e.g., <IPv4 address> in one embodiment) and at 506, the DNS64 uses the A record to synthesize an IPv6 address. At 507, the IPv6 address is transmitted to the requesting host and, at 508, the host uses the synthesized IPv6 address to open a connection through a NAT64 to the IPv4 host.
At 601 multiple test DNS queries are generated using the network names of hosts known to have IPv4 addresses but not IPv6 addresses. In one embodiment, for example, the application provider (i.e., the entity providing the client software) provides a plurality of known network names which meet this requirement (e.g., test1.nat64-discovery.example.com, test2.nat64-discovery.example.com, etc). Alternatively, various well known public host names may be used. At 602, responses to the queries are received in the form of synthetically-generated IPv6 addresses that identify a particular NAT64 or group of NAT64 devices. At 603, the responses are analyzed to determine the coding scheme used to generate the synthetic IPv6 addresses. By way of example, each IPv6 address may simply encode the IPv4 address in a specified 32-bit field of the IPv6 address and the remainder of the IPv6 address may be used to identify the NAT64 server. Alternatively, each host name may assigned a random or sequential addressing slot in the NAT64 mapping. In such a case, it may be difficult (or impossible) to determine the IPv6 coding scheme. Assuming that some form of heuristic analysis can be used to determine the coding scheme (e.g., by “subtracting” out the known IPv4 address from the IPv6 address) then, once determined, at 604, the host may synthetically generate IPv6 addresses using any IPv4 literals (e.g., as part of a P2P application or other application type).
In one embodiment, rather than transmitting a query from the DNS64 server 202 to the IPv4 DNS translator 201 as described above, the DNS64 server 202 may itself include the logic necessary for extracting the IPv4 address from the test query. Returning to the previous example, if the test query takes the form <IPv4 address>.<server-name>.<application-provider> where <IPv4 address> is the IPv4 literal and <server-name>.<application-provider> identifies a DNS translation server 201, the DNS64 server may be configured with the knowledge of this mapping scheme and may pretend to be the translation server 201 without actually making the query, thereby reducing the overall load on the DNS64 server 202 and the DNS translator server 201. Various additional modifications are contemplated to be within the scope of the underlying principles of the invention.
Any one of the methods described herein can be implemented on a variety of different data processing devices, including general purpose computer systems, special purpose computer systems, and mobile computing devices. For example, the data processing systems which may execute the methods described herein may include a desktop computer, laptop computer, tablet computer, smart phone, cellular telephone, personal digital assistant (PDA), embedded electronic device or any form of consumer electronic device.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
Embodiments of the invention may include various steps as set forth above. The steps may be embodied in machine-executable instructions which cause a general-purpose or special-purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components. Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable program code. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or other type of media/machine-readable medium suitable for storing electronic program code.
Throughout the foregoing description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. For example, it will be readily apparent to those of skill in the art that the functional modules and methods described herein may be implemented as software, hardware or any combination thereof. Moreover, although some embodiments of the invention are described herein within the context of a client P2P application, the underlying principles of the invention may be implemented in the form of a server application or any other form of client application. Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.
