IPv6 Rapid Deployment (6rd) on IPv4 Infrastructures

After having had a succinct presentation of the 6rd idea, a major French Internet service provider (ISP), Free of the Iliad group (hereafter Free), did all of the following in an impressively short delay of only five weeks (November 7th to December 11th 2007): obtained its first IPv6 prefix from its regional Internet Registry (RIR); its length being 32, the length that was allocated without a justification and a delay to examine it; added 6rd support to the software of its Freebox home-gateway (upgrading for this an available 6to4 code); provisioned PC-compatible platform with a 6to4 gateway software; modified it to support 6rd; tested IPv6 operation with several operating systems and applications; finished operational deployment, by means of new downloadable software for Freeboxes; announced IPv6 Internet connectivity, at no extra charge, for all its customers wishing to activate it. More than 1,500,000 residential customers thus became able to use IPv6 if they wished, with all the look and feel of native IPv6 addresses routed in IPv6. The only condition was an activation of IPv6 in their Freeboxes, and of course in their IPv6-capable hosts. This story is reported to illustrate that ISPs that provide customer premise equipment to their customers with routing capability (router Customer Premises Equipment (CPEs)), and that have so far postponed IPv6 deployment can, with the dramatically reduced investment and operational costs that 6rd make possible, decide to wait no longer. To complete the story, Free announced, on March 6th 2008, that provided two of its customer sites had IPv6 activated, its Telesites application (Web sites published on TV) could now be used remotely between them. While IPv6 availability was limited in December 2007 to only one IPv6 link per customer site (with /64-site prefix assignments), it was upgraded a few months later to up to 16 IPv6 links (with /60 site prefix assignments), after Free had detailed its achievement and plans to its RIR and obtained from it a /26 prefix. Readers are supposed to be familiar with 6to4 .

Having ISPs to rapidly bring IPv6 to customers' sites, in addition to IPv4 and without extra charge, is a way to break the existing vicious circle that has delayed IPv6 deployment: ISPs wait for customer demand before deploying IPv6; customers don't demand IPv6 as long as application vendors announce that their products work on existing infrastructures (that are IPv4 with NATs); application vendors focus their investments on NAT traversal compatibility as long as ISPs don't deploy IPv6. But most ISPs are not willing to add IPv6 to their current offer at no charge, unless incurred investment and operational costs are extremely limited. For this, ISPs that provide router CPEs to their customers have the most favorable conditions: they can upgrade their router CPEs to support IPv6 encapsulation and operate gateways between these infrastructures and the global IPv6 Internet to also do IPv6/v4 encapsulation, so that they can keep the routing plan of their IPv4 infrastructures. Encapsulation a la 6to4 is very close to being sufficient for this: it is simple; it is supported on many platforms including PC-compatible appliances; open-source portable code is available; its stateless nature ensures good scalability. There is however a limitation of 6to4 that prevents ISPs from using it to offer full IPv6 unicast connectivity to their customers. While an ISP that deploys 6to4 can guarantee that IPv6 packets outgoing from its customer sites will reach the IPv6 Internet, and also guarantee that packets coming from other 6to4 sites will reach its customer sites, it cannot guarantee that packets from native IPv6 sites will reach them. A packet coming from a native IPv6 address needs to traverse, somewhere on its way, a 6to4 relay router to do the required IPv6/IPv4 encapsulation. The problem is that there is no guarantee to have a route toward such a relay from everywhere, nor is there a guarantee that all such relays do forward packets toward the complete IPv4 Internet. An ISP, if it operates one or several 6to4 relay routers and opens IPv6 routes toward them on the IPv6 Internet for the 6to4 prefix 2002::/16, may receive in these relays, packets destined to an unknown number of other 6to4 ISPs. If it doesn't forward them, it creates a black hole in which packets may be systematically lost, breaking some of the IPv6 connectivity. If it does forward them, it can no longer dimension its 6to4 relay routers in proportion to the traffic of its own customers. Quality of service, at least for customers of other 6to4 ISPs, will then hardly be guaranteed. The purpose of 6rd is to slightly modify 6to4 so that: Packets that, coming from the global Internet, enter 6rd gateways of an ISP are only packets destined to customer sites of this ISP. All IPv6 packets destined to 6rd customer sites of an ISP, and coming from anywhere else on the IPv6 Internet, traverse a 6rd gateway of this ISP.

The principle of 6rd is that, to build on 6to4 and suppress its limitation, it is sufficient that: 6to4 functions are modified to replace the standard prefix 2002::/16 by an IPv6 prefix that belongs to the ISP-assigned address space, and to replace the 6to4 anycast address by another anycast address chosen by the ISP. The ISP operates one or several 6rd gateways (upgraded 6to4 routers) at its border between its IPv4 infrastructure and the IPv6 Internet. CPE routers are IPv6 on their customer-site side and support 6rd (upgraded 6to4 function). shows how the IPv6 prefix of a customer site is derived from its IPv4 address.

<------------ 32 -------------> <-- less or equal to 64 -------------------------------> Format of the IPv6 Prefix Assigned to a 6rd Customer Site ]]> The chosen address format uses 32 bits of IPv4 address within the IPv6 address for reasons of simplicity and of compatibility with the existing 6to4 code. Free's customers being essentially residential, limiting initially their sites to one IPv6 subnet per site was not a significant restriction: most of them would not have been able to use several subnets anyway; as soon as Free would get shorter a prefix than /32, this restriction could be relaxed.

| <= of 6rd relays | ___ | / \ of 6rd relays | of the ISP | | | | / \ | ___ |--| |--|-' \ | | | | |___| | '-----------------|--| |--- | | | |___| | IPv4 addresses | | <= of customer sites | |__________________________| ISP Architecture to Deploy IPv6 with 6rd ]]> NOTE: If it had been important to use less than 32 bits of IPv4 addresses in IPv6 prefixes, this would have been possible. Since Free, like many ISPs, had several RIR-allocated IPv4 prefixes (6 of them, having lengths from /10 to /16 in the particular case), 6rd gateways and 6rd CPEs would however have had for this to support a variable-length mapping table. Some of the IPv4 addressing entropy would thus have been extended to 6rd gateways and CPEs, and complexity would have been significantly higher. This would have defeated the objective of extreme simplicity to favor actual and rapid deployment. shows which nodes have to be upgraded from 6to4 to 6rd, and which addresses or prefixes have to be routed to them. IPv6 communication between customer sites of a same ISP is direct across the ISP IPv4 infrastructure: when a CPE sees that the IPv6 destination address of an outgoing packet starts with its own 6rd relay ISPv6 prefix, it takes the 32 bits that follow this prefix as IPv4 destination of the encapsulating packet. (Sending and decapsulation rules of 6to4, duly adapted to the 6rd prefix in place of the 6to4 prefix, apply as described in Section 5.3 of .) The IPv4 anycast address of 6rd relays may be chosen independently by each ISP. The only constraint is that routes toward the ISP that are advertised must not include this address. For example, Free took a 192.88.99.k address, routed with the same /24 prefix as 6to4 but with k different from 1 to avoid confusion with the 6to4 address of . Another possibility is to use the anycast address of 6to4 and to add, in relays, a test on the IPv6 prefix of the ISP-side address. If it is 2002::/16, the packet is 6to4, not 6rd.

| of 6rd relays | 6rd-CPEs | ==> | 6rd-relays | | <-----| 0.0.0.0/0 |-----> | : | |______________V_______________| __|__ ISP-supported NAT(s) | | |_____| | V IPv4 public addresses 6rd Applicability to ISPs That Assign IPv4 Private Addresses ]]> If an ISP has assigned to customer sites addresses of an IPv4 private space of , typically 10.x.x.x/8 addresses, it can also use 6rd to offer IPv6 to these sites. IPv4 packets that contain IPv6 packets don't go to NATs that this ISP needs to operate in its infrastructure: they go directly to 6rd relays because their destination is the 6rd relay anycast address. Note that in this case, the 10.0.0.0/8 prefix is common to all IPv4 addresses of the addressing realm in which 6rd is used. Knowing it, gateways and CPE can avoid including this constant IPv4 prefix in IPv6 prefixes, and thus reduce to 24 the number of bits of IPv4 addresses to be used in IPv6 prefixes. If an ISP is large enough to provide service to more IPv4 endpoints than will fit inside a 10.x.x.x/8 addressing realm, it can configure several such realms, with 6rd-relay IPv6 prefixes specific of each one. Each of these prefixes is the RIR-allocated ISP prefix followed by an ISP-assigned realm identifier.

Security considerations for 6to4 are documented in . With the restriction imposed by 6rd that relays of an ISP deal only with traffic that belongs to that ISP, checks that have to be done become the following: CPE PACKETS TOWARD THE INTERNET: The IPv6 source must be, and the IPv6 destination must not be, a 6rd address of the site. RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd address that matches the IPv4 source. The IPv6 destination must not start with the ISP 6rd prefix. CPE PACKETS FROM THE INTERNET: If the IPv4 source is the 6rd-relay's anycast address of the local ISP, the IPv6 source must not be a 6rd address of this ISP. Otherwise, the IPv6 source must be the 6rd address that matches the IPv4 source. RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a 6rd address of the ISP. The IPv4 destination must not be multicast, i.e., must not start with 224/3. NOTE: The fact that the IPv6 destination starts with the IPv6 prefix of the ISP 6rd relays is ensured by the routing configuration, but may be double-checked. If the IPv4 address extracted from the IPv6 destination doesn't belong to the ISP, the destination CPE should detect that the IPv6 destination contains neither its ISP 6rd prefix, if it has one, nor the 6to4 prefix, and should discard the packet. These precautions being taken, it remains that, where IPv4 address spoofing is possible (IPv4 sites placing unauthorized source addresses in some packets they send), IPv6 address spoofing is also possible.

ISPs that provide CPEs to all their customers need no new number assignment by IANA. Their being allocated an IPv6 prefix by their RIR, /32 or shorter, is sufficient. For 6rd to be also used in the future by ISPs that let customers have their own CPEs, means to communicate 6rd parameters to these CPEs would be needed. If the IETF specifies such means for this, some number assignment by IANA is likely to be solicited, in a registry to be then defined.

The author warmly acknowledges the major contribution of Rani Assaf to 6rd's proven credibility. He readily appreciated 6rd's potential, and made the daring decision to rapidly implement it and deploy it on Free's operational network. Mark Townsley, Brian Carpenter and Patrick Grossetete have to be thanked for their encouragements and suggestions as to how to proceed in IETF. Acknowledgments are also due to some IPv6 old timers, in particular Laurent Toutain, Francis Dupont, and Alain Durand, who, when the author came as a late novice on IPV6, taught him a few subtleties of the subject. Without them, designing 6rd would probably not have been possible.