IPv4 to IPv6 Transition Mechanisms

Transcription

1 IPv4 to IPv6 The mechanisms for the changeover from IPv4 to IPv6 are described in RFC 4213, updating the original mechanisms described in RFC As mentioned in the notes for IP, a portion of the IPv6 address space was reserved for mapped addresses, formed by prepending ::ffff/96 to an IPv4 address. Hence any IPv4 address can be mapped to an IPv6 address. One assumption is that during the transition period hosts that have moved to IPv6 will also maintain their old IPv4 protocol stack, so that they are capable of sending and receiving both IPv4 and IPv6 packets. Above the network layer, the protocol stacks merge. TCP and UDP messages don t care whether they were carried by IPv4 or IPv6 and are unchanged between IPv4 and IPv6. The application and the transport layer have the responsibility of deciding whether to use IPv4 or IPv6 as the network layer protocol. The DNS resolver library on a host which supports IPv4 and IPv6 will search out IPv4 A records and IPv6 AAAA records 1. Where both exist, the order in which they are returned must be controllable, either by system policy or by application preference. How do the application and transport layer decide which IP version to use? The underlying principle is that a host capable of IPv6 should use it whenever it s possible and not grossly inefificient. If only an IPv4 A record is found, then the resolver will return it either as an IPv4 address or in the form of a mapped IPv6 address (again, policy). This will be recognised by the application and transport layer as an indication that IPv4 should be used. If only an IPv6 record is returned, and the address is not of the mapped form, then IPv6 must be used for communication. Tunnelling is another important mechanism for the IPv4 to IPv6 transition. It is expected that it will often be necessary to transmit IPv6 packets using the existing IPv4 infrastructure. To do this, an IPv6 packet is encapsulated as data in an IPv4 packet. Some terminology will make it easier to describe how this is done. 1 A6 records, defined in RFC 2874, were the replacement for AAAA records, which were deprecated, but as of RFC 3363 the tables have turned. AAAA records are back in favour and A6 records are deprecated. 1 July, 2014

2 The host or router implementing the near end of the tunnel is called the encapsulating node; the host or router implementing the far end is the decapsulating node. Rather than typing the interface configured as the encapsulating end of a tunnel, or the interface configured as the decapsulating end of a tunnel, we ll use the tunnel interface. The appropriate end (near or far) is generally clear in context. Most often, a tunnel interface is implemented as a pseudo-interface, i.e., a data structure with tunnel configuration instructions, mapped onto a physical interface. In general, it s not possible to automatically determine the address of the far end of a tunnel. This information must be supplied as part of the tunnel interface configuration at the encapsulating node. This is called (naturally enough) configured tunnelling. In contrast, RFC 2893 described a second type of tunnel, an automatic tunnel, which used the IPv4 address imbedded in a compatible IPv6 address to determine the far end point of the tunnel. Automatic tunnels have been deprecated (replaced by the 6to4 scheme described below). Since this was the only use for compatible addresses, they, too, became obsolete. Configured tunnelling can be used to tunnel an IPv6 packet from an isolated IPv6 host to a router at the edge of an IPv6 routing domain. It can also be used between IPv6 routers, when it s necessary to cross from one IPv6 island to another using the IPv4 infrastructure. A tunnel is inherently unidirectional, with one end encapsulating and the other decapsulating. A tunnel from Router A to Router B may use a different set of interfaces than a tunnel from Router B to Router A. In turn, packets going one direction may follow a different route than packets flowing in the other direction. Clearly, each tunnel interface must have a routable IPv4 address. These will be used as the source and destination addresses of the encapsulating IPv4 packet. There are interesting issues involving fragmentation and error messages. Consult RFC 4213 for additional details. Configured tunnels are used for other purposes in both IPv4 and IPv6. Virtual private networks (VPNs) are one example of configured tunnels. 2 July, 2014

3 The current scheme for tunnelling IPv6 packets through IPv4 infrastructure is called 6to4 and is described in RFC 3056 (augmented by RFC 3068). Calling 6to4 tunnelling stretches the notion of tunnel, because what actually happens is that the IPv6 packet is encapsulated in an IPv4 packet and then routed according to the IPv4 portion of a mapped IPv6 address. There is no unique pair of ends for the tunnel. 6to4 is intended to apply to an IPv6 site on a site-wide basis and requires only a single valid IPv4 address. A 6to4 router sits between an IPv6 routing domain and the IPv4 infrastructure. The IPv4 address is required for the IPv4 interface of the 6to4 router. IPv6 addresses used by the 6to4 scheme are formed by using an IPv4 address to form the global routing prefix portion of the IPv6 address. Specifically, if ip.v4.ad.dr is the IPv4 address, then the routing prefix is 2002:ip.v4.ad.dr::/48. Because the IPv4 address is guaranteed globally unique, the routing prefix is globally unique. Because the 6to4 prefix is a /48 prefix, it s compatible with the recommended standard practice of allocating /48 routing prefixes to edge networks. Each host within the site acquires a new IPv6 address (the 6to4 address) constructed using the 6to4 routing prefix. Hosts locate a 6to4 router by standard IP routing rules. Specifically, the 6to4 router advertises the prefix 2002::/16 using the interior routing protocol for the site 2. Destinations with a prefix 2002:dst.v4.ad.dr::/48, where dst.v4.ad.dr is not an address within the local site, are steered to the 6to4 router, where they are encapsulated and submitted to the IPv4 infrastructure with a destination address of dst.v4.ad.dr. The standard IPv4 routing infrastructure will now deliver the encapsulated packet to the 6to4 router at the destination site (which has an interface bound to the IPv4 address dst.v4.ad.dr). On delivery to the destination s site, their 6to4 router decapsulates and submits the packet to the destination site s IPv6 infrastructure. Figure 1 illustrates the 6to4 architecture for two organisations EnenKio, Inc. and Melchizedek LLC. EnenKio s 6to4 router uses the IPv4 address Every host in Enenkio s intranet receives an IPv6 address with prefix 2002: ::/48. Melchizedek s 6to4 router uses the IPv4 address Every host in Melchizedek s intranet receives an IPv6 address 2 The advertised prefix deliberately excludes the IPv4 portion of the 6to4 routing prefix in order to avoid indirectly polluting the IPv6 routing table with IPv4 routing information for external destinations. If systems with 6to4 addresses exist within the organisation, forwarding table entries with full 48-bit prefixes will be chosen in preference to the entry for the 2002::/16 prefix. 3 July, 2014

4 Melchizedek LLC 2002: ::/ : ::17 host A 6to to4 host B 2002: :: : ::/48 EnenKio Inc IPv4 internet Figure 1: 6to4 Architecture with prefix 2002: ::/48. Both 6to4 routers advertise the prefix 2002::/16 to their respective intranets. Suppose now that host B wants to send an IPv6 packet to host A. The IPv6 source address will IPv4 header src: be 2002: ::24 and dst: the destination address will be src: 2002: :: : ::17. The dst:2002: ::17 packet will be delivered to EnenKio s 6to4 router where IPv4 data it will be encapsulated in an IPv6 data IPv4 packet with source address and destination address The figure to the right shows the encapsulated packet as it traverses the IPv4 internet. This packet will be delivered through the IPv4 internet to Melchizedek s 6to4 router where it will be decapsulated and delivered to host A. IPv6 header The above description assumes a simple scenario with isolated ASs that run an IPv6 internal routing protocol and each have one boundary router configured as a 6to4 router. All these ASs are connected to one another through the IPv4 Internet. 4 July, 2014

5 What if we have a more complex structure: An IPv6 archipelago containing multiple ASs. Each AS is uses IPv6 internally and uses native IPv6 interior routing. Similarly, the BGP speakers for each AS will be exchanging routes with IPv6 NLRI. In this scenario, not all ASs will have a 6to4 boundary router, and the only address available for a host in such an AS will be a native IPv6 address. To communicate with hosts within such a native IPv6 routing archipelago, a 6to4 relay router is used. This is just a normal IPv6-capable boundary router with at least one interface configured for 6to4 encapsulation. (I.e., an interface that possesses an IPv4 address, is connected to an IPv4 routing domain, and is configured for 6to4 encapsulation.) You can think of it as a sort of super-6to4 boundary router. One or more of these will serve the multiple ASs within the native IPv6 routing domain. The 6to4 relay router advertises the prefix 2002::/16 to its BGP peers. within the IPv6 routing domain. A packet with a 6to4 destination address that originates anywhere inside this IPv6 archipelago will be delivered to the nearest 6to4 relay router and injected into the IPv4 routing domain, where IPv4 routing can take over. Now consider a packet that originates in an isolated AS whose only access to the IPv6 Internet is through its 6to4 boundary router. Suppose the destination address of this packet is a host within the native IPv6 archipelago which has only a native IPv6 address. This packet must be delivered to a 6to4 relay router serving the native IPv6 domain; from there it will be handled by the domain s internal IPv6 routing infrastructure. One option is for the 6to4 boundary router of the isolated AS to have an interface configured as a point-to-point connection (e.g., a leased line or a tunnel) to some 6to4 relay router. This interface becomes the default route for all packets addressed to a native IPv6 address outside of the isolated AS. A more sophisticated option is for the 6to4 boundary router of the isolated system to run BGP-4, set up point-to-point connections to multiple 6to4 relay routers and form peer relationships with them. In effect, the isolated system is no longer isolated. It has joined an IPv6 exterior routing domain and the 6to4 boundary router of the isolated system is now simply one more peer in a group of BGP-4 boundary routers. At the start of the IPv6 to IPv4 transition, translation was considered as an alternative for communication between an IPv6 host and an IPv4 host. A router at the edge of an IPv6 region would translate between IPv6 packet headers and IPv4 headers and send the packet on its way. Huitema [1] mentions this translation approach but states that it was finally discarded because of technical difificulties. 5 July, 2014

6 (Just how do you translate IPv6 options to IPv4 options? What about fragmented IPv4 packets? Etc.) Observe, however, that the transport and application layers are independent of the underlying IP version. For a time, it remained true that automatic protocol translation was not under consideration. RFCs 2765 and 2766 describe early translation approaches. RFC 4966 ofificially consigns RFC 2766 to historical status and contains a discussion of the problems with protocol translation. In the view of the IETF, the dual-stack approach, mapped addresses, and 6to4 tunnelling scheme provide flexible support for the transition from IPv4 to IPv6. If both hosts are IPv6-capable and have access to routers capable of routing IPv6 packets, they should communicate using IPv6. Where both IPv6 hosts are isolated (i.e., without access to a router capable of routing IPv6 packets), if they have a dual IPv4/IPv6 stack they can simply fall back on IPv4. Similarly, when an IPv4/IPv6 host needs to communicate with an IPv4 host, it should use the IPv4 protocol stack. Good sense says that you should not remove IPv4 capability from a host unless it s in an IPv6 island and will never need to communicate with a host that s only capable of IPv4. Given the speed of the IPv4 to IPv6 transition, it s unlikely this will happen any time soon. RFC 4213 is quite clear that the sensible approach to the IPv4 to IPv6 transition is to enable IPv6, use IPv4 and IPv6 in parallel while working out any bugs in the IPv6 deployment, and eventually simply turn off IPv4. Unfortunately, the IETF dramatically underestimated the tendency of organisations to cling to the status quo and delay change until it s too late. Parts of the world are now in a position where it s difificult or impossible to obtain new IPv4 addresses, with the result that IPv6-only systems must communicate with IPv4-only systems. Protocol translation is once again under consideration, with limitations. RFC 6144 outlines a framework for translating between the IPv4 and IPv6 versions of IP and ICMP messages. RFC 6145 describes the Stateless IP/ICMP Translation (SIIT) algorithm based on the framework of RFC Very briefly, IPv4/IPv6 address translation is performed by embedding the IPv4 address in an IPv6 address. RFC 6052 reserves a standard prefix of 64:ff9b::/96 and defines a number of other forms for algorithmic address translation. There is also provision in the framework for stateful translation. Observe that when separated into 16-bit words, adding 0x0064 to 0xff9b gives 0xffff, hence it does not change the value of the Internet checksum. 6 July, 2014

7 Translating IPv4 packets to IPv6 packets entails replacing the IPv4 header with a new IPv6 header. This implies that a transport layer checksum may need to be revised. (Remember the pseudoheader?) It may also be necessary to fragment the IPv4 packet, as routers do not fragment IPv6 packets in transit. IPv4 options are ignored. Translating ICMPv4 to ICMPv6 entails translating the type and code fields and calculating the ICMPv6 checksum. For ICMPv4 messages that return the IPv4 header as data, the IPv4 header content must be translated. ICMPv4 messages that have no counterpart ICMPv6 messages are silently dropped. Translating IPv6 packets to IPv4 packets entails replacing the IPv6 header with an new IPv4 header. IPv4 addresses are algorithmically extracted from the IPv6 addresses. If the source IPv6 address is not IPv4-translatable, the packet is dropped and an ICMPv6 Destination Unreachable message is returned to the sender. By definition the destination address is IPv4- translatable. Here, too, the transport layer checksum may need to be revised. As an additional complication, the minimum MTU for IPv4 is less than the minimum MTU for IPv6, so there s a chance that the sending IPv6 implementation might simply balk when it receives an ICMPv6 Packet too big message specifying a MTU that s less than the IPv6 minimum. Translating ICMPv6 messages to ICMPv4 messages always requires recalculation of the ICMP checksum because the ICMPv4 checksum does not incorporate the pseudoheader. Here, too, the type and code fields must be correctly translated, as well as any IPv6 header information included in error messages. The authors of RFC 6144 acknowledge that translation is feasible only in the common use case of applications in a newly-created IPv6-only network that need to communicate with applications in the legacy IPv4-only Internet. This is the prototypical example for a new installation that cannot obtain an allocation of IPv4 addresses. In general, users on this new network will want to communicate with IPv4-only systems in the Internet, and will want to provide servers that are accessible from the IPv4-only Internet. As long as the systems in the IPv6 network are configured with IPv4-translatable IPv6 addresses, translation can work. Translation is not feasible for the case of applications in a legacy IPv4-only network that need to communicate with applications in the new IPv6 Internet. In general, there s no guarantee that IPv6 hosts will have IPv4-translatable addresses. 7 July, 2014

8 Bibliography [1] C. Huitema. IPv6 The New Internet Protocol. Prentice Hall PTR, Upper Saddle River, New Jersey, July, 2014