The Second Internet by Lawrence Hughes - HTML preview
Download the book in PDF, ePub, Kindle for a complete version.
Chapter 7 – Transition Mechanisms
This chapter covers a variety of protocols and mechanisms that were created to simplify the introduction of IPv6 into the Internet. The goal is not to make an abrupt transition from all-IPv4 to all- IPv6 on some kind of “flag day”. That would be unbelievably disruptive, and unlikely to succeed. The goal is to gradually add new capabilities that take advantage of IPv6, or work far better over it (e.g. IPsec VPN, SIP, Mobile IP, IPTV and most other multicast), while continuing to use IPv4 for those things that work tolerably well via over IPv4 with NAT (e.g. web, email, ftp, ssh, and most client-server). This allows immediate alleviation of the most grievous problems caused by widespread deployment of NAT and other shortcomings of IPv4, while allowing a longer, more controlled migration of those protocols that do not benefit as much from IPv6. Eventually, all protocols and applications will be migrated, and IPv4 can quietly be dropped from operating systems and hardware. However, this will probably be 5 to 10 years from now. As more and more applications are transitioned to IPv6, that will take the pressure off of the remaining stock of IPv4 addresses.
Most of these transition mechanisms are defined in RFCs, and were designed as a part of the IPv6 standard. There are many mechanisms, some with confusingly similar names, such as “6in4”, “6to4”, and “6over4”, which are all quite different. Most deployments of IPv6 will use one or more of these transition mechanisms, none will use all of them. Some of the transition mechanisms are designed for use in the early phases of the transition, where there is an “ocean” of IPv4 with small (but growing) islands of IPv6 (e.g. 6in4 tunneling). Some are for use in the later stages of the transition, where the Internet has flipped into an “ocean” of IPv6, with small (and shrinking) islands of IPv4 (e.g. 4in6 tunneling).
7.1 – Relevant Standards
The following standards are relevant to IPv6 transition mechanisms:
* RFC 2473, “Generic Packet Tunneling in IPv6 Specification”, December 1998 (Standards Track) [4in6]
* RFC 2529, “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels”, March 1999 (Standards Track) [6over4]
* RFC 3056, “Connection of IPv6 Domains via IPv4 Clouds”, February 2001 (Standards Track) [6to4]
* RFC 3068, “An Anycast Prefix for 6to4 Relay Routers”, June 2001 (Standards Track) *6to4+
* RFC 3964, “Security Considerations for 6to4”, December 2004 (Informational) [6to4]
* RFC 4213, “Basic Transition Mechanisms for IPv6 Hosts and Routers”, October 2005 (Standards Track) [Dual Stack, 6in4]
* RFC 4380, “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)”,
February 2006 (Standards Track) [Teredo]
* RFC 5158, “6to4 Reverse DNS Delegation Specification”, March 2008 (Informational) [6to4]
* RFC 5214, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)”, March 2008 (Informational) [ISATAP]
* RFC 5569, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)”, January 2010 (Informational) [6rd]
* RFC 5579, “Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces”, February 2010 (Informational)
* RFC 5571, “Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)”, June 2009 (Proposed Standard) [Softwire]
* RFC 5572, “IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)”, February 2010 (Experimental) [TSP]
For Translation between IPv4 and IPv6, you have to go to the Internet Drafts (submitted documents that are not yet approved and given RFC numbers). This is the cutting edge of IPv6. Drafts have a lifetime of six months, and often go through many iterations before being approved (the iteration number is the last part of the draft name, e.g. -08). To keep track of them, use:
* draft-guo-software-6rd-ipv6-config-00, “IPv6 Host Configuration in 6rd Deployment”, 2010-13– 01
* draft-howard-isp-ip6rdns-03, “Reverse DNS in IPv6 for Internet Service Providers”, 2010-03-08
* draft-ietf-softwire-ipv6-6rd-08, “IPv6 via IPv4 Service Provider Networks ‘6rd’”, 2010-03-23
* draft-lee-softwire-6rd-udp-00, “UDP Encapsulation of 6rd”, 2009-10-18
* draft-ietf-behave-v6v4-xlate-stateful-11, “Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers”, 2010-03-30
* draft-boucadair-behave-dns64-discovery-00, “DNS64 Service Location and Discovery”, 2009-10– 18
* draft-cao-behave-dsdns64-00, “Dual Stack Hosts with DNS64”, 2010-02-12
* draft-ietf-behave-dns64-09, “DNS64: DNS extensions for Network Address Translation from Ipv6 Clients to IPv4 servers”, 2010-03-30
* draft-wing-behave-dns64-config-02, “DNS64 Resolvers and Dual-Stack Hosts”, 2010-02-12
* draft-templin-isatap-dhcp-06, “Dynamic Host Configuration Protocol (DHCPv4) Option for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)”, 2009-12-08
* draft-ietf-softwire-dual-stack-lite-04, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion”, 2010-03-08
7.2 – Transition Mechanisms
There are four general classes of transition mechanisms to help us get from all-IPv4 through a mixture of IPv4 and IPv6, to eventually all-IPv6:
7.2.1 – Co-existence
Co-existence involves all client and server nodes supporting both IPv4 and IPv6 in their network stacks. The only mechanism in this group is the Dual Stack. This is the most general solution but also involves running essentially two complete networks that share the same infrastructure. It does not double network traffic, as some administrators fear. Any new connection over IPv6 is typically one less connection over IPv4. Over time, an increasing percentage of the traffic on any network will be IPv6, but the only increase in overall traffic will be from the usual suspects (increasing number of applications, users and/or customers), not from supporting Dual Stack. In fact, at some point you will see the total amount of IPv4 traffic begin to decrease. You may see an increase in incoming customer connections due to the ability to now also accept connections from IPv6 users. When YouTube started accepting connections over IPv6, there was an enormous and almost instant jump in IPv6 traffic on the backbone. Many nodes are ready to begin using IPv6 as soon as content is available, because of automated tunneling. In many cases, the end users might not even have been aware that they were now connecting over IPv6.
There is a recent variant of the dual-stack concept called Dual-Stack Lite that uses the basic dual-stack design, but adds in IP-in-IP tunneling and ISP based Network Address Translation to allow an ISP to share precious IPv4 addresses among multiple customers. It is defined in draft-ietf-softwire-dual-stack-lite-04, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion”.
7.2.2 – Tunneling
Tunneling involves creating IP-in-IP tunnels with a variety of mechanisms to allow sending IPv6 traffic over existing IPv4 infrastructures by adding an IPv4 packet header to the front of an entire IPv6 packet. This treats the entire IPv6 packet, including IPv6 packet header(s), TCP/UDP header and payload fields as a “black box” payload of an IPv4 packet. In the later phases of the transition, it reverses this: it treats an entire IPv4 packet, including IPv4 packet header and options, TCP/UDP header, and payload fields as a “black box” payload of an IPv6 packet. Some of these tunnel mechanisms are “automatic” (no setup required). Others require manual setup. Some require authentication while others do not. The benefit is to leverage the existing IPv4 infrastructure as a transport for IPv6 traffic, without having to wait for ISPs and equipment vendors to support IPv6 everywhere before anyone can start using it. This allows early adopters to deploy nodes and entire networks today, regardless of whether or not their ISP supports IPv6 today. In some cases (e.g. tunnels to a gateway router or firewall), when the ISP does provide dual- stack service, it is a simple process to change from tunneled service to direct service, and the process is largely transparent to inside users. There are several organizations providing free tunneled IPv6 service (using various tunnel mechanisms) during the transition, to help with the adoption of IPv6. Tunneling mechanisms include 6in4, 4in6, 6to4, 6over4, TSP (from gogonet) and Teredo. There are many Operating Systems features and installable client software available to make use of these tunneling mechanisms.
7.2.3 – Translation
This is basically Network Address Translation (with all of its attendant problems), this time between IPv4 and IPv6 (as opposed to the more traditional NAT which is IPv4 to IPv4). An IPv6 to IPv4 translation gateway allows an IPv6-only internal node to access external IPv4-only nodes and allow replies from those legacy IPv4 nodes to be returned to the originating internal IPv6 node. Connections from an internal IPv6-only node to external IPv6-only or dual-stack nodes would be done as usual over IPv6 (without going through the translation gateway). This would be useful for deploying IPv6-only nodes in a predominantly IPv4 world. An IPv4 to IPv6 gateway would allow an IPv4-only internal node to access external IPv6-only nodes, and allow replies from those external IPv6 nodes to be returned to the internal IPv4-ony node). Connections from an internal IPv4-only node to external IPv4-only nodes, or to dual-stack nodes, would be done as usual over IPv4 (without going through the translation gateway). This would be useful for deploying IPv4-only nodes in a predominantly IPv6 world. Some of these mechanisms require considerable modification to (and interaction with) DNS, such as NAT-PT and NAT64 + DNS64.
There are two broad classes of Network Address Translation between IPv4 and IPv6 – those that work at the IP layer, and are transparent to upper layers and protocols; and those that work at the application layer (i.e. Application Layer Gateways, also called Proxies). The IP layer mechanisms need only be implemented once, for all possible application layer protocols. Unfortunately they also have the most technical issues.
There are quite a few Network Address Translation mechanisms between IPv4 and IPv6 currently proposed in IETF drafts, and all have advantages and disadvantages of various kinds. None is a “clean” design without any problems. One such mechanism called NAT-PT was defined in RFC 2766, “Network Address Translation – Protocol Translation (NAT-PT)”, February 2000. It had so many issues that it has already been deprecated to historic status by RFC 4966, “Reasons to Move the Network Address Translator – Protocol Translator (NAT-PT) to Historic Status”, July 2007. Reading RFC 4966 gives a lot of insight into the issues with trying to do translation between IPv4 and IPv6 at the Internet Layer.
7.2.4 – Proxies (Application Layer Gateways)
The other kind of translation mechanism takes place at the Application Layer. They are called proxies, because they do things “on behalf of” other servers, much like a stock proxy voter will vote your stock on your behalf. They are also called Application Layer Gateways (ALGs) because they are gateways (they do forwarding of traffic from one interface to another), and they work at the Application Layer of the TCP/IP four-layer model. They don’t have the serious problems found in IP layer translation mechanisms, such as dealing with IP addresses embedded in protocols (like SIP or FTP). However, there are some problems unique to proxies:
A proxy must be written for every protocol to be translated, and often even different proxies for incoming and outgoing traffic, even for a given protocol (e.g. “SMTP in” and “SMTP out”). Typically each proxy is a considerable amount of work. Often only a handful of the most important protocol will be handled by proxies, while all other protocols are handled by packet filtering.
Writing proxies involves implementing most or all of the network protocol, although sometimes in a simplified manner (e.g. no need to store incoming e-mail messages in a way suitable for retrieval by POP3 or IMAP, just for retransmission by SMTP).
They can support SSL/TLS, but the secure connection extends only from client to proxy, and/or from proxy to server (not directly from client to server). This includes both encryption (the traffic will be “in the clear” on the proxy) and authentication (authentication is only from server to proxy, and/or proxy to client, not from server to client). Typically another digital certificate is required for the proxy server if it supports SSL/TLS (in addition to the one for the server).
They can’t work with traffic secured in the IP layer (IPsec), without access to the keys necessary to decrypt the packets.
Throughput is typically lower than with a packet filtering firewall, due to the need to process the protocol. Of course the security is much better – it won’t let through traffic that is not a valid implementation of the specific protocol, while packet filtering might let through almost anything so long as it uses the right port. There is typically no problem dealing with IP addresses embedded in a protocol.
In many cases, the proxies are not transparent, which means the client must know that it is talking not directly to a server, but via an intermediate proxy. Many protocols support this kind of operation, e.g. HTTP provides good support for an HTTP proxy. Basically, there must be a way for a client to specify not only the nodename of the final server, but also the address or nodename of the proxy server. In a browser (HTTP client), the nodename of the final server is specified as usual, and the address of the proxy server is specified during the browser configuration (“use a proxy, which is at address w.x.y.z”). When configured for proxy operation, the browser actually connects to the proxy address and relays the address of the final server to the proxy. The proxy then makes an ongoing connection to the final web server. Some protocols have no support for proxy type operation (e.g. FTP). It is possible for a firewall to recognize outgoing traffic over a given port, and automatically redirect it to a local proxy.
Application Layer Gateways (e.g. for SIP, HTTP, and SMTP) work quite well. Basically they accept a connection on one interface of a gateway, and make a second “ongoing” connection (on behalf of the original node) via another interface of the same gateway. It is easy for the two connections to use different IP versions (e.g. translate IPv4 traffic to IPv6 traffic or vice versa). In some ALGs an entire message might be spooled onto temporary storage, (e.g. email messages) and then retransmitted later. In other cases, the ongoing connection would be simultaneous with the incoming connection, and bidirectional (e.g. with HTTP). This would correspond to a human “simultaneous translator” who hears one language (e.g. Chinese), translates and simultaneously speaks another language (e.g. English).
Another example of this is an outgoing web proxy which could accept connections from either IPv4-only or IPv6-only browsers, and then make an ongoing connection to external servers using whatever version of IP those servers support (based on DNS queries). Again, this is a traditional (forward) web proxy, with the addition of IP version translation. This would allow IPv4-only or IPv6-only clients to access any external web server, regardless of IP version they support. Such a proxy could of course also provide any services normally done by an outgoing web proxy, such as caching and URL filtering.
Another example of this is a dual-stack façade that would accept incoming connections from outside over either IPv4 or IPv6, and make an ongoing connection over IPv4 to an internal IPv4-only (or over IPv6 to an IPv6-only) web server. It would relay the web server’s responses using whatever version of IP was used in the original incoming connection to the client. This is a typical “reverse” web proxy, with the addition of IP version translation. This kind of translation can help you provide dual stack versions of your web services quickly and easily, without having to dual-stack the actual servers themselves. The same technique could allow you to make your e-mail services dual stack without having to modify your existing mail server.
7.3 – Dual Stack
Dual Stack (also known as Dual IP Layer) is defined in RFC 4213, “Basic Transition Mechanisms for IPv6 Hosts and Routers”, October 2005. A dual-stack node should include code in the Internet Layer of its network stack to process both IPv4 and IPv6 packets. Typically, there is a single Link Layer that can send and receive either IPv4 or IPv6 packets. The Link Layer also contains both the IPv4 Address Resolution Protocol (ARP) and the IPv6 Neighbor Discovery (ND) protocol. The Transport Layer has only minor differences in the way IPv4 and IPv6 packets are handled, primarily concerning the way the TCP or UDP checksum is calculated (they checksum also covers the source and destination IP address from the IP header, which of course is different in the two IP versions). The application layer code can make calls to
routines in the IPv4 socket API, the IPv6 basic socket API and the IPv6 advanced socket API. IPv4 socket functions will access the IPv4 side of the IP layer, and IPv6 socket functions will access the IPv6 side of the IP layer.
Four Layer Network Model for Dual Stack
The node should include the ability to do conventional IPv4 node configuration (including a node address, default gateway, subnet mask and addresses of DNS servers, all as 32 bit IPv4 addresses). This configuration information can be done manually, via DHCPv4, or some combination thereof. The node should also include the ability to do conventional IPv6 node configuration (including a link-local IP address, one or more global unicast address(es), a default gateway, the subnet length and the addresses of DNS servers, all 128 bit IPv6 addresses). This configuration information can be done manually, automatically via Stateless Address Autoconfiguration, automatically by DHCPv6, or by some combination thereof. There is usually a way to disable either the IPv6 functionality (in which case the node behaves as an IPv4-only node), or the IPv4 functionality (in which case the node behaves as an IPv6-only node). There may or may not also be some tunneling mechanism involved. If the node is in a native dual-stack network no tunnel mechanism is required. If the node is in an IPv4-only, or an IPv6- only network, it will require a tunnel mechanism to handle traffic of the other IP version.
IPv4-only (and for that matter, IPv6-only) applications (client, server and peer-to-peer) will work just fine on a dual-stack node. They will make calls to system functions only one side of the network stack. They will not gain any new ability to accept or make connections over the other IP version just because they are running on a dual-stack node.
A dual-stack client can connect to IPv4-only servers, IPv6-only servers, or dual-stack servers. A dual-stack server can accept connections from IPv4-only clients, IPv6-only clients, or dual-stack clients. Dual-stack is the most complete and flexible solution. The only issues are the additional complexity of implementation and deployment, and the additional memory requirements. For very small devices (typically clients), dual-stack may not be an option. Some critics of IPv6 claim that DSTM is not viable because we are running out of IPv4 addresses. What they are missing is that there are plenty of private IPv4 addresses for use behind NAT, and the IPv4 side of dual-stack systems can be used only for protocols where this is not a problem, while using their IPv6 side for those protocols which are incompatible with NAT (IPsec VPN, SIP, Mobile IP, P2P, etc), or can benefit from other IPv6 features which are superior to their IPv4 equivalents, such as multicast and QoS (SIP, IPTV, conferencing, P2P, etc). Also, any application running on that node that needs to accept a connection from external nodes (e.g. your own web server) can use a global unicast IPv6 address (for IPv6 capable clients). If you want to accept connections from IPv4 clients, you would have needed a globally routable IPv4 address for that anyway, or would need to deploy NAT Traversal (with or without dual-stack). Dual-Stack cannot create more globally routable IPv4 addresses. It can however, allow you to easily make use of an almost unlimited number of globally routable IPv6 addresses (both unicast and multicast).
A key part of a dual-stack network is a correctly configured dual-stack DNS service. It should not only be able to publish both A and AAAA records (as well as reverse PTR records for IPv4 and IPv6), it should also be able to accept queries and do zone transfers over both IPv4 and IPv6. A dual-stack network typically uses DHCPv4 to assign IPv4 addresses to each node, and either Stateless Address Autoconfiguration and/or DHCPv6 to assign IPv6 addresses to each node. A dual-stack firewall can bring in either direct dual-stack service (both IPv4 and IPv6 traffic) from an ISP (if available), routing both to the inside network; or it can bring in direct IPv4 traffic from an ISP and terminate tunneled IPv6 traffic (from a “virtual” ISP usually different from the IPv4 ISP) and route both IPv4 and IPv6 into the inside network. In either case (direct dual stack service or tunneled IPv6 with endpoint in the gateway), inside nodes appear to have direct dual-stack service, and require no support for tunneling.
The DNS support does not require any modifications to a standard DNS server (e.g. BIND). DNS just needs to be able to perform its normal forward and reverse lookups with either IPv4 (A/PTR) or IPv6 (AAAA/PTR) resource records. There is need to for the DNS server to do nonstandard mappings between IPv4 and IPv6 addresses as is required with most IP layer translation schemes (e.g. NAT64 + DNS64).
Migrating IPv4-only client or server applications to IPv6-only is quite simple. There is essentially a one to one mapping of function calls from the IPv4 socket API to similar ones in the IPv6 basic socket API. Of course, more storage is required for each IP address in data structures (4 bytes for IPv4 addresses, 16 bytes for IPv6 addresses).
Modifying either IPv4-only clients or IPv4-only servers to dual-stack operation is somewhat more complicated. A dual-stack client must be modified to retrieve multiple addresses (IPv4 and/or IPv6) from DNS, and try connections sequentially to the returned address list until a connection is accepted. The default (assuming IPv6 connectivity is available) is to attempt connections over IPv6 first. If DNS advertises an IPv6 address, and the node supports IPv6, but for some reason the client is unable to connect over IPv6 (e.g. tunnel down), there will be a 30 second timeout then a fallback to IPv4. A dual- stack server must listen for connections on either IPv4 or IPv6, and process connections from either. It is also possible to deploy two copies of each server, one being IPv4-only, and the other IPv6-only. This might involve cross process file locking on any shared resource, such as a message store. Either approach to providing dual-stack servers will work fine, and the user experience will be the same. Conditional compilation could be used to have a single source code tree create both an IPv4-only and an IPv6-only executable (depending on setting of system variables at compilation time). For most server designs (process per connection or thread per connection), the split model (an IPv4-only server and an IPv6-only server) would roughly double the memory footprint compared to a single dual-stack server.
Most open source servers today have good support for dual-stack operation. These include the Apache web server, Postfix SMTP server, Dovecot IMAP/POP3 mail access servers, etc. If you are a developer and want to see examples of how to deploy dual-stack servers, there are numerous examples available in open source. Most open source client software also has good support for IPv6 and dual-stack. These include the Firefox web browser, Thunderbird e-mail client, etc. The open source community has done an excellent job of supporting the migration to IPv6. Both the original IPv4-only socket API and the newer IPv6 socket APIs are readily available on all UNIX and UNIX-like platforms. The documentation for the newer IPv6 socket APIs are in RFC 3493, “Basic Socket Interface Extensions for IPv6” and RFC 3542, “Advanced Sockets Application Program Interface (API) for IPv6”. There is also RFC 5014, “IPv6 Socket API for Source Address Selection”, and RFC 4584, “Extension to Sockets API for Mobile IPv6”.
Virtually all Microsoft server products (since 2007) have had good support for dual-stack operation. These include Windows Server 2008 (and all of its components, such as DNS, file and printer sharing, etc); Exchange Server 2007; and many others. Their client operating systems have had good support for IPv6 since Vista. For Microsoft developers, both the original IPv4-only socket API (WinSock) and the new IPv6 socket APIs (basic and advanced) are available as part of the standard Microsoft developer libraries.
7.3.1 – Dual-Stack Lite
The IETF Softwires Working Group has come up with a variant on the basic Dual-Stack network design, which is described in draft-ietf-softwire-dual-stack-lite-04, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion”. Clients will still support both IPv4 and IPv6, but the service from the ISP to the customer will be IPv6-only, with IPv4 service tunneled over the IPv6. The addresses provided to the customer will be RFC 1918 private addresses, provided by a giant Large Scale NAT (LSN) at the ISP. The NAT involved actually uses the customer’s IPv6 address to tag the private IPv4 addresses used by the client, which would allow multiple ISP clients to use the same private address range (e.g. all of them could use 10.0.0.0/8, and the LSN would keep each organization’s addresses separate based on their unique IPv6 address).
IPv6-only or Dual-Stack nodes at the client would be able to connect to any IPv6 node in the world directly, via the ISPs IPv6 service. IPv4-only or Dual-Stack nodes at the client would be able to connect to any IPv4 node in the outside world via IPv4 tunneled over IPv6, with addresses from the ISP’s Large Scale NAT. There is no 6to4 translation that would allow an IPv6-only node to connect to external IPv4 nodes, or 4to6 translation that would allow an IPv4-only node to connect to external IPv6 nodes. Any internal node that needs to connect to external IPv4 nodes should be configured to support dual-stack.
The way this differs from basic Dual-Stack operation is that there is no direct IPv4 service provided, and the IPv4 addresses used at the client are private, and managed by infrastructure at the ISP. This allows the ISP to share a relatively small number of precious real IPv4 addresses among a large number of customers, and also allows the ISP to run only a single IP family of “direct service” to the customer (which happens to be IPv6). A major advantage of DS-Lite is that no 6to4 or 4to6 translation is required.
This will require a firmware upgrade (or replacement) of the Customer Premise Equipment (CPE), which is typically a DSL or cable modem, with embedded router and NAT.
This is the “IPv6 service” being trialed by Comcast in the United States as this is being written.
The ISC (who also supply the BIND DNS server and dhcpd DHCPv4 server) have created a freeware implementation of the ISP side facilities to support DS-Lite, called AFTR (Address Family Transition Router). This includes IPv4 over IPv6 tunneling, DHCPv4, DHCPv6 and some other pieces.
The CPE device for DS-Lite is called B4 (Basic Bridging BroadBand Element). There is an open source implementation of this for the Linksys WRT-54GL.
7.4 – Tunneling
If tunneled service is brought into the network by a gateway device (typically the gateway router or firewall), which contains the tunnel endpoint, the internal network is a native dual-stack network from the viewpoint of all internal nodes. No internal node needs to have support for any tunneling mechanism. If at some point, the tunneled service is replaced with direct service (both IPv4 and IPv6 service direct from your ISP) a minor reconfiguration at the gateway is all that is required. Internal nodes will probably not require any reconfiguration at all. They will typically have a new IPv6 prefix (unless you were getting tunneled service from your ISP), so you will likely have to update all forward and reverse address references in your DNS server (only for IPv6 addresses), to reflect the new IPv6 prefix. If your DNS server supports instant prefix renumbering like SolidDNS, this is a quick, painless process. If you are using DHCPv6 in stateful mode (where it assigns IP addresses) in conjunction with dynamic DNS registration, even DNS changes due to change of IPv6 prefix may happen automatically.
A tunnel mechanism has both a server side and a client side. The server side typically can accept one or more connections from tunnel clients. It is also commonly called a Tunnel Broker. A tunnel client typically makes connections to a single tunnel server. Some such connections (e.g. with 6in4) are not authenticated (although the server can typically be restricted to accepting connections only from specific IP addresses or address ranges). Some such connections (e.g. gogonet’s TSP) include authentication of the client to the server, before the tunnel will begin operation. Some connections (e.g. 6in4) require a globally routable IPv4 address on the client (although this can be the same address as the hide-mode NAT address). Other tunnel clients will work behind NAT, even with a private address. These include a NAT traversal mechanism in the client, and typically all tunneled packets are carried over UDP. Once a tunnel is created, it is bi-directional. Packets can be sent either upstream or downstream. From a hop count perspective, the tunnel counts as one hop, no matter how many hops the tunneled packets traverse.
Typical Product Support for Tunneling: InfoWeapons’ SolidWall Dual Stack Firewall
As an example of a typical product that includes support for tunneling, InfoWeapons has a dual stack firewall called SolidWall. On the IPv4 side, it includes typical firewall capabilities including routing, filtering by port and address, stateful packet inspection and various forms of NAPT (hide mode, BINAT or 1:1 and port forwarding). On the IPv6 side, it includes all of that (except for NAPT), plus a Router Advertisement Daemon (to enable Stateless Address Autoconfiguration) and 6in4 server and client mode. You could use the 6in4 client mode to bring in IPv6 tunneled service from any 6in4 virtual ISP (e.g. Hurricane Electric). You could create your own (small) IPv6 virtual ISP using Solidwall’s 6in4 tunnel server mode. For example, you could provide tunneled IPv6 service from your HQ or collocation facility to various branches, using the 6in4 tunnel server at HQ and the 6in4 tunnel clients at each branch. You can carve off any number of “/64” subnets into each branch office. For example, you could split a “/48” block into sixteen “/52” blocks, and route one “/52” block into each branch office.
Because the client mode tunnel endpoint is located inside a firewall node, incoming IPv6 packets from the tunnel can be filtered and routed into any inside network(s). Outgoing IPv6 packets from any internal network can be filtered and routed out the tunnel to the outside world (via a remote tunnel server).
The server mode tunnel endpoint is also located inside a firewall node, so the firewall’s routing capabilities allow you to easily route any block of addresses from the outside world into any tunnel (and hence to branch offices), and outgoing packets (from tunnels coming from branch offices) to the outside world. Currently there is no support for OSPFv3 or BGP4+, so you would need to relay outgoing IPv6 traffic onwards via an ISP (or virtual ISP) that can do further routing.
As an example, we have one SolidWall at our colocation facility in Atlanta, Georgia. We split our “/48” block (2001:418:5403::/48) into 16 “/52” blocks. We use subnet 2001:418:5403:0::/52 locally in the collocation facility. Our website (www.infoweapons.com) is hosted there along with our main DNS servers (on a pair of our own SolidDNS appliances). We route subnet 2001:418:5403:2000::/52 to our office in Cebu, and subnet 2001:418:5403:3000::/52 to my home in Cebu. The client side of each of these tunnels is another SolidWall appliance. In each case, it brings IPv4 service from a local ISP into the network, with IPv6 from our colo tunneled over it. Incoming IPv6 is “de-tunneled” inside the firewall and routed into the internal network alongside the filtered IPv4. Outgoing IPv6 from each network is “en- tunneled” through the local SolidWall, and it comes out at the SolidWall at the colo, where it is routed onwards via our direct dual-stack service from NTT America. It sounds complicated, but in reality it only takes a few minutes to each tunnel up, using a simple point-and-click GUI.
Because the tunnel mechanism used (6in4) is an IETF standard, SolidWall’s tunnels will interoperate with server or client mode 6in4 tunnel endpoints on any other vendor’s products or even on homegrown routers built from open source platforms such as FreeBSD, OpenBSD or Linux.
In future releases we plan to add several other kinds of tunneling to SolidWall (probably 6to4, TSP and Dual-Stack Lite).
7.4.1 – 6in4 Tunneling
RFC 4213 (in addition to specification for Dual Stack), specifies 6in4 tunneling (unfortunately they use the term “6over4” when they mean “6in4”). Technically, 6in4 is a tunneling mechanism. 6over4 is a transition mechanism that uses 6in4 tunneling to create a virtual IPv6 link over an IPv4 multicast infrastructure (see RFC 2529). This book will use the term 6in4 unless we are specifically talking about 6in4 tunnels over IPv4 multicast. 6in4 is also sometimes referred to as “Protocol 41” tunneling. 6in4 tunneling requires both ends of the tunnel to have globally routable IPv4 addresses (neither tunnel endpoint can be behind NAT). It is possible for a firewall that is using a globally routable IPv4 address for HIDE mode NAT (with multiple internal nodes hidden behind it), to use that same address as one endpoint of a 6in4 tunnel.
This process is done to “push packets into the tunnel” for packets going from either end of the tunnel to the other. The basic idea is to prepend a new IPv4 packet header to a complete IPv6 packet (which itself consists of the basic IPv6 header, zero or more extension headers, a TCP or UDP header, and a payload), and treat the entire IPv6 packet as a “black box” payload for the IPv4 packet.
The encapsulation of an IPv6 datagram in IPv4 for 6in4 tunneling is shown below:
Encapsulating IPv6 in IPv4
The new IPv4 packet header is constructed as follows (from the RFC):
4 (the encapsulating packet is IPv4)
IP Header Length:
5 (in 32 bit words, so 20 bytes, and no IPv4 options are used in the encapsulating header)
Type of Service:
0 unless otherwise specified (see RFC 2983 and RFC 3168 for details)
IPv6 payload length plus IPv6 header length (40) plus IPv4 header length (20), so IPv6 payload length + 60
Generated uniquely as for any IPv4 packet
DF (Don’t Fragment) flag should be set as specified in section 3.2 of RFC 4213
MF (More Fragments) flag set as necessary if fragmenting
Set as necessary if fragmenting
Time to Live (TTL):
Set as described in Section 3.3 of RFC 4213
41 – this is the defined payload type for IPv6 tunneled over IPv4, and is used regardless of whether the IPv6 transport is UDP or TCP
Calculated as usual for an IPv4 packet header
An IPv4 address of the encapsulator: either configured by the administrator, or an address of the outgoing interface
IPv4 address of the tunnel endpoint (that is, the client side of the tunnel)
This is done for all packets received over the tunnel from the other end. The basic idea is to strip the outer (IPv4) packet header off (and discard it), then handle what is left (the original IPv6 packet) as native IPv6 traffic.
From the RFC: When a dual stack node receives an IPv4 datagram that is addressed to one of its own IPv4 addresses (or a joined multicast group address), which has a protocol field of 41 (tunneled IPv6), the packet must be verified to belong to a configured tunnel interface (according to source/destination addresses), reassembled (if it was fragmented), have the IPv4 header removed, and then the resulting IPv6 datagram is submitted to the IPv6 layer on the node for further processing.
The decapsulation process for 6over4 tunneling is shown below:
Decapsulating IPv6 from IPv4
According to RFC 4213, section 3.2, the MTU of the tunnel must be between 1280 and 1480 bytes (inclusive), but should be 1280 bytes. Section 3.3 specifies that the tunnel counts as a single hop to IPv6, regardless of how many hops the underlying IPv4 packet traverses. The actual TTL value in the outer IP header should be set as for any IPv4 packet (see RFC 3232 and RFC 4087).
RFC 4213 section 3.4 specifies how to handle errors that happen while the encapsulated packet is inside the tunnel. Unfortunately older routers may not return enough of the packet to include both source and destination IPv6 addresses of the encapsulated packet, so it may not be possible to construct a correct ICMPv6 error message. Newer routers typically include enough of the failed packet for correct ICMPv6 error message creation.
7.4.2 – 6over4 Tunneling
6over4 tunneling is defined in RFC 2529, “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels”. It is a transition mechanism that uses 6in4 tunneling over an IPv4 multicast capable network. The term 6over4 is sometimes confusingly used for 6in4 tunneling. Due to the requirement for IPv4 multicast, which is very difficult to deploy, 6over4 is not commonly used.
7.4.3 – 6to4 Tunneling
6to4 tunneling is described in RFCs 3056, 3068, 3964 and 5158. It is a transition mechanism that provides tunneled IPv6 over IPv4 without explicitly configured tunnels. With the original 6to4 mechanism, the IPv4 addresses involved must be valid globally routable IPv4 addresses (not behind NAT). Teredo is a variant of 6to4 tunneling that will work even behind NAT.
6to4 does not provide general translation to IPv4 addresses for interoperation between IPv6 hosts and IPv4 hosts. It uses automatically created tunnels over IPv4 to facilitate communication between any number of IPv6 hosts.
A “6to4 Host” is a regular IPv6 host that also has at least one 6to4 address assigned to it.
A “6to4 Router” is a regular IPv6 router that includes a 6to4 pseudo interface. It is normally a border router between an IPv6 site and a wide-area IPv4 network.
A “6to4 Relay Router”, which is a 6to4 router which is also configured to support transit routing between 6to4 addresses and native IPv6 addresses.
Without 6to4 Relay Routers, you can communicate with other nodes that use 6to4 tunneling, over IPv6 (even though your ISP does not yet support IPv6). To communicate with IPv6 users that are not using 6to4, you need to relay your traffic through a 6to4 relay router. You can create your own (which must have both a 6to4 pseudo interface, and real (not 6to4) IPv6 connectivity to the IPv6 Internet.
A 6to4 router will send an encapsulated packet directly over IPv4 if the first 16 bits of an IPv6 destination address are 2002, using the next 32 bits as the IPv4 destination (which must be another 6to4 node that will unpack the IPv6 packet being sent and use it or relay it to other IPv6 hosts). For all other IPv6 destination addresses, a 6to4 router will forward the packet to the IPv6 address of a well-known relay server that has access to native IPv6 (or simply send it to the IPv6 anycast address
2002:c058:6301::/128, which will send it to the nearest 6to4 relay router). For details on how to configure a FreeBSD node with 6to4 tunneling, see http://www.kfu.com/~nsayer/6to4 An IPv6 address for use with 6to4 tunneling looks like the following:
Essentially the IPv6 prefix for all 6to4 addresses is 2002:V4ADDR::/48. RFC 3056 defines a 6to4 pseudo-interface as follows:
“6to4 encapsulation of IPv6 packets inside IPv4 packets occurs at a point that is locally equivalent to an IPv6 interface, with the link layer being the IPv4 unicast network. This point is referred to as the pseudo-interface. Some implementers may treat it exactly like any other interface, and others may treat it like a tunnel endpoint.”
7.4.4 – Teredo
Teredo is one extension of basic 6to4 tunneling. It adds encapsulation over UDP datagrams, and uses a simplified version of STUN NAT Traversal, allowing a Teredo client to be behind NAT. It is defined in RFC 4380, “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)”. The name “Teredo” is part of the Latin name for a little worm that bores holes through wooden ship hulls. This gives you a pretty good idea of what the Teredo protocol does to your firewall. Teredo is installed and enabled by default in Windows Vista and Windows 7. It is possible to disable it, but this is not easy.
There is an open source Teredo client for Linux, BSD and Mac OS X called Miredo. It can act as a client, relay and server.
There are publically available Teredo “relay routers” that allow any node with Teredo to access the IPv6 Internet. Microsoft makes several very large ones available for use from Windows nodes. Windows nodes are preconfigured to use these relay servers. Unlike 6to4 and some other tunnel mechanisms, Teredo can only provide a single “/128” IPv6 address per tunnel endpoint.
Teredo uses a different IPv6 address block than basic 6to4 tunneling. The rest of the Teredo address is defined differently as well.
* Bits 0-31 contain the Teredo prefix, which is 2001:0000::/32.
* Bits 32-63 contain the IPv4 address of the Teredo Server used.
* Bits 64-79 contain some flags. Currently only bit 64 is used. If set to 1, the client is behind a cone NAT, otherwise it is 0. More of these flag bits are used in Vista, Windows 7 and Windows Server 2008.
* Bits 80-95 contain the obfuscated UDP port number (port number that is mapped by NAT, with all bits inverted)
* Bits 96-127 contain the obfuscated IPv4 address of the node (public IPv4 address of the NAT with all bits inverted)
As an example, a Teredo address might be 2001::4136:e378:8000:63bf:3fff:fdd2, which broken into fields is:
* Bits 0-31: 2001:0000 – The Teredo prefix
* Bits 32-63: 4136:e378 – IPv4 address 188.8.131.52 in hexadecimal
* Bits 64-79: 8000 – Cone mode NAT
* Bits 80-95: 63bf – Obfuscated port number 40000
* Bits 96-127: 3fff:fdd2 – Obfuscated public IPv4 address of the node (192.0.2.45) Public Teredo servers can be located on the following website:
Hurricane Electric, as of Q1 2009, had deployed 14 public Teredo relays (via anycast), in Seattle Washington, Fremont California, Los Angeles California, Chicago Illinois, Dallas Texas, Toronto Ontario, New York New York, Ashburn Virgina, Miami Florida, London England, Paris France, Amsterdam Netherlands, Frankfurt Germany and Hong Kong SAR.
7.4.5 – 6rd – IPv6 Rapid Deployment
6rd is another extension of 6to4 tunneling, that adds reliable routing. Normal 6to4 tunnels use the standard 2002://16 prefix, and in theory scale to the entire world. Unfortunately, there is no way to control who can connect to 6to4 public servers, and there is no incentive to provide quality service. Also there is no guarantee that any 6to4 node will be reachable. The same is true of Teredo.
6rd instead works only within the confines of a single ISP, and instead of the 2000://16 prefix, each ISP uses a prefix that they own and control and runs the Relay Router. They can insure quality service and reachability of all nodes within their network.
6rd was deployed by a French ISP called “Free” (in spite of the name, this is a commercial ISP). This was done in 5 weeks starting in December 2007. This gave France the second highest IPv6 penetration in the world, 95% of which was via Free’s 6rd. RFC 5569 discusses Free’s 6rd deployment. The current Internet Draft that defines 6rd (draft-ietf-softwire-ipv6-6rd-08, “IPv6 via IPv4 Service Provider Networks ‘6rd’”,
2010-03-23) should be approved soon. Meanwhile you can read the draft.
In January 2010, Comcast (a large U.S. ISP) announced plans to do a trial deployment of IPv6 using 6rd. Softbank (a large Japanese ISP) also has announced that they will roll out IPv6 using 6rd.
7.4.6 – Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
ISATAP is a transition mechanism that allows transmission of IPv6 packets between dual-stack nodes on top of an IPv4 network. It is similar to 6over4, but it uses IPv4 as a virtual Non-Broadcast Multiple-Access (NBMA) network Link Layer, and does not require IPv4 multicast (which 6over4 does require). It is discussed in RFC 5214, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)”.
ISATAP specifies a way to generate a link-local IPv6 address from an IPv4 address, plus a mechanism for performing Neighbor Discovery on top of IPv4.
The generated link local address is created by appending the 32 bit IPv4 address onto the 96 bit prefix fe80:0:0:0:0:5efe::. For example, the IPv4 address 192.0.2.143 in hexadecimal is c000028f. Therefore the corresponding ISATAP link-local address is fe80::5efe:c000:28f.
The Link Layer address for ISATAP is not a MAC address, but an IPv4 address (remember IPv4 is used as a virtual Link Layer). Since the IPv4 address is just the low 32 bits of the ISATAP address, mapping onto the “Link Layer” address simply involves extracting the low 32 bits (ND is not required). However, router discovery is more difficult without multicast. ISATAP hosts are configured with a potential routers list (PRL). Each of the routers on this list are probed by an ICMPv6 Router Discovery message, to determine which of them are functioning and to then obtain the list of on-link IPv6 prefixes that can be used to create global unicast IPv6 addresses.
Current implementations create their PRL by querying the DNS. DHCPv4 is used to determine the local domain, then a DNS query is done for isatap.<localdomainame>. For example, if the local domain is demo.com, it would do a DNS query for isatap.demo.com.
ISATAP avoids circular references by only querying DNS over IPv4, but it still a lower-layer protocol that is using a higher-layer function (DNS). This is a violation of network design principles.
ISATAP is implemented in Windows XP, Windows Vista, Windows 7, Windows Mobile, and Linux (since Kernel 2.6.25). It is not currently implemented in *BSD due to a potential patent issue.
7.4.7 – Tunnel Setup Protocol (TSP)
TSP is defined in RFC 5572, and was created by Marc Blanchet, author of “Migrating to IPv6” (and at the time CTO of Hexago). Hexago sold an IPv6 Tunnel Broker appliance that implemented TSP. It is similar in certain respects to 6in4 tunneling, but works even behind NAT, and includes client authentication. Hexago offered free TSP clients for most platforms and free IPv6 tunneled service to anyone through their own Freenet6 service. There was a management buyout a few years ago, and now Hexago is known as gogo6. They still offer the same TSP based products and free tunneled IPv6 service. They now run gogoNET, which is a social networking site built around IPv6 (with 17,000 members as of April 2010).
gogo6’s free tunneled service is one of the best ways to get started in IPv6. You simply download their free client for whatever platform you use, install it, sign up for a free account, and connect. You can obtain a single (“/128”) IPv6 address even when you are on the road (e.g. in a hotel). You can even obtain a “/56” block on a router to provide IPv6 connectivity to an entire network. Service is on a “best effort” basis (no guarantees). They also have a DS-Lite trial service for tunneled IPv4 over IPv6, and a DSTM (Dual-Stack Transition Method) service to allow people to access IPv4-only Internet services from an IPv6-only network. The IPv4 address obtained in private, and all users of Freenet6’s DSTM share a single block of public IPv4 addresses.
TSP is actually a framework that can do any of the following:
* User authentication, with various mechanisms include SASL
* NAT discovery
* Encapsulation of IPv6 over IPv4 (RFC 4213, 6in4)
* Encapsulation of IPv4 over IPv6 (RFC 2473, 4in6)
* Encapsulation of IPv6 over UDP-IPv4 tunnels for NAT traversal
* IP address assignment for the tunnel endpoints
* DNS registration of the IP endpoint address (AAAA record)
Once a user is authenticated, the client performs NAT discovery. The client sends a TSP message over UDP, containing its tunnel request information (e.g. source IPv4 address) to the tunnel server. The TSP server compares the IPv4 source address of this datagram with the address in the datagram payload. If they differ, then at least one NAT was traversed, and the tunnel will use encapsulation over UDP with NAT traversal. A keep-alive mechanism is also selected. If the addresses match (no NAT detected), then simple 6in4 (RFC 4213) tunneling is selected. If the datagram contains an IPv6 address, and the source address of the datagram is IPv6, then 4in6 tunneling is selected.
Features of TSP:
* The created tunnel is static, which is more secure than automated tunnels (per RFC 3964).
* The IPv6 address and prefix are stable, and not dependent on the underlying IPv4 address
* Prefix assignment is supported
* Automated NAT discovery and negotiation of optimal NAT traversal scheme
* TSP uses TCP on port 3653 or UDPv4 on port 3653
Tunnel Setup Protocol Exchange
C: ERSION=2.0.0 CR LF
S: APABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN
AUTH=DIGEST-MD5 CR LF
C: UTHENTICATE ANONYMOUS CR LF
S: 0 Success CR LF
Successful Anonymous Authentication
C: ERSION=2.0.0 CR LF
S: APABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS
S: AUTH=DIGEST-MD5 CR LF
C: UTHENTICATE DIGEST-MD5 CR LF
C: 2hhcnNldD11dGY4LHVzZXJuYW1lPSJ1c2VybmFtZTEiLHJlYWxtPSJoZXhvcyIsbm uY2U9IjExMTM5MDg5NjgiLG5jPTAwMDAwMDAxLGNub25jZT0iMTExMzkyMzMxMSIsZG lnZXN0LXVyaT0idHNwL2hleG9zIixyZXNwb25zZT1mOGU0MmIzYzUwYzU5NzcxODUzZ
S:200 Success CR LF
Successful Digest-MD5 Authentication
-- UDP session established -–
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS
AUTH=PLAIN AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Success CR LF
C:Content-length: 205 CR LF
<tunnel action="create" type="v6udpv4">
</tunnel> CR LF
S:Content-length: 501 CR LF
200 Success CR LF
<tunnel action="info" type="v6udpv4" lifetime="604800">
</tunnel> CR LF
C:Content-length: 35 CR LF
<tunnel action="accept"></tunnel> CR LF
Example of a Command/Response Sequence
-- Successful TCP Connection -–
C:VERSION=1.0 CR LF
S:CAPABILITY TUNNEL=V4V6 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
C:AUTHENTICATE ANONYMOUS CR LF
S:OK Authentication successful CR LF
C:Content-length: 228 CR LF
<tunnel action="create" type="v4v6">
</tunnel> CR LF
S: Content-length: 370 CR LF
200 OK CR LF
<tunnel action="info" type="v4v6" lifetime="1440">
<address type="ipv4" length="30">
<address type="ipv4" length="30">
</tunnel> CR LF
IPv4 over IPv6 Tunnel Request and Response
7.4.8 – Softwires
The IETF has a very active Softwires working group. Essentially they are trying to create standards for tunneling IPv6 over IPv4 networks and for tunneling IPv4 over IPv6 networks. There are two basic models for this, one is called Hub and Spoke. This is similar to the way that airlines have a few large hub airports and many spokes or local flights radiating from those hubs to smaller communities nearby. For example, Atlanta International Airport is a hub for the entire Southeastern United States. If you fly in or out of that region, you will likely interchange in Atlanta. There are several schemes that vary in exactly what part of the network path the softwire is deployed:
* from ISP to Customer Modem/Router
* from ISP via Customer Modem/Router to an inside softwire router
* from ISP via Customer Modem/Router to an end-user node
All the components necessary to deploy the various schemes are widely available, including;
* LNS: large ISP based L2TP Network Server
* Dual AF CPE: Customer Premise Equipment Modem/Router with support for L2TPv2 softwires
* Dual AF Router: Customer Premise dual-stack router with support for L2TPv2 softwires
* Dual AF Host: Client software for end-user nodes with support for L2TPv2 softwires
In the above, “Dual AF” means Dual Address Family, in other words, IPv4 + IPv6, or dual stack.
The other softwire architecture is called Mesh. This involves a number of peer nodes, with multiple connections between them. If all nodes are connected to all other nodes, that would be a fully meshed network.
The term softwire refers to a tunneled link between two or more nodes. In early RFCs related to this technology, sometimes the term pseudowire is used instead. Softwires are assumed to be long-lived, and the setup time is expected to be a very small fraction of the total time required for the startup of the Customer Premise Equipment / Address Family Border Router. The goal is to make cost effective use of existing facilities and equipment where possible.
Current softwire solutions are mostly based on L2TPv2, which is defined in RFC 2661, “Layer Two Tunneling Protocol ‘L2TP’”, August 1999. L2TPv1 was defined in RFC 2341, “Cisco Layer Two Forwarding (Protocol) ‘L2F’”, May 1998. L2TPv2 is layered on PPP, which is defined in RFC 1661, “The Point-to-Point Protocol (PPP)”, July 1994. All L2TPv2 connections use UDP encapsulation. There are already some very large deployments of softwires on LT2Pv2 in ISPs today. L2TPv2 meets all IPv6 over IPv4 softwire requirements today. It is 99% ready for IPv4 over IPv6 softwire today.
Future softwire solutions will be based on L2TPv3, which is defined in RFC 3931, “Layer Two Tunneling Protocol – Version 3 (L2TPv3)”, March 2005. L2TPv3 can be layered on PPP, but in v3 it is optional (it can layer directly on IP). UDP encapsulation is also optional in v3. UDP encapsulation is useful for NAT traversal, but it increases overhead and lowers throughput and reliability. If no NAT needs to be traversed, turning off the UDP encapsulation can lower overhead. Session ID and Control Connection IDs are 32 bits (vs. 16 in L2TPv2). L2TPv3 also provides better user authentication, and data channel security through use of optional cookies. An L2TPv3 cookie is an up to 64 bit cryptographically generated random value, included in every packet. L2TPv3 is close to meeting all softwires requirements.
* RFC 4935, “Softwire Problem Statement”, July 2007 (Informational)
* RFC 5512, “The BGP Encapsulation Subsequent Address Family Indicator (SAFI) and the BGP Tunnel Encapsulation Attribute”, April 2009 (Standards Track)
* RFC 5543, “BGP Traffic Engineering Attribute”, May 2009 (Standards Track)
* RFC 5549, “Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop”,
May 2009 (Standards Track)
* RFC 5565, “Softwire Mesh Network”, June 2009 (Standards Track)
* RFC 5566, “BGP IPsec Tunnel Encapsulation Attribute”, June 2009 (Standards Track)
* RFC 5571, “Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)”, June 2009 (Standards Track)
* RFC 5619, “Softwire Security Analysis and Requirements”, August 2009 (Standards Track)
* RFC 5640, “Load-Balancing for Mesh Softwires”, August 2009 (Standards Track)
There are a lot of IETF drafts related to softwires (this is a hot area of Internet development):
* draft-arifumi-softwire-dslite-global-addr-00, “Global IPv4 Address Configuration for DS-Lite”, 2010-03-01
* draft-boucadir-softwire-cgn-bypass-01, “Procedure to bypass DS-lite AFTR”, 2010-03-05
* draft-cui-softwire-pet-02, “IPv4/IPv6 Coexistence Framework (PET)”, 2010-03-10
* draft-cui-softwire-pet64-00, “PET for IPv6 to IPv4 communication”, 2009-10-19
* draft-despres-softwire-mesh-sam-01, “Stateless Address Mapping (SAM) – Mesh Softwires without e-BGP”, 2009-10-26
* draft-despres-sofwire-sam-00, “Stateless Address Mapping (SAM) for Softwire-Lite Solutions”, 2010-03-01
* draft-donnerhacke-softwire-ipv6-6to4-00, “More specific unicast routing for 6to4”, 2009-11-26
* draft-gundavelli-softwire-gateway-init-ds-lite-03, “Gateway Initiated Dual-Stack Lite Deployment”, 2010-03-08
* draft-gui-softwire-6rd-ipv6-config-00, “IPv6 Host Configuration in 6rd Deployment”, 2010-03-01
* draft-guo-softwire-auto-gre-00, “Auto GRE Tunnel for Hub and Spoke Softwire”, 2009-10-19
* draft-guo-softwire-sc-discovery-03, “Softwire Concentrator Discovery Using DHCP”, 2010-03-05
* draft-ietf-softwire-ds-lite-tunnel-option-02, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Options for Dual-Stack Lite”, 2010-03-02
* draft-ietf-softwire-dual-stack-lite-04, “Dual Stack Lite Broadband Deployments Following IPv4 Exhaustion”, 2010-03-08
* draft-ietf-softwire-ipv6-6rd-08, “IPv6 via IPv4 Service Provider Networks ‘6rd’”, 2010-03-23
* draft-ietf-softwire-6rd-udp-00, “UDP Encapsulation of 6rd”, 2009-10-18
* draft-sarikaya-softwire-dslitemobility-01, “Dual-stack Lite Mobility Solutions”, 2009-10-20
* draft-wing-softwire-4over6multicast-02, “Port Control Protocol (PCP)”, 2010-03-08
* draft-xu-softwire-4over6multicast-02, “Softwire Mesh Multicast”, 2010-03-08
* draft-xu-softwire-tunnel-endpoint-01, “Simple Tunnel Endpoint Signaling in BGP”, 2010-02-22
PET (Prefixing, Encapsulation and Translation)
One of the emerging softwire standards, which is trying to work out the optimal combination of tunneling and translation mechanisms to provide a workable framework for IPv4/IPv6 co-existence. The types of tunnels discussed are:
* IP-in-IP tunnels (RFC 2893, RFC 4213)
* GRE tunnel (RFC 1702)
* 6to4 tunnel (RFC 3056)
* 6over4 tunnel (RFC 2529)
* Softwire transition technique (RFC 5565)
The translation mechanisms discussed include:
* SIIT (RFC 2765)
* NAT-PT (RFC 2766 - deprecated)
* BIS (RFC 2767)
* SOCKS64 (RFC 3089)
* BIA (RFC 3338)
* IVI (draft-xli-behave-ivi)
The draft discusses various combinations of the above tunneling and translation mechanisms to accomplish different kinds of co-existence. The recommended tunneling scheme is Softwire transition technique (RFC 5565). It also notes that DNS may have to interact with the co-existence solution using a DNS Application Layer Gateway, such as DNS64.
7.5 – Translation
Translation between IPv4 and IPv6 is by far the most complex transition mechanism. It has all the issues of IPv4 to IPv4 Network Address Translation, plus new issues that complicate it even further. There is a great deal of activity in the IETF trying to create standards that will be implementable and deployable.
Since IPv4 addresses are running out, many ISPs would like to deploy IPv6-only service to their customers (as opposed to dual-stack with both IPv4 and IPv6 service). Without translation, an IPv6-only node cannot access legacy IPv4-only nodes on the First Internet (which currently includes most online sites). Over time, more and more sites and services will be dual-stack, which will make IPv6-only nodes more useful. Until that time, translation gateways will be needed for IPv6-only nodes. It will be far simpler and cheaper, resulting in a superior user experience if both IPv4 and IPv6 are deployed, even if the IPv4 service is heavily NATted. However, ISPs seemed to be obsessed with deploying translation. There are a variety of ways that this can be accomplished, but most are quite complex and likely to be major sources of problems.
Tunneling cannot achieve IPv4 to IPv6 interworking, but it’s highly transparent and lightweight, can be implemented by hardware, and can keep IPv4 routing and IPv6 router separated. It allows existing infrastructure (whether IPv4 or IPv6) to be used as a transport to link two nodes (or networks) using the other version of IP.
Translation achieves direct intercommunication between IPv4 and IPv6 nodes or networks by means of converting the semantics between IPv4 and IPv6. However it has limitations in operational complexity and scalability. Like any NAT, it may have serious issues with transparency (some protocols may not work through it). Correct translation requires:
* address or (address, port) tuple substitution
* MTU discovery
* fragmentation when necessary
* Translation of both IP and ICMP fields
* ICMP address substitution in payloads (e.g. with SIP)
* IP/TCP/UDP checksum recomputation
* Application Layer translation when necessary
Stateless translation consumes IPv4 addresses to satisfy IPv6 hosts, which does not scale (for one thing we are running out of IPv4 addresses, for another, there are lots more IPv6 addresses than IPv4 addresses). It can be implemented in hardware, but any ALG translation is too complex for hardware.
Stateful translation requires maintaining complex state for dynamic mapping of (address, port) tuples, and cannot be implemented in hardware.
* RFC 2765, “Stateless IP/ICMP Translation Algorithm (SIIT)”, February 2000 (Standards Track)
* RFC 2766, “Network Address Translation – Protocol Translation (NAT-PT)”, February 2000 (Standards Track – Deprecated)
* RFC 2767, “Dual Stack Hosts using the “Bump-In-the-Stack” Technique (BIS)”, February 2000 (Informational)
* RFC 3089, “A SOCKS-based IPv6/IPv4 Gateway Mechanism”, April 2001 (Informational)
* RFC 4787, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP”, January 2007 (Best Current Practices)
* RFC 4864, “Local Network Protection for IPv6”, May 2007 (Informational)
* RFC 5382, “NAT Behavioral Requirements for TCP”, October 2008 (Best Current Practice)
* RFC 5508, “NAT Behavioral Requirements for ICMP”, April 2009 (Best Current Practice)
* draft-ietf-behave-v6v4-xlate-18, “IP/ICMP Translation Algorithm”
* draft-xli-behave-ivi-07, “The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Translation”, 2010-01-06
* draft-ietf-behave-dns64-09, “DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Serves”, 2010-03-30
* draft-ietf-behave-v6v4-xlate-stateful-11, “Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers”, 2010-03-30
* draft-ietf-behave-address-format-07.txt, “IPv6 Addressing of IPv4/IPv6 Translators”, 2010-04-09
* draft-ietf-behave-v6v4-framework-08, “Framework for IPv4/IPv6 Translation”, 2010-03-22
* draft-haddad-mext-nat64-mobility-harmful-00, “A Note on NAT64 Interaction with Mobile IPv6”, 2009-10-11
* draft-chen-behave-olnat-01, “A Optimal Load-balance mechanism for NAT64 (OL-NAT)”, 2009– 10-26
* draft-wang-behave-nat64-load-balancer-01, “Some Considerations on the Load-Balancer for NAT64”, 2010-02-21
* draft-wing-behave-nat64-referrals-01, “Referrals Across an IPv6/IPv4 Translator”
RFC 4864, “Local Network Protection for IPv6” makes a very strong case against use of NAT in IPv6, which was designed with the express intention of making NAT unnecessary. It shows how simple IPv6 mechanisms can provide all of the perceived benefits of NAT in existing IPv4 networks, without recourse to NAT.
RFC 2765, “Stateless IP/ICMP Translation Algorithm (SIIT)”, is used in NAT-PT, IVI and NAT64/DNS64. It is not a candidate itself for v6->v4 translation, but is included to help understand other more complete mechanisms.
RFC 2766, “Network Address Translation – Protocol Translation (NAT-PT)”, is not a viable candidate, as so many problems have been encountered that it has been officially deprecated to historic status by the IETF.
RFC 3089, “A SOCKS-based IPv6/IPv4 Gateway Mechanism” is not a viable candidate, because it requires “socksification” (modifications to the source code to insert a SOCKS layer between all system calls and the socket API) of all software applications that need to use the gateway.
IVI (currently described in draft-xli-behave-07) is a potentially viable candidate for v6->v4 translation, as it has been used extensively in CERNET in China, to allow IPv6-only clients to access IPv4-only servers. Since this mechanism is still in Internet Draft form, it should be considered experimental, and not for deployment in critical infrastructure.
NAT64/DNS64 (currently described in draft-ietf-behave-v6v4-xlate-stateful-11 and draft-ietf-behave- dns64-09) are a potential candidate for v6->v4 translation, and an open source implementation is available from gogo6. Since these mechanisms are still in Internet Draft form, they should be considered experimental, and not for deployment in critical infrastructure.
7.5.1 – NAT64 / DNS64
This translation mechanism requires both a NAT64 gateway and either a DNS server that supports DNS64 mapping, or a DNS ALG that supports DNS64. What follows is a highly simplified description of operation. The full details are covered in the Internet Draft (there is quite a bit of complexity involved in the real operation).
The NAT64 gateway should have two interfaces, one connected to the IPv4 network (with a valid IPv4 address on that network), and the other connected to the IPv6 network (with a valid IPv6 address on that network). IPv6 traffic from a node on the IPv6 network going to an IPv4 node is sent in IPv6 and routed to the NAT64 gateway. The gateway does address translation and forwards the translated packets to the IPv4 interface, from which it is routed to the destination node. Reply packets from the IPv4 node are sent in IPv4 to the gateway, are translated into IPv6 and forwarded to the IPv6 interface, from which they are routed back to the original sender. This process requires state, binding an IPv6 address and TCP/UDP port (referred to as an IPv6 transport address) to an IPv4 address and TCP/UDP port (referred to as an IPv4 transport address).
Packets that originate on the IPv4 side cannot be correctly translated, because there would be no state from the packets coming through the gateway in the v6->v4 direction. NAT654 is not symmetric. For traffic initiated by an IPv6 node, everything works right. Once the binding is created, that traffic flow can continue (from the IPv6 node to the IPv4 and back).
For the traffic originating on the IPv4 side to be translated to IPv6 requires some additional mechanism, such as ICE or a static binding configuration.
This mechanism depends on constructing IPv4-Converted IPv6 addresses (defined in draft-ietf-behave- address-format-nn). Each IPv4 address is mapped into a different IPv6 address by concatenating a special IPv6 prefix assigned to the NAT64 device (Pref64::/n).
It also uses a small pool of IPv4 addresses, from which mappings will be created and released dynamically, as needed (as opposed to permanently binding specific IPv4 addresses to specific IPv6 addresses). This implies that NAT64 does both address and port translation.
When an IPv6 initiator does a DNS lookup to learn the address of the responder, DNS64 is used to synthesize AAAA resource records from A resource records. The synthesized AAAA resource records are passed back to the IPv6 initiator, which then initiates an IPv6 connection with the Ipv6 address that is associated with the Ipv4 receiver. The packet will be routed to the NAT64 device, which will create the IPv6 to IPv4 address mapping as described before.
In general dual-stack nodes should not use DNS64. If they get a synthesized IPv6 address and a native IPv4 address, the rule to prefer IPv6 will cause the dual-stack host to do the access via the NAT64 gateway instead of direct using IPv4. If you deploy DNS64, it should be used only by IPv6-only nodes, and there should be a regular DNS for use by any dual-stack nodes.
7.5.2 – IVI
This address translation scheme is being used on a large scale between CERNET (IPv4-only) and CERNET2 (IPv6-only) to nodes on either side to connect to nodes on the other side, as well as allowing IPv6-only nodes connect to IPv4 nodes out on the public Internet.
The pros of using IVI are as follows:
* It is stateless, so it scales to large number of nodes better than NAT64 / DNS64
* The translation is decoupled from DNS
* It is symmetric, so can be used for connections initiated on either side of the gateway (IPv4 to
IPv6 side, or IPv6 to IPv4 side)
* There is an open source implementation of the IVI gateway and DNS64 ALG available on Linux.
The cons of using IVI are as follows:
* An ALG is still required for any protocol that embeds IP addresses in the protocol, such as SIP.
* It restricts the IPv6 hosts to use a subset of the addresses inside the ISP’s IPv6 block. Therefore, IPv6 Stateless Address Autoconfiguration cannot be used to assign IPv6 addresses to nodes. You must either manually assign addresses, or use stateful DHCPv6.
* There are still some issues with end-to-end transparency, address referrals and incompatible semantics between protocol versions.
* You still need a DNS64 ALG for DNS.
7.6 – Recommendations on Transition Mechanisms
There are so many problems with scalability, stability, transparency, and need for nonstandard infrastructure (e.g. DNS64), possibly not being able to use Stateless Address Autoconfiguration, that if at all possible, you should avoid using translation. It is not difficult to deploy dual-stack in your LAN (either using conventional Dual Stack, or Dual-Stack Lite if that is what your ISP provides). The complexity from running two parallel networks (IPv4 and IPv6) on the same infrastructure is minor compared to the issues from using translation. If direct dual stack ISP service is available, then definitely you should deploy dual-stack in your network. If not, you can easily tunnel in IPv6 service to a gateway router/firewall and route it into your network alongside existing IPv4.
If you restrict those protocols that don’t work well with NAT to run only on the IPv6 side (e.g. SIP, IPsec VPN, P2P, etc), then the IPv4 side can have addresses that are heavily (even multiply) NATted, so there is no problem finding addresses for the IPv4 side, even after the IPv4 address space is depleted. Legacy applications that work well even over NAT can be run over the IPv4 side until there are time and resources available to migrate them to IPv6.
Virtually all modern operating systems support dual-stack today. Most Microsoft products (client and server) have good support for dual-stack. Most open-source applications support it very well.
All standard infrastructure can be used – no need for NAT specific variants of things like DNS.
If you have to use translation, IVI is probably the least of several evils, and has a track record of working well on a large scale in CERNET / CERNET2 in China. You should plan on using stateful DHCPv6 to assign addresses (since Stateless Address Autoconfiguration won’t work). You should deploy client nodes with only IPv6, and depend on access via the IVI gateway for any IPv4 access. You will still have issues with SIP over IPv4, so you should either plan on using SIP only over IPv6, or deploy a SIP ALG to resolve the issues with addresses in the protocol.