Internet Engineering Task Force R. Despres Internet-Draft April 7, 2009 Intended status: Informational Expires: October 9, 2009 IPv6 Rapid Deployment on IPv4 infrastructures (6rd) draft-despres-6rd-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 9, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like Despres Expires October 9, 2009 [Page 1]

Internet-Draft 6rd - IPv6 Rapid Deployment April 2009 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. Despres Expires October 9, 2009 [Page 2]

Internet-Draft 6rd - IPv6 Rapid Deployment April 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem statement and purpose of 6rd . . . . . . . . . . . . . 5 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Applicability to ISPs that assign private IPv4 addresses . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Despres Expires October 9, 2009 [Page 3]

Internet-Draft 6rd - IPv6 Rapid Deployment April 2009 1 . Introduction Despres Expires October 9, 2009 [Page 4]

Internet-Draft 6rd - IPv6 Rapid Deployment April 2009 Readers are supposed to be familiar with 6to4 [RFC3056]. 2 . Problem statement and purpose of 6rd Despres Expires October 9, 2009 [Page 5]

Internet-Draft 6rd - IPv6 Rapid Deployment April 2009 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: 1. Packets that, coming from the global Internet, enter 6rd gateways of an ISP are only packets destined to customer sites of this ISP. 2. 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. 3 . Specification Despres Expires October 9, 2009 [Page 6]

Internet-Draft 6rd - IPv6 Rapid Deployment April 2009 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. IPv4 AND IPv6 customer site | | 6rd CPEs 6rd relays | (modified 6to4) (modified 6to4) | | | | | __________________________ | | | | | | | | | ISP IPV4 INFRASTRUCTURE | V GLOBAL V V | | ___ IPV6 ___ | | | | INTERNET | | | | .-----------------|--| |--- |--| |--|-. / | |___| | |___| | \ / | | \ / IPv4 | IPv6 Prefix | O anycast address => | <= of 6rd relays | ___ | / \ of 6rd relays | of the ISP | | | | / \ | ___ |--| |--|-' \ | | | | |___| | '-----------------|--| |--- | | | |___| | IPv4 addresses | | <= of customer sites | |__________________________| ISP ARCHITECTURE TO DEPLOY IPV6 WITH 6rd Figure 2 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. Despres Expires October 9, 2009 [Page 7]

Internet-Draft 6rd - IPv6 Rapid Deployment April 2009 Figure 2 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 [RFC3056] section 5.3.) 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 [RFC3068]. 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. 4 . Applicability to ISPs that assign private IPv4 addresses Despres Expires October 9, 2009 [Page 8]

Internet-Draft 6rd - IPv6 Rapid Deployment April 2009 If an ISP has assigned to customer sites addresses of an IPv4 private space of [RFC1918], 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 which 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. 5 . Security Considerations RFC3964]. 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: o CPE PACKETS TOWARD THE INTERNET: The IPv6 source must be, and the IPv6 destination must no be, a 6rd address of the site. o 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. o CPE PACKETS FROM THE INTERNET: If the IPv4 source is the 6rd- relays 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. o 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. (Notes: 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, Despres Expires October 9, 2009 [Page 9]

Internet-Draft 6rd - IPv6 Rapid Deployment April 2009 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. 6 . IANA Considerations 7 . Acknowledgements 8 . References 8.1 . Normative References RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Despres Expires October 9, 2009 [Page 10]