Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
  • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/09—Mapping addresses
  • H04L61/25—Mapping addresses of the same type
  • H04L61/2503—Translation of Internet protocol [IP] addresses
  • H04L61/251—Translation of Internet protocol [IP] addresses between different IP versions
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/09—Mapping addresses
  • H04L61/25—Mapping addresses of the same type
  • H04L61/2503—Translation of Internet protocol [IP] addresses
  • H04L61/2592—Translation of Internet protocol [IP] addresses using tunnelling or encapsulation
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/45—Network directories; Name-to-address mapping
  • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
  • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/16—Implementing security features at a particular protocol layer
  • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Definitions

• IPV4 SYSTEM AND METHOD FOR DATA COMMUNICATION BETWEEN A FIRST INTERNET PROTOCOL VERSION (IPV4) AND A SECOND INTERNET PROTOCOL VERSION (IPV6)
• This invention relates to a system for data communication between a first Internet protocol version (IPv4) and a second Internet Protocol version (IPv6), or between the second Internet Protocol version (IPv6) and the first Internet protocol version (IPv4), which system comprises at least one first Local Area Network (LAN), which LAN communicates with at least one computer device such as a client or a server, which LAN operates according to at least one Internet Protocol version (IPv4),(IPv6), which LAN is connected to at least one gateway, which gateway communicates with the IPv4 or IPv6 Internet, which Internet communicates with a number of external computer devices such as servers or clients.
• LAN Local Area Network
• IPv4 Internet Protocol version
• IPv6 Internet Protocol version
• the pending patent application further discloses a system for data communication, which system comprises a LAN, which LAN comprises at least one client, which client performs communication to a first gateway, which gateway performs communication through an IPv4 Internet to a first tunnel server, which first tunnel server performs communication through an IPv6 Internet to a second tunnel server, which second tun- nel server performs communication through the IPv4 Internet to a second gateway, which second gateway performs communication with a server.
• This invention also relates to a method for operating a system as disclosed.
• CN102098356A discloses a method for translating an Internet protocol version 4 (IPv4) to Internet protocol version 6 (IPv6) when initiating a communication based on a cloud service on an IPv4 network.
• IPv4 Internet protocol version 4
• IPv6 Internet protocol version 6
• An information resource database and a domain name resolution server are installed in a cloud service data center.
• a stateless IPv4/IPv6 translator and an IPv6/IPv6 translator, configured through the information resource database, are installed in series.
• An address translation algorithm of the stateless IPv4/IPv6 translator is used for translating an IPv4 address reserved for accessing a pure IPv6 service from an IPv4 network into a special IPv6 address into which the IPv4 address is embedded (an operator prefix is used).
• IPv6/IPv6 translator An address translation algorithm of the IPv6/IPv6 translator is used for mapping an IPv6 address, which corresponds to a pure IPv6 information resource, into the special IPv6 address into which the IPv4 address is embedded.
• the domain name resolution server is used for returning a record A to a user in response to a domain name resolution request of the user according to the mapping relation. Therefore, an IPv4 user can then initiate access to the information resource of a pure IPv6.
• CN101227373A discloses a method for intercommunicating between IPv4 and IPv6 networks on the base of stateless mapping. The invention is characterized in that the method comprises setting a boundary router between the IPv4 and the IPv6 networks, and setting a stateless address mapping module and a packet translation module in the boundary router so as to perform the mapping between IPv4 and IPv6.
• NAT46 Network Address Translation
• ESR Extended Name Resolver
• the ENR module works as follows: (i) the IPv4 application sends type A DNS query - the IPv4 client may be configured to use the translation unit as its DNS server; (ii) the type A DNS query is routed to the ENR module, which will then send both type A and AAAA queries to the DNS system using its IPv4 interface; (iii) the DNS system may return an A and/or an AAAA record according to the server's IP version; and (iv) the ENR module decides what DNS response message will be sent to the IPv4 client, based on the network connection type towards the IPv6 Internet and the returned DNS message.
• the ENR module requests the address mapping module to create a mapped-IPv4 address for the server's IPv6 address.
• the ENR module will then return an A record that contains the mapped-IPv4 address to the IPv4 client.
• the latter will use this mapped-IPv4 address as the destination address of the server to start the communication.
• IPv6 there will be a number of IPv6 networks that are only interconnected using IPv4.
• tunnelling methods that will tunnel IPv6 over IPv4.
• Existing tunnelling methods fall into three categories: (i) 6to4 tunnels; (ii) Teredo tunnels; and (iii) configured tunnels.
• the two classes of automatic tunnels namely 6to4 and Teredo, make use of two IPv6 prefixes reserved for this purpose.
• the IPv6 addresses are computed from the IPv4 addresses and traffic between automatic tunnels and native IPv6 hosts makes use of third party relays, which are found through anycast addressing. This approach minimiz- es the amount of configuration needed on individual hosts using tunnelling, but the use of third party relays makes automatic tunnels unreliable. Users may experience slowness in their connection and sometimes some sites will be unreachable.
• Configured tunnels require explicit registration with a tunnel provider, and the users of such tunnels must configure their network to use this provider. This requires more work on the user side, but, at the same time, gives the user the advantage of maintaining control over which tunnel provider he is using, thus being able to choose a provider based on its reliability.
• configured tunnels For communications between a native IPv6 host and a host using IPv6 through a tunnel, configured tunnels have until now represented the best option. However, for communications where both endpoints are using tunnelling, 6to4 is more popular, because it is able to avoid the use of third party relays, as long as both endpoints are using 6to4.
• This invention aims at providing an effective and fast method of Network Address Translation (NAT) from IPv4 to IPv6, and vice versa, which is stateless and allows for gateway redundancy (more than one gateway in parallel in the system), thus rendering the system more reliable. Also, this invention aims at providing a method of tunnelling IPv6 packets through the IPv4 Internet. Specifically, the purpose of this invention is to provide a solution to the specific drawback from configured tunnels in case both endpoints are using a configured tunnel.
• NAT Network Address Translation
• the system further comprises an Address Server, which Address Server communicate with the gateway, which Address Server perform address mapping between the remote second Internet Protocol version (IPv6) and the first local Internet protocol version (IPv4).
• IPv6 remote second Internet Protocol version
• IPv4 Internet Protocol version
• IPv4 Internet Protocol version
• IPv6 Internet protocol version
• the system performs an automatic mapping between IPv4 Internet addresses and IPv6 Internet addresses. After such mapping has been per- formed, a highly effective communication between an old IPv4 net towards a new IPv6 net is possible. Because of lack of IPv4 addresses there is no doubt that many new computer systems will operate according to IPv6. Therefore, it is necessary that different computer systems operating at the two different Internet protocol versions can communicate without any disturbance.
• mapping is established between the two different Internets protocol versions can be transmitted both ways in a very fast manner.
• the process can be performed in a speed so that it would not delay traditional data communication.
• Even communication of digital video between IPv4 and IPv6 is possible.
• even a system starting at IPv4 can convert into a global IPv6 communication net and from here the communication is again transmitted to an IPv4 net. It is very important that the original IPv4 headers will be received at the receiving IPv4 without any change. This is performed by so to say imbedding the IPv4 address into the header of the IPv6.
• IPv4 IPv4
• IPv6 IP version 6
• the Address Server communicates through the gateway with at least one Domain Name System (DNS) translator.
• DNS Domain Name System
• IPv4 existing
• IPv6 new
• the DNS translator may con- tact the gateway, which gateway in turn may contact the Address Server, and in that way the addresses can be translated in a highly effective way before transmission.
• At least one DNS translator communicates through a gateway with at least one Address Server.
• the advantage of this embodiment is that sending communications between the Address Server and the DNS translator through the gateway simplifies the system and utilizes the mapping cache present in each gateway.
• the mapping of the first local Internet Protocol version (IPv4) addresses into the second remote Internet Protocol version (IPv6) addresses uses a subset of the second remote Internet Protocol version (IPv6) addresses available under allocated prefixes. This may be achieved by concatenating a 64 bits IPv6 prefix, 32 zero bits, and a 32 bits IPv4 address. Each component may open an IPv4 UDP port to obtain an IPv6 address. This may be achieved by concatenating a 64 bits IPv6 prefix, 16 zero bits, a 16 bits port number and a 32 bits IPv4 address. This allows the component to be addressed through IPv6 addresses regardless of its physical location.
• the component may be attached to the IPv4-only LAN or located in different facility addresses over the IPv6 backbone.
• a component on an IPv4 LAN served by gateways with multiple IPv6 prefixes assigned to it will have multiple IPv6 addresses.
• the network administrator may choose any of these IPv6 addresses to use for the component or let the system choose the preferred prefix for the given component.
• the system assigns the second Internet Protocol version (IPv6) addresses to User Datagram Protocol (UDP) ports at the LAN.
• IPv6 Internet Protocol version
• UDP User Datagram Protocol
• the advantage of this embodiment is that assigning an IPv6 address to each UDP port number allows simpler addressing of the components in the system. Also, this permits for a rapid development and deployment of IPv6 services.
• the translation disclosed by this invention allows an IPv4 LAN to connect to the IPv6 Internet backbone. Specifically, said translation facilitates communications between clients on the IPv4 LAN and servers on the IPv6 Internet, as well as between clients on the IPv6 Internet and servers on the IPv4 LAN.
• Another advantage of the translation disclosed inhere is that it translates IP addresses but not port numbers. This avoids the need for connection tracking, which makes the system more reliable and scalable.
• mapping of local addresses and remote addresses happens independently, with no explicit pairing between them - this allows individual mappings to be used by many users simultaneously, thus permitting for a more efficient usage of the pool of IPv4 addresses used for translation.
• the last 64 bits of the IPv6 address are encrypted bits, which bits are encrypted through the use of a block cipher with a 64 bits block size.
• multiple prefixes are used for the same LAN, where different encryption keys are utilized for each prefix.
• An advantage of this embodiment is that the use of multiple prefixes allows for higher reliability by using the most suitable prefix for each remote address. Moreover, the use of different keys for the different prefixes allows for a non-intrusive key rotation.
• mapping from an IPv4 address to an IPv6 address is performed to decide which local prefix is being used.
• a highly effective mapping from IPv6 to IPv4 can be achieved.
• the position in the array will provide the least significant bits of the resulting IPv4 address, and the most signifi- cant bits of the resulting IPv4 address are fixed and known from the pool which is allocated for this purpose.
• the advantage of this embodiment is that deducing the IPv4 address from the array index reduces the memory usage. Deducing the array index from the IPv4 address makes mapping from IPv4 to IPv6 simpler and faster. The re- suiting IPv4 addresses from the pool will enable a much faster communication, in case a new communication has to be started to addresses that have been previously in use.
• mappings of remote addresses are maintained in an array with one entry per available IPv4 address, wherein each array entry has an IPv6 address and a local prefix identifier, and wherein the array entries are linked to form a least recently used (LRU) list.
• LRU least recently used
• the tail of the LRU list is overwritten with the new IPv6 address and moved to the head of the LRU list, an update to the IPv4 to IPv6 mapping is performed and moved to the head of the LRU list and assigned a sequence number.
• the Address Server may send the update to all known gateways, the update consisting of an IPv6 header, an authentication header and a routing header, the IPv6 source ad- dress being the destination address from the outmost IPv6 header, the IPv6 destination address being the gateway for which the update is intended, the authentication header using a security association that is preconfigured out of band, the routing header containing instructions for the gateway on how to update the mappings.
• two 64 bit numbers specify the interval of sequence numbers covered by the update, the interval covering all updates that this gateway has not yet acknowledged, if they can fit in 1280 bytes, and otherwise as many as can fit in 1280 bytes, for each update, a 32 bits mapping index, a 128 bits IPv6 address and a 64 bits local prefix are used.
• the advantage of these embodiments is that allowing multiple updates in each update reduces the number of packets that need to be transmitted between Address Server and gateways. Limiting the packet size to 1280 bytes avoids the need for fragmentation of packets from Address Server to gateways.
• the pending patent application further discloses a system as described in the preamble to claim 11 and further modified by let the second gateway performs a communication towards the first gateway through the first and second Internet Protocol versions, which first gateway receives a reply communication, which reply communication comprises an IP address of the second gateway, which first gateway based on the received IP address at the second gateway establishes a communication tunnel between the first gateway and the second gateway.
• a very effective tunnel for data communication can be achieved.
• the system comprises a Tunnel Daemon whereby the gateway maintains a routing table with all the active automatic tunnels, which gateway informs the Tunnel Daemon about the destination addresses used.
• the advantage of this embodiment is that information from the gateway about which destination addresses are being used allows separating some of the functionalities into a separate daemon. This in turn reduces the state needed in the gateway and thereby makes the system more reliable.
• the routing table comprises entry for the destination address, which gateway use the usage counter to ensure that the Tunnel Daemon is only notified about a sample of the destination addresses.
• the Tunnel Daemon produces all the necessary IC- MPv6 echo requests and interpret the replies, which Tunnel Daemon overrides the routing decision for the gateway to be able to send probes through both paths even though the routing table in the gateway would only specify one of them.
• the advantage of this embodiment is that processing echo requests and replies in the Tunnel Daemon simplifies the gateway. Allowing the Tunnel Daemon to override routing decisions in the gateway allows the Tunnel Daemon to measure the reliability of a change before it activates that change, thereby making the system more reliable.
• the Tunnel Daemon instructs the gateway on how to update the routing table, which Tunnel Daemon decides on the tree structure used for the routing table.
• the advantage of this embodiment is that letting the Tunnel Daemon decide on the tree structure simplifies the gateway and makes the system more reliable.
• the tree structure comprises an 8 bits number at the start, which serves different purposes followed by additional fields, which depend on the 8 bits number, for leaves in the tree, the 8 bits number is zero and it is followed by an IPv6 prefix, an IPv4 address and a counter of how many packets are being routed using this leaf, for internal nodes, the 8 bits number is non-zero and it is followed by 16 pointers to other nodes, and the least significant 5 bits of the 8 bits number indicates which nibble of the IPv6 address is being branched on, which full 8 bits number is required to be increasing on the path from the root of the tree until it reaches a leaf.
• the gateway may use a loop to run down the tree and use the increasing 8-bit value as the only exit criterion. If the value did not increase when moving down a pointer, the loop must be exited. Then, the gateway may inspect the actual contents of the found node to figure out if it is a leaf and if the prefix in that leaf matches the IPv6 address it was searching for.
• the aforementioned scopes may hereby be achieved by a method operating a system as previously described, which method concerns a sequence of the following steps: a. perform communication between a first LAN operating with a first Internet Protocol version (IPv4) and a second LAN operating with a second Internet Protocol version (IPv6); b. perform an address translation of the first Internet Protocol version (IPv4) addresses and/or the second Internet Protocol version (IPv6) addresses; c. send a request from a client for an A record of a domain name to the DNS translator; d. the DNS translator encapsulates the DNS request in an IPv6 header, where next header indicates the UDP payload; e. set IPv6 source address to all zeros; f.
• IPv4 Internet Protocol version
• IPv6 Internet Protocol version
• IPv6 Internet Protocol version
• IPv6 destination address to a recursive resolver specified in the configuration of the translator; g. the DNS translator sends the IPv6 packet encapsulated in a UDP packet to the gateway's IPv4 any cast address, where a system-defined destination port is used for network analysis tools to decode the packet; h. the gateway recognizes the source addresses where it replaces all zeros with IPv6 address computed from source IPv4 and UDP port number. In an embodiment of the invention this is done by comparing each byte of the source address with zero and replace the complete address if all bytes are found to be zero.
• the tunnelling method disclosed by this invention requires the same amount of configuration as ordinary configured tunnels and works with existing tunnel providers. It sets up additional tunnels to avoid relying on the service of the tunnel providers when both endpoints are using a tunnel provider, and it does so in an automatic way, without the need for bilateral agreements between the networks.
• the pending patent application further discloses a method, which method concerns a sequence of the following steps: a. perform data communication in the form of data packets from a client by a LAN towards a first gateway; b. perform data communication in the form of data packets from the first gateway through an IPv4 Internet to a fist tunnel sever; c. perform data communication in the form of data packets from the first tunnel server to a second tunnel server through an IPv6 Internet; d. perform data communication in the form of data packets from the second tunnel server through the IPv4 Internet to the second gateway; e. perform data communication in the form of data packets from the second gateway to a server; f.
• the advantage of the tunnelling disclosed inhere is that it sets up new tunnels that work as an alternative path between the endpoints. This allows health checking of both the conventional path and the automatic tunnel, and enables the gateway to choose the most reliable path at any given time. This provides more reliable access than that achieved without automatic tunnels.
• Existing automatic tunnelling methods does in fact not have this option, as they are the only path between the endpoints, and if the automatic tunnel is unavailable, access to the IPv6 network is unavailable.
• this invention avoids the need for bilateral agreements by using 6to4 to automatically find the gateway for the target network. This is achieved by making a constructive use of the IPv4 source address header field that existing 6to4 implementations either ignore or compare with an expected value, dropping all packets when the field has an unexpected value.
• a method for communication is performed from the gateway towards one or more computer devices on the Internet, which communication comprises at least the following sequence of steps:
• gateway extracts a non-6to4 destination address from a conventional packet
• gateway sends an ICMPv6 echo request using a 6to4 source address and the non- 6to4 destination address
• the one or more computer devices reply to the ICMPv6 echo request with an IC- MPv6 echo reply;
• gateway extracts source IPv4 address from the ICMPv6 echo reply
• gateway sends encapsulated IPv6 packets to the extracted IPv4 address.
• a method for communication is performed from the gateway towards a Tunnel Daemon, which communication comprises at least the following sequence of steps:
• each local IPv6 prefix may use the same encryption key, if any, for all kinds of mappings.
• the advantage of this embodiment is that the encrypted value may be decrypted to find out which kind of mapping was used.
• FIG. l Mapping of local addresses from IPv4 to IPv6.
• FIG.2 Mapping of local addresses from IPv4 to IPv6 with encryption.
• FIG.3 Mapping of remote addresses from IPv4 to IPv6.
• FIG.4 Mapping of remote addresses from IPv6 to IPv4.
• FIG.5 Overview of the system and its components.
• FIG.6 Assignment of an IPv6 address to each UDP port on the LAN.
• FIG.7 Handling of traffic from a client on the IPv6 Internet to a server on the IPv4 LAN.
• FIG.8 Handling of packets received by the gateway.
• FIG.9 Handling of IPv4 packets received by the gateway for translation.
• FIG.10 Handling of IPv6 packets received by the gateway in UDP over IPv4 encapsulation.
• FIG.11 Handling of IPv6 packets received by the gateway.
• FIG.12 Handling of packets received by the Address Server.
• FIG.13 Handling of requests received by the DNS translator.
• FIG.14 Layout of a packet sent from the client and received at the gateway.
• FIG.15 Layout of a packet sent from the gateway and received at the Address Server.
• FIG.16 Layout of a packet sent from the Address Server and received at the gateway.
• FIG.17 Layout of a packet sent from the gateway and received at the server.
• FIG.18 Layout of a packet sent from the server and received at the gateway.
• FIG.19 Layout of a packet sent from the gateway and received at the client.
• FIG.20 Flow of packets in the tunnel setup.
• FIG.21 Tree structure used for the routing table.
• FIG.22 Flow of packets in the tunnel setup with the Tunnel Daemon.
• FIG.23 Layout of the probes from the Tunnel Daemon to the gateway.
• FIG.24 Another layout of the probes from the Tunnel Daemon to the gateway.
• FIG.1 illustrates how local addresses may be mapped from IPv4 to IPv6 through a stat- ic mapping.
• An IPv4 address (100) from the LAN (4) may be combined with a 64 bits IPv6 prefix (101) to form a 128 bits IPv6 address (102) by concatenating the 64 bits IPv6 prefix (101), 32 'zero' bits (103) and the 32 bits IPv4 address (100).
• the IPv4 address (100) is usually obtained from a packet leaving the LAN (4).
• the IPv6 prefix (101) may be part of the gateway's configuration.
• FIG.2 shows that, optionally, the last 64 bits of the IPv6 address (102) may be en- crypted bits (104), which are encrypted through the use of a block cipher with a 64 bits block size, for example.
• prefixes may be used for the same LAN. The methods for choosing between the prefixes are described later. When multiple prefixes are in use, different encryption keys may be utilized for each prefix. Note that it is possible to leave addresses on one or more prefixes unencrypted.
• Remote addresses may be mapped dynamically, as needed.
• IPv4 address (105) to an IPv6 address (106) may happen as follows (ref. FIG.3).
• the least significant bits of the IPv4 address are used as an index (107) into an array (108).
• Each array entry contains two fields: the IPv6 address (106), which will be the result of the translation, and an identification of which local prefix (109). This mapping will be used in conjunction with translation from IPv4 to IPv6.
• FIG.4 discloses mapping from an IPv6 address to an IPv4 address (110) may happen as follows. First, decide which local prefix is being used (the criteria for making this deci- sion are described later). Next, search the array for the pair of IPv6 address and local prefix. If an exact match is found, the position in the array will provide the least significant bits of the resulting IPv4 address (110). The most significant bits of the resulting IPv4 address (110) are fixed and known from the pool which was allocated for this purpose. If, for example, 10.0.0.0/8 is the pool, the most significant 8 bits (111) are known to always be the number 10 and the least significant 24 bits (112) will be the array index.
• the search in the array may be, for example, carried out by using a linear search or an auxiliary data structure.
• a new mapping may be created.
• the new mapping may overwrite an old mapping. The exact mechanism for how to create the new mapping and how to decide which old mapping to delete is described later.
• FIG.5 shows the system (2) disclosed by this invention, which introduces three new components: a gateway (6), an Address Server (16) and a Domain Name System (DNS) translator (8).
• the design allows for some of these components to be replicated. For example, one may choose to have three gateways (6), one Address Server (16) and two DNS translators (8).
• the new components (6,8, 16) will communicate through networks of IPv4 and IPv6 routers. They will communicate with each other as well as with existing clients (5), servers (14) and DNS servers (12).
• FIG.6 illustrates how some of the remaining IPv6 addresses (114) are used to assign an IPv6 address (114) to each User Datagram Protocol (UDP) port on the LAN (4) by concatenating the 64 bits IPv6 prefix (115), 16 'zero' bits (116), the 16 bit port number (117) and the 32 bits IPv4 address (113).
• UDP is a communications protocol that offers a limited amount of service when messages are exchanged between computers in a network that uses the Internet Protocol (IP).
• IP Internet Protocol
• UDP is an alternative to the Transmission Control Protocol (TCP) and, together with IP, is sometimes referred to as UDP/IP.
• TCP Transmission Control Protocol
• UDP uses the Internet Protocol to actually get a data unit (called a datagram) from one computer.
• Each component may open an IPv4 UDP port to have an IPv6 address. This allows the components to be addressed through IPv6 addresses regardless of their physical location. They may be attached to the IPv4-only LAN or may be located in a different facility accessed over the IPv6 backbone.
• a component on an IPv4 LAN served by gateways with multiple IPv6 prefixes assigned to it may have multiple IPv6 addresses. The administrator may choose any of these IPv6 addresses to use for the component or let the system choose the preferred prefix for the given component.
• FIGs.7A-D describe how traffic originating from a client on the IPv6 Internet intended for a server on the IPv4 LAN may be handled: 1. The IPv6 packet arrives at the gateway.
• the gateway compares the first 64 bits of the destination IPv6 address with the 64 bits IPv6 prefixes assigned to the network served by this gateway. 3a. If the destination IPv6 address (i.e., the prefix) is unknown, the gateway responds to the packet source with an "ICMPv6 destination unreachable" message and performs no further processing.
• the gateway will decrypt the last 64 bits of the address, if necessary - the prefix will identify which decryption key to use.
• the gateway will find bits 64-95 to be zero and the combination of destination prefix and source IPv6 address is looked up in the gateways' array of dynamic mappings.
• Step 22 If the destination prefix and the source IPv6 address combination is found, skip directly to Step 22.
• the two new headers will be an IPv6 header and an authentication header.
• the source IPv6 address is set to the IPv6 address assigned to this gateway instance.
• the destination IPv6 address is set to the IPv6 address assigned to the Address Server.
• the authentication header uses a security association that was preconfigured out of band. For example, an administrator may copy a key file to the device before traffic is routed to it.
• IPv6 packet that arrived at the gateway is included with no further modification.
• the resulting packet is processed as an incoming packet.
• the destination address is decrypted, if necessary.
• the gateway will find bits 64-79 to be zero and 80-95 to be a non-zero port number.
• the gateway prepends UDP and IPv4 headers to the IPv6 packet such that it will be tunnelled to the UDP port of the Address Server.
• the Address Server on receipt of the packet verifies its integrity using the authentication header and drops the packet if not authentic.
• the Address Server will proceed with processing and store the source address of the outer IPv6 header in a list of known gateways.
• the Address Server extracts the source address and the 64 bits prefix of the destination address from the inner IPv6 header for further processing.
• the Address Server will search for the IPv6 address and the prefix combination in the active mappings.
• LRU Least Recently Used
• the address server sends the update to all known gateways.
• the update consists of three headers, an IPv6 header, an authentication header and a routing header.
• IPv6 source address will be the destination address from the outmost IPv6 header.
• the IPv6 destination address will be the gateway for which the update is intended.
• the authentication header uses a security association that was preconfigured out of band.
• the routing header will contain instructions for the gateway on how to update the mappings.
• the entry for each update consists of a 32 bit mapping index, a 128 bit IPv6 address and a 64 bit local prefix for which the mapping is used.
• next header field of the routing header will indicate that there are no further headers in this packet.
• the address server replaces the outermost IPv6 header and authentication header of the received packet with the same three headers as above, with the following changes:
• the IPv6 destination address will be an anycast address that any of the gateways will recognize.
• the routing header will contain only the most recent update concerning this specific packet.
• next header field of the routing header will indicate that it is followed by another IPv6 header.
• a gateway When a gateway receives such a packet, the latter will be processed the same way both when addressed to the gateway itself and when addressed to the gateway's anycast address. 18. The gateway will use the authentication header to verify the integrity of the packet and drop the packet, if it is not valid. 19. The gateway will process all updates in the routing header.
• the gateway will send an acknowledgement to the Address Server indicating the lowest sequence number it has not yet seen. 21. If the next header of the routing header indicates that there is an IPv6 packet inside, this IPv6 packet is processed as an incoming packet. As the inner IPv6 packet is guaranteed to match an update from the routing header that was just processed, the packet can be processed without further communication with the Address Server. 22. The gateway will replace the IPv6 header with an IPv4 header, with fields filled in as follows:
• Total length is the payload length from the IPv6 header plus 20 bytes.
• - TTL is set to hop limit from the IPv6 header.
• Protocol is set to next header value from the IPv6 header.
• Header checksum is set to correctly match all other fields in the header.
• Source IP is set to the IPv4 mapping of the source IPv6 address.
• Destination IP is set to the lower 32 bits of the destination address or the lower 32 bits of the decrypted data, if the address was encrypted.
• the gateway updates the transport checksum to match the changes made to the pseudo header.
• TCP Transport Control Protocol
• UDP User Datagram Protocol
• the IPv4 packet reaches the server. 25.
• the server sends an IPv4 reply.
• the gateway receives the IPv4 reply and uses the lower bits of the IPv4 destination address to look up for the source IPv6 prefix and IPv6 destination address.
• the gateway uses the source IPv6 prefix to look up an encryption key.
• the gateway constructs a 64 bits word where the most significant 32 bits are 0 and the least significant 32 bits represent the source IPv4 address.
• the gateway replaces the IPv4 header with an IPv6 header.
• Payload length is computed by subtracting 20 from the total length field from the IPv4 header.
• - Hop limit is set to the TTL from the IPv4 header.
• the gateway updates the transport checksum to match the changes made to the pseudo header.
• the gateway sends the packet over the IPv6 network to the client.
• FIG.8 illustrates how the gateway may inspect a received packet to decide which of the flows FIGs.9-11 should be used for processing the packet.
• FIG.9 illustrates how the gateway translates an IPv4 packet into an IPv6 packet by looking up the destination address and the local prefix followed by an encryption of the resulting IPv6 address, if required for this prefix.
• FIG.10 illustrates how the gateway handles IPv6 over UDP over IPv4 packets by validating the addresses used in the packet and filling in addresses left empty by the sender.
• FIG.11 illustrates how the gateway handles IPv6 packets by looking up the IPv6 addresses to find out if they are known to the gateway and to decide which kind of han- dling is required for this combination of addresses including communication with the Address Server in case a packet from an unknown source needs translation.
• FIG.12 illustrates how packets are handled by the Address Server by validating the integrity of the packet and looking up the source address in the current mappings, creat- ing a new mapping, if necessary, and sending updates to the gateways.
• FIG.13 illustrates how requests are handled by the DNS translator by forwarding the request through a gateway to a DNS resolver and by translating an A request to an AAAA request and communicating with a gateway to translate the resulting AAAA reply into an A reply.
• FIGs.14-19 show how a packet modifies when transmitted from one component of the system to another.
• N indicates a new header
• C indicates a header that was copied verbatim from the previous packet
• M indicates a header that was copied with modifications.
• Checksums are underlined and length fields are italics.
• destination address 20010DB8000000000000CCCC0A000001 in the outer IPv6 header is the address of the Address Server from the gateway configuration. From this address, the gateway has extracted port number CCCC and IPv4 address 0A000001 for use in the outmost IPv4 and UDP headers.
• the MAC value in the authentication header is shown as x characters and depends on the configured security association.
• the IPv6 and TCP headers are passed unmodified.
• the sequence number ranges from 0 to 1. The interval is interpreted as a half open interval, so 0-1 means only sequence number 1 is included.
• the universally unique identifier is used to distinguish the header from other vendor specific routing headers.
• source address 0A000004 is computed by taking the most significant bits from the reserved interval starting at 0A000000 and the least significant bits from the array index 00000004.
• Destination address 0A000001 is extracted from the IPv6 destination address 20010DB800000000000000000A000001.
• TCP checksum is changed from 0570 to 6914 to reflect difference between IPv6 header and IPv4 header.
• IPv4 source address 0A000004 the least significant bits of IPv4 source address 0A000004 are extracted to get the array index 4, which is used to look up for the destination address and the local prefix to be used.
• source address 20010DB800000000000000000A000001 is constructed from: prefix 20010DB800000000, padding 00000000 and IPv4 address 0A000001.
• Traffic originating from a client (5) on the IPv4 LAN (4) intended for a server (14) on the IPv6 Internet is handled as follows: 1.
• the client (5) sends a request for an A record of a domain name to the DNS translator (8).
• the DNS translator (8) encapsulates the DNS request in an IPv6 header.
• IPv6 source address is set to all zeros (:: in standard IPv6 notation).
• IPv6 destination address is set to a recursive resolver specified in the configuration of the translator.
• the DNS translator (8) sends the IPv6 packet encapsulated in a UDP packet to the gateway's IPv4 any cast address. Destination port 3544 may be used to allow network analysis tools to decode the packet. 4. If the request is for an A record, the DNS translator (8) creates a request for an AAAA record as well.
• the gateway (6) on receipt of the packet, replaces the all zeros source address with a source address constructed from a prefix configured for this network.
• the lower 64 bits will be 16 zero bits, 16 bits port number, 32 bits IPv4 address - if an encryption key is specified for the prefix, the 64 bits are encrypted.
• the gateway (6) updates the UDP checksum to reflect the changes in the IPv6 source address.
• the gateway (6) sends the IPv6 packet over the IPv6 Internet to the DNS resolver (12). 8. The gateway (6) receives the reply from the DNS resolver (12) and recognizes the destination prefix.
• the gateway (6) extracts the IPv4 address and the port number from the destination IPv6 address.
• the gateway (6) encapsulates the packet in a UDP packet for the DNS translator (8).
• IPv6 packet was received through an IPv6 over IPv4 tunnel, an origin indica- tion header is inserted between the UDP header and the IPv6 header.
• the packet is sent to the DNS translator (8).
• the DNS translator (8) removes the origin indication header, if present, to find a reply.
• the DNS translator (8) decides if the translation is needed. 15. If the translation is not needed, the answer is sent to the client (5) without further changes. 16. If the translation is needed, the DNS translator (8) constructs an "incoming" packet that would create a mapping for the desired address. The packet will consist of two IPv6 headers and a nonce value constructed as follows:
• Source IPv6 address is the address to be translated from the AAAA reply.
• IPv6 address is set to all zeros (: : in standard IPv6 notation).
• Source IPv6 address is the IPv6 address of the DNS translator (8) itself as obtained from the destination field of the DNS reply.
• - Nonce is 64 random bytes.
• the DNS translator (8) sends the IPv6 packet over UDP to the gateway (6).
• the gateway (8) recognizes that the IPv6 source address is not the one assigned the UDP port from which the packet was received neither it is all zeros.
• the gateway (6) recognizes that the outmost destination address is empty and the innermost IPv6 header has source and destination that do match the UDP port from which the packet was received.
• the gateway (6) replaces the destination address of the outermost IPv6 header with an IPv6 address that will translate to the anycast IPv4 address of the gateway (6).
• the gateway (6) checks if the outermost IPv6 address is a local address that can be reached without translation. If the address can be reached without translation, the gateway (6) creates a response with the same structure as in Step 26, containing the local IPv4 address to be contacted.
• the gateway (6) processes the packet as an incoming packet.
• the resulting IPv4 packet will be an IPv6 in IPv4 tunnelled packet to the gateway (6) itself.
• the gateway (6) recognizes this and recognizes the destination IPv6 address.
• the gateway (6) encapsulates the IPv6 packet in a UDP packet. Since the packet appears to have arrived through a tunnel, an origin indication is included.
• the DNS translator (8) receives the packet and recognizes the nonce value.
• the DNS translator (8) extracts the IPv4 address from the origin indication. This is the translation of the IPv6 address that the DNS translator (8) copied from the AAAA reply. 29. The DNS translator (8) constructs an A reply to the client (5) using the extracted IPv4 address.
• the client (5) sends a packet to the IPv4 address.
• the gateway (6) receives the IPv4 packet, which will match the mapping obtained in Step 23.
• the packet is translated the same way as in the oncoming connection case.
• the server (14) responds 33.
• the gateway (6) receives an IPv6 packet also matching the mapping.
• the packet is translated the same way as in the oncoming connection case.
• the protocol for the DNS translator (8) to obtain the mapping from IPv6 addresses to IPv4 addresses may also be chosen among the following alternatives:
• the Address Server (16) does not know how to map local addresses, so a different protocol would be needed for local addresses.
• the gateway (6) would need to forge a source IPv4 address belonging to a host on the LAN (4). This can confuse firewalls and router filters.
• FIG.20 shows all the packets in the tunnel setup flow.
• a client (5) sends a packet (1), which reaches the gateway (6).
• the latter checks its internal routing table to find out if currently there is an automatic tunnel to the destination.
• the gateway (6) initiates two different flows (2a,2b) in parallel. Specifically, the gateway (6) will forward the packet (1) from the client (5) to the server (14) through the conventional method (ref. (2a- 10a) in FIG.20), as well as it will initiate the tunnel setup (ref. (2b- 13b) in FIG.20).
• the first packet (2b) of the tunnel setup protocol makes use of a combination of addresses, which common address selection algorithms will try to avoid, if at all possible.
• Said packet (2b) represents an ICMPv6 echo request, which uses a 6to4 address as the source address and a non-6to4 address as the destination address.
• the source address is derived from the 6to4 prefix 2002: :/16 and the IPv4 address of the gateway (6).
• the destination address is copied from the packet (1) sent from the client (5).
• the payload will be a randomly generated nonce that the gateway (6) can use to recognize the reply (7b).
• the unusual combination of addresses will allow the sending gateway (6) to identify the IPv4 address of the receiving gateway (7). It does not cause any problem to make use of this combination of addresses for the first few packets of the setup protocol, be- cause communication can proceed as indicated by steps (1-lOa) until the setup protocol completes.
• the packet (2b) can be send to the 6to4 relay (9) anycast address 192.88.99.1 as shown in the figure or to the tunnel server (11) used by this network or to both in parallel for better reliability.
• the ICMPv6 echo request (5b) reaches the server (14), the latter will send an ICMPv6 echo reply (6b) as specified by the standard RFC 2460.
• the packet (6b) will then proceed to the closest 6to4 relay (7), which in the figure is the gateway (7) for that network.
• that gateway (6) will inspect the IPv4 source address. If the IPv4 source address is 192.88.99.1, it aborts the setup protocol and keeps using the conventional path, as indicated by the steps (2a- 10a). If the IPv4 source address is different, it will use that address to continue the setup protocol. None of the existing tunnelling methods makes constructive use of this source address. Routers and firewalls may have been configured to discard the packet, if this field does not match an expected value. Literature on 6to4 bases the recommendations on how to set this value on which is least likely to cause it to get filtered.
• the gateway (6) will send a second ICMPv6 echo request (8b) to verify the usability of the automatic tunnel it is configuring.
• the ICMPv6 echo request (8b) will use the IPv4 destination address obtained from the IPv4 source address at step (7b).
• the IPv6 destination address will be the same as the previous ICMPv6 echo request (5b), which was copied from the original packet (1) from the client (5).
• the IPv6 source address will be the IPv6 address assigned to the gateway (6) chosen from the prefix assigned by the tunnel provider.
• the gateway (6) will know that the tunnel is usable. While the tunnel is usable, the gateway (6) will periodically send ICMPv6 echo requests through both the conventional tunnel and through the automatic tunnel to meas- ure round trip time and packet loss. Based on those measurements, it will decide which way payload packets should be sent through.
• the gateway (6) may use the following algorithm to reduce the routing table size.
• the gateway (6) maintains a data structure with the IPv6 addresses for which it has attempted to find a gateway IPv4 address - this is kept sorted according to the IPv6 address.
• the gate- way (6) may try to merge the two entries into a range of IPv6 addresses and an IPv4 address. In order to verify the validity of such a merge, it must repeat the probe (ref. (2b-7b) in FIG.20) with a selection of random addresses from the range. If any of the probes provide a different IPv4 address, the merging is not permitted. If a majority of the probes provide the same IPv4 address and for the remaining probes the reply (7b) was not received at all, the merge is permitted.
• FIG.21 illustrates the setup flow when the Tunnel Daemon (15) is being used (this requires 6 more packets to be sent). Note that the systems in FIG.20 and FIG.21 may be combined with that in FIG.5.
• the gateway (6) only maintains a routing table with all the active automatic tunnels. Each entry in this table will consist of an IPv6 prefix for the range covered by the entry, an IPv4 destination address and a usage counter.
• the gateway (6) will then need to inform the Tunnel Daemon (15) about destination addresses that are being used. If there is a routing table entry for the destination address, the gateway (6) will use the usage counter to ensure that the Tunnel Daemon (15) is only notified about a sample of the destination addresses - this could be one in every 256 destination addresses, for example. If there is no routing table entry for the destination address, the gateway (6) will need to inform the Tunnel Daemon (15) about every destination address or choose a sample in some other way.
• the Tunnel Daemon (15) will produce all the necessary ICMPv6 echo requests and interpret the replies.
• the Tunnel Daemon (15) will need to be able to override the rout- ing decision for the gateway (6) to be able to send probes through both paths even though the routing table in the gateway (6) would only specify one of them.
• the Tunnel Daemon needs to instruct the gateway (6) on how to update the rout- ing table.
• the Tunnel Daemon (15) will do the work to decide on the tree structure used for the routing table - a few requirements are imposed on this structure to ensure that the gateway (6) will never need to validate the full consistency of the tree structure (ref. FIG.22).
• Each node in the tree structure will have an 8-bit number at the start, which serves a few different purposes followed by additional fields, which depend on the 8-bit number. For leaves in the tree, the 8-bit number is zero and it is followed by an IPv6 prefix, an IPv4 address and a counter of how many packets are being routed using this leaf.
• the 8-bit number is non-zero and it is followed by 16 pointers to other nodes.
• the least significant 5 bits of the 8-bit number indicates which nibble of the IPv6 address is being branched on.
• the full 8-bit number is required to be increasing on the path from the root of the tree until it reaches a leaf.
• the gateway (6) may use a loop to run down the tree and use the increasing 8 -bit value as the only exit criterion. If the value did not increase when moving down a pointer, it must exit the loop. Then, it can inspect the actual contents of the found node to figure out if it is a leaf and if the prefix in that leaf matches the IPv6 address it was searching for.
• the Tunnel Daemon (15) may let all unused pointers point back to the root of the tree.
• the probes from the Tunnel Daemon (15) to the gateway (6) may look as depicted in FIG.23.
• the Destination and Message Authentication Code fields are not part of the IPv6 packet, but serve to let the gateway (6) know that the Tunnel Daemon (15) wishes to override the default routing decision and that it is authenticated to do so.
• FIG.24 shows an alternative format of the probe packets, which differ from the above in FIG.23 in the following.
• the destination address and MAC have been removed from the end of the packet. Instead, three new headers have been inserted between the existing UDP header and IPv6 header:
• the IPv4 header has the same format as in FIG.23 and is used to tunnel the payload to the gateway.
• the UDP header has the same format as in FIG.23 and is used to tunnel the payload to the gateway.
• the IPv6 header was inserted to support multiple gateways.
• the Tunnel Daemon uses the destination field of this header to indicate which of the multiple gateways the packet is intended to use.
• the source IPv6 may be that of the Tunnel Daemon.
• the use of this IPv6 header also permits inclusion of the next two headers.
• the authentication header contains a field called Integrity Check Value or Message Authentication Code. This replaces the MAC address that was shown at the end of the previous format.
• the routing header has an IPv4 address field, which replaces the Destination field that was shown at the end of the previous format.
• IPv6 and ICMPv6 headers and the nonce fields together make up the IPv6 packet that the gateway is going to forward to the Internet.
• This IPv6 packet is identical to that of the previous format.
• the gateway may verify that the IPv6 source address is identical in the two IPv6 headers.
• Gateway receives packet.
• the packet may arrive from the Internet.
• IPv4 Is packet IPv4 or IPv6? If IPv4 proceed to 804, if IPv6 proceed to 803.
• 809 Is packet ICMP echo request? If yes proceed to 810, otherwise proceed to 811.
• 810 Send ICMP echo reply
• mapping cache 902 Lookup destination IPv6 and local source prefix using lowermost bits of IPv4 destination as index into mapping cache. Construct 64 bit word from 32 zero bits and source IPv4 address. In an embodiment of the invention both the desti- nation IPv6 address and local IPv6 prefix are extracted from the mapping cache for use in the following steps.
• 903 Is local prefix encrypted? If yes proceed to 904, otherwise proceed to 905.
• 906 Is packet TCP or UDP? If yes proceed to 907, otherwise proceed to 908 907: Update transport checksum
• IPv6 handling Proceed to 1 101 in FIG. l 1. Treat as locally generated in continued processing.
• IPv6 handling Proceed to 1 101 in FIG. l 1. Treat as locally generated in continued processing.
• 1012 Does source IPv6 address match source IPv4 and UDP port? If yes proceed to 1010, otherwise proceed to 1013. In an embodiment of the invention this is verified by decrypting lowermost 64 bits if prefix is encrypted; then compare lowermost 64 bits to the concatenation of 16 zero bits, UDP port and IPv4 address.
• 1013 Is destination IPv6 : :? If yes proceed to 1014, otherwise proceed to 1018.
• 1014 Does next header indicate another IPv6 packet inside? If yes proceed to 1015, otherwise proceed to 1018.
• 1015 Does source IPv6 address of inner IPv6 packet match source IPv4 and UDP port? If yes proceed to 1016, otherwise proceed to 1018.
• 1017 Preferably replace destination address on outermost header with IPv4 address of gateway translated to an IPv6 address. Proceed to 1101 in FIG. l 1 for further processing of outermost IPv6 packet. Treat as locally generated in continued processing.
• IPv6 handling Packets reaching this point will already have been classified into one of three classes:
• Drop packet 1108 Send ICMPv6 response to source
• IPv6 packet to address server with acknowledgement of received updates. Treat as locally generated for further processing.
• a local prefix is one which is known by the gateway.
• 1117 Copy lower 64 bits.
• the lower 64 bits are the last 64 bits of the address.
• 1118 Decrypt lower 64 bits.
• the lower 64 bits are the last 64 bits of the address.
• Preferably padding consists of zeros.
• the port number may be a UDP port number.
• padding is the top 16 bits.
• 1122 Is port zero? If yes proceed to 1 126, otherwise proceed to 1123. In an embodiment of the invention this may be done by comparing the top 32 bits to zero.
• 1123 Was packet a 6in4 packet? If yes proceed to 1 124, otherwise proceed to 1125.
• 1124 Prepend IPv6 packet with origin indication
• 1125 Send packet over UDP to IP and port which was found by splitting buffer. In an embodiment of the invention this may be done by: - Encapsulate IPv6 packet in IPv4 and UDP header.
• 1126 Is source IPv6 address and destination IPv6 prefix in mapping cache? If yes, proceed to 1130, otherwise proceed to 1127.
• the gateway searches for (destination prefix, source IPv6 address) in mapping cache before making the decission.
• IPv6 source is set to gateway unicast address
• IPv6 destination is set to configured address server address
• 1129 Use gateway IPv4 address as source address for further processing.
• the index from mapping cache lookup is the lowermost bits of the IPv4 address, and the address from splitting the buffer is the bottom 32 bits of the extracted 64 bit word
• 1131 Is packet TCP or UDP? If yes, proceed to 1132, otherwise proceed to 1133.
• 1133 Is destination IPv4 address an anycast or unicast address of this gateway? If yes, proceed to 1135, otherwise proceed to 1134.
• 1202 Verify authentication header. Proceed to 1204 if packet is authentic or 1203 if not. In an embodiment of the invention, packet is authentic if SPI is known and ICV is valid according to SPI.
• Drop packet 1204 Add source address to list of known gateways. Preferably the source address of the outermost IPv6 header is copied to list of known gateways.
• Update ack info for this gateway In an embodiment of the invention the Address Server remembers a sequence for each gateway such that all updates before that sequence number are known to have been received by the gateway.
• prefix and source are copied from the second IPv6 header.
• the address server searches for (prefix,address) in existing mappings.
• the address server create an update message with:
• the Address Server send a message to the gateway consisting of:
• the Address Server send a message to the gateway consisting of:
• the message send to the gateway anycast address consists of:
• IPv6 1302 Encapsulate DNS request in UDP and IPv6 header with destination IPv6 address set to a configured resolver address. And source IPv6 address set to : : Send IPv6 packet over UDP to gateway anycast IPv4 address.
• 1303 Check if request is of type A. Proceed to 1304 on A or 1305 on any other type. 1304: Change type to AAAA and send another request
• 1309 Send unmodified reply to client. 1310: Does policy require translation for the received combination of answers? Proceed to 1311 if policy require translation or 1309 if not.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=47842988

Family Applications (1)

Country Status (1)

Cited By (6)

Citations (2)

• 2013
  • 2013-03-05 WO PCT/DK2013/050055 patent/WO2013139337A2/fr active Application Filing

Patent Citations (2)

Similar Documents

Legal Events