|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
Over the past couple of years quite a few transition mechanisms and models have been created to ease the deployment of IPv6 into ISPs and enterprises. Some of the recent ones have very similar names, and can be easily confused with each other. I'm going to attempt to summarize them all here as concisely as possible in my own words, and possibly put them in some sort of logical order (or not).
(Update: Added 6rd and DS-Lite!)
Request for Comments: 3056
Summary: 6to4 is probably the oldest and original IPv6 transition mechanisms. It essentially allows any host with only IPv4 connectivity to communicate with IPv6 hosts using 6in4 (IPv4 protocol number 41) tunnels through one or many public 6to4 relays operated on the Internet. Each IPv4 host using 6to4 assigns itself a prefix out of 2002::/16 in the form of 2002:<IPv4 address in hex>::/48. It then forwards all (well, not 2002::/16) IPv6 traffic toward the nearest anycasted 6to4 relay (192.88.99.1).
Pros: Everything supports it, by now. It's fairly simple to setup.
Cons: Due to Internet routing issues, it's not guaranteed to work. Anycasting with BGP does not guarantee low latency. In fact, latency to the closest (AS_PATH speaking) 6to4 relay is often 100s of ms away! Whenever the host's IPv4 address changes, their whole IPv6 /48 based on that address must change, too. Also, 6to4 doesn't work through IPv4 NAT too well.
Request for Comments: 4213
Summary: 6in4 is a generic term that's used to describe the encapsulation of IPv6 packets in IPv4 packets with a protocol number of 41. In a sense, it's a manual version of 6to4, but much more flexible. In the case of two networks separated by the Internet, one dual-stack and one IPv4-only, one would build a 6in4 tunnel between the sites, and route IPv6 prefixes to the IPv4-only site to provide IPv6 connectivity. This is the main method of "do it yourself" IPv6 tunnels that are offered by several organizations (often called "tunnel brokers"). Hurricane Electric and SixXS (pronounced six-ess, like success) are two of the most popular organizations that offer these type of tunnel services with the main goal of providing end-users access to the IPv6 Internet.
Pros: It's quick and easy. Most public tunnel brokers will provide a /48 prefix of PA space to end-users.
Cons: By their definition, 6in4 tunnels are static, so the change of either IPv4 endpoints requires a re-build of the tunnel, or at the minimum a reconfiguration (although wrapping the 6in4 tunnel with OpenVPN eliminates this issue). MTU issues can exist, if both sides do not coordinate the setup correctly, or if the MTU along the path decreases in a failover scenario.
Request for Comments: 5214
Summary: ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) allows two dual-stack nodes to communicate via IPv6 over an IPv4-only network. ISATAP, geared toward enterprises, was developed by Microsoft, and views the IPv4 network as one big flat link layer for IPv6. ISATAP creates link-local addresses to be used on the virtual "link" by appending 0x5efe plus the host's IPv4 address. Global addresses can be assigned on the ISATAP link via autoconfiguration or DHCPv6, as well. Clients discover the ISATAP routers by performing an IPv4 DNS query for isatap.<domain> upon connection to the network. The IPv4 transport uses protocol number 41, just like 6to4 and 6in4.
Pros: It's fairly automatic and doesn't require any configuration on the client.
Cons: Relies on IPv4 DNS, which some folks consider a circular dependency. MTU issues could also exist.
Request for Comments: 4380
Summary: Teredo is a tunneling protocol that shares a similar goal with 6to4, yet uses UDP (port 3544) instead of 6in4 to improve NAT traversal. A Teredo client will contact a server and obtain a single address consisting of a combination of the client IPv4 address, source port number, Teredo server IPv4 address, and some flags. The server handles the first packet, and then directs the traffic through a Teredo relay that's closest (AS_PATH speaking) to the IPv6 host. Relays advertise 2001:0::/32 into BGP, and this is the prefix that Teredo addresses are built from.
Pros: Simple to setup (Windows Vista/7 enables it by default if no RAs are received). It works great through all sorts of NATs. Easy to troubleshoot since the same relay is used for communication in both directions.
Cons: Only one address is allocated per Teredo client. It's so easy to setup and works so well that it may inadvertently expose hosts on a secured IPv4 network to the IPv6 Internet.
IETF Internet-Draft: draft-shirasaki-nat444-isp-shared-addr-02
Summary: NAT444 is a model that ISPs can use to deploy IPv6 to both commercial and residential customers without removing IPv4 access or replacing CPE equipment with specialized hardware. CPE (customer premise equipment) hardware can be a standard Linksys router or something with more functionality and performance. Although NAT444 can be deployed commercially, it appears to be designed around residential customers (MSO/DSL). The customer's network in NAT444 is dual-stack, with the IPv6 prefix(es) being globally-unique and assigned by the MSO, and the IPv4 addresses chosen by the customer (or more likely, the default configuration of the CPE). The IPv6 traffic is routed natively by the CPE, via the provider's backbone toward Internet peers and on to the destination. However, the IPv4 traffic encounters NAT (or more accurately: NAPT) at both the CPE and what is generically termed an LSN (large scale NAT) or CGN (carrier-grade NAT) device at the provider's edge. IPv4 traffic is translated a total of two times before it reaches the Internet. The two layers of NAT are required because NAT444 may be deployed on a new ISP at a point in the evolution of the Internet where virtually all the IPv4 space has been exhausted, and there may be no way for the provider to allocate addresses beyond the bare minimum that are required for the LSN/CGN devices. The IETF draft mentions class-E (240/4) and RFC1918 addresses that are candicates that can be used on the ISP's backbone network.
Pros: Assuming more CPEs start featuring IPv6 functionality, NAT444 is the only model that doesn't require the replacement of the CPE with some specialized hardware (and most likely centrally-managed) from the ISP. No DNS or address family translation is needed, which avoids most of the headaches and complexity common with many other migration designs.
Cons: Where do I start? Performing two sets of NAPT ("double-natting") causes large problems with numerous applications ranging from online gaming to VoIP. Unsolicited inbound connectivity may be impossible unless the ISP decides to offer some sort of customer portal service that can be used to reserve a set of ports on one or more addresses in the LSN/CGN pool for the customer. Even with this, the customer will have to configure the port forwarding on the CPE device, too. Auditing is also difficult with NAT444 because hundreds or even thousand customers could be sharing one IPv4 address. This also opens the door for botnets and spam to potentially get one or more of the LSN/CGN pool addresses blacklisted by any number of centralized RBLs (using the term loosely) on the Internet, effectively denying service to all the other customers who may be translated to these addresses.
IETF Internet-Draft: draft-mrw-behave-nat66-02
Summary: NAT66 is a method of providing flexibility for the migration of IPv6 networks that do not qualify for PI (provider independent, or in other words: portable) space between ISPs. A small network is typically provided a block of PA (provider assigned, or in other words: not portable) space when purchasing service from an ISP. However, if the network needs to change ISPs, all hosts and network devices must be renumbered, a time-consuming and hellish process. NAT66 defines a unique translation method that performs NAT between hosts on an internal network to a prefix provided by an ISP or other upstream provider. The NAT66 device does not track sessions and does not perform port translation. Additionally, an "algorithmic" approach to address selection during NAT allows for the assignment of translated addresses that cause the original and translated packets to share the same checksum. Although any prefix can be used on the internal network, it is recommended to use ULA addresses to prevent conflicts. DNS configuration must be altered whenever the PA space changes.
Pros: Somewhat easy to immplement. No state needs to be maintained on the NAT66 device.
Cons: The PA prefix must be 48 bits or less, otherwise the original and translated packets may not share the same checksum, potentially breaking some IP security imeplementations. Just like with any NAT, applications that encode the host's source address in the payload of the packets (stream) will require additional configuration or ALGs (application-level gateways) that can aid the translation of the payload on-the-fly.
IETF Internet-Draft: draft-ietf-behave-v6v4-xlate-stateful-11
Summary: Very similar to NAT-PT (RFC 2766), which has since been deprecated, NAT64 provides a mechanism for IPv6-only hosts to communicate with IPv4-only hosts through a device that implements NAT64 assisted by a DNS server that implements DNS64. NAT64 is stateful, meaning that the NAT64 device keeps track of all connections, since the addresses on the IPv4 side of the NAT64 device are obviously in short supply, and must be overloaded, using port translation. DNS64 allows IPv6-only hosts to be provided synthesized AAAA RRs that actually point to IPv6 addresses with embedded IPv4 addresses. These addresses ultimately are routed to the NAT64 device that map connections to the IPv4 host in question. New connections initiated from IPv4-only clients back to IPv6-only clients are only allowed with the definition of static mappings and optionally custom DNS records (DNS64 does not help with this).
Pros: Provides a [better] replacement for NAT-PT and NAPT-PT.
Cons: It's complicated, and only works with TCP, UDP, and ICMP. The combination of having to synthesize AAAA RRs and maintain complex session state seems to make this setup quite fragile. Communication is also only one-way by default.
Request for Comments: 5569
Summary: 6rd stands for IPv6 Rapid Deployment. It's very similar to 6to4, and even uses the standard IP protocol 41 method to encapsulate the IPv6 packets into IPv4. However, it's different because it's only used within an ISP, which doesn't need to have a dual-stack backbone. An ISP first sets up a 6rd relay at their edge, and connects it to the IPv6 Internet. It then sets aside a prefix that will be used for 6rd, and the ISP's customers use this prefix + IPv4 address to build their own prefix that can be used for SLAAC internally. The ISP anycasts their 6rd relays and preconfigures the customer's CPEs (which ends up being just a modified 6to4 implementation) to connect to tunnel IPv6 traffic to this address. Traffic destined to this prefix (return traffic) from the Internet gets routed to the customers via the 6rd relays.
Pros: Easy to implement. No need to dual-stack the whole ISP's backbone. Does not imply the need for LSN/CGN.
Cons: The 6rd address space can't be a prefix longer than 32 bits. This requires the ISP to get a prefix shorter than a /32 from its RIR. Modification of CPEs is necessary.
IETF Internet-Draft: draft-ietf-softwire-dual-stack-lite-04
Summary: Dual-Stack Lite (or shortened to DS-Lite, and sometimes slightly incorrectly referred to as NAT464) is very similar to NAT444, with the exception that IPv4 NAT is only performed once, by the LSN/CGN at the ISP's edge. Just like NAT444, DS-Lite will most likely gain popularity once all free IPv4 blocks have been exhausted. Using a custom CPE running a piece of the AFTR software, IPv4 connections from a customer's network are tunnelled over the ISP's IPv6 backbone to the LSN/CGN, where connections reach the IPv4 Internet. So, essentially, DS-Lite is like NAT444, but the IPv4 connections across the ISP's backbone are tunnelled inside IPv6. The LSN/CGN devices also add the CPE's IPv6 address to the NAT translation table for IPv4 connections, since it's likely that many residences will overlap with each other's RFC1918 space.
Pros: Eliminates the issues associated with performing NAT twice. Requires very little IPv4 addresses.
Cons: CPEs must be replaced. This is a large undertaking. MTU issues may arise due to the IPv4 tunnelling.
New comments are currently disabled for this entry.
     |
This HTML for this page was generated in 0.002 seconds. |