summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5569.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5569.txt')
-rw-r--r--doc/rfc/rfc5569.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc5569.txt b/doc/rfc/rfc5569.txt
new file mode 100644
index 0000000..aafdd0c
--- /dev/null
+++ b/doc/rfc/rfc5569.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Independent Submission R. Despres
+Request for Comments: 5569 RD-IPtech
+Category: Informational January 2010
+ISSN: 2070-1721
+
+
+ IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
+
+Abstract
+
+ IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon
+ mechanisms of 6to4 to enable a service provider to rapidly deploy
+ IPv6 unicast service to IPv4 sites to which it provides customer
+ premise equipment. Like 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.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any
+ other RFC stream. The RFC Editor has chosen to publish this
+ document at its discretion and makes no statement about its value
+ for implementation or deployment. Documents approved for
+ publication by the RFC Editor are not a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5569.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres Informational [Page 1]
+
+RFC 5569 6rd - IPv6 Rapid Deployment January 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 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
+ (http:trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Problem Statement and Purpose of 6rd ............................3
+ 3. Specification ...................................................4
+ 4. Applicability to ISPs That Assign Private IPv4 Addresses ........7
+ 5. Security Considerations .........................................8
+ 6. IANA Considerations .............................................8
+ 7. Acknowledgements ................................................9
+ 8. References ......................................................9
+ 8.1. Normative References .......................................9
+ 8.2. Informative References .....................................9
+
+1. Introduction
+
+ 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):
+
+ 1. obtained from its regional Internet Registry (RIR) an IPv6
+ prefix, the length of which was that allocated without a
+ justification and a delay to examine it, namely /32;
+
+ 2. added 6rd support to the software of its Freebox home-gateway
+ (upgrading for this an available 6to4 code);
+
+ 3. provisioned PC-compatible platform with a 6to4 gateway software;
+
+ 4. modified it to support 6rd;
+
+ 5. tested IPv6 operation with several operating systems and
+ applications;
+
+ 6. finished operational deployment, by means of new version of the
+ downloadable software of their Freeboxes;
+
+
+
+Despres Informational [Page 2]
+
+RFC 5569 6rd - IPv6 Rapid Deployment January 2010
+
+
+ 7. 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 (CPE) to their clients, with included routing
+ capability, 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). A few
+ months later, after Free had detailed its achievement and plans to
+ its RIR, and then obtained from it a /26 prefix, up to 16 IPv6 links
+ per customer became possible (with /60 site-prefix assignments).
+
+ Readers are supposed to be familiar with 6to4 [RFC3056].
+
+2. Problem Statement and Purpose of 6rd
+
+ 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 and can operate gateways between their IPv4
+ infrastructures and the global IPv6 Internet to support IPv6
+ encapsulation in IPv4. They then need no more routing plans than
+ those that exist on these IPv4 infrastructures.
+
+
+
+
+
+Despres Informational [Page 3]
+
+RFC 5569 6rd - IPv6 Rapid Deployment January 2010
+
+
+ Encapsulation a la 6to4, as specified in [RFC3056], 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. The problem is that 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. There is no
+ guarantee that routes toward such a relay exist from everywhere, nor
+ is there a guarantee that all such relays do forward packets toward
+ the complete IPv4 Internet.
+
+ Also, if an ISP operates one or several 6to4 relay routers and opens
+ IPv6 routes toward them in the IPv6 Internet, for the 6to4 prefix
+ 2002::/16, it may receive in these relays packets destined to an
+ unknown number of other 6to4 ISPs. If it doesn't forward these
+ packets, 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:
+
+ 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
+
+ The principle of 6rd is that, to build on 6to4 and suppress its
+ limitation, it is sufficient that:
+
+ 1. 6to4 functions are modified to replace the standard 6to4 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.
+
+
+
+Despres Informational [Page 4]
+
+RFC 5569 6rd - IPv6 Rapid Deployment January 2010
+
+
+ 2. The ISP operates one or several 6rd gateways (upgraded 6to4
+ routers) at its border between its IPv4 infrastructure and the
+ IPv6 Internet.
+
+ 3. CPEs support IPv6 on their customer-site side and support 6rd
+ (upgraded 6to4 function) on their provider side.
+
+ Figure 1 shows how the IPv6 prefix of a customer site is derived from
+ its IPv4 address.
+
+ +---------------//-------.------------------------------+
+ | 6rd-relays IPv6 prefix | IPv4 address |
+ | of the ISP | of the customer site |
+ +---------------//-------'------------------------------+
+ <-- less or equal to 32 -><------------ 32 ------------->
+ <-- less or equal to 64 ------------------------------->
+
+ Figure 1: Format of the IPv6 Prefix Assigned to a 6rd Customer Site
+
+ Figure 2 shows which nodes have to be upgraded from 6to4 to 6rd, and
+ which addresses or prefixes have to be routed to them.
+
+ 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 |
+ |__________________________|
+
+ Figure 2: ISP Architecture to Deploy IPv6 with 6rd
+
+
+
+
+Despres Informational [Page 5]
+
+RFC 5569 6rd - IPv6 Rapid Deployment January 2010
+
+
+ NOTE: The chosen address format uses 32 bits of IPv4 addresses in
+ IPv6 addresses for reasons of simplicity and of compatibility with
+ the existing 6to4 code. Limiting initially Free's customer sites to
+ one IPv6 subnet per site, a consequence of Free's initial prefix
+ being a /32, was not a significant restriction: since Free's
+ customers are essentially residential, most of them would have been
+ unable to use several subnets anyway, and as soon as Free would get a
+ prefix shorter than /32, this restriction would be relaxed. If it
+ had been important to immediately 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 could for this have implemented variable-length
+ mapping table. But some of the IPv4 addressing entropy would thus
+ have been extended to 6rd gateways and CPEs. Complexity being then
+ significantly higher, this would have defeated the objective of
+ extreme simplicity to favor actual and rapid deployment.
+
+ 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 [RFC3056].)
+
+ 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.201 address, routed with the same /24 prefix as 6to4 but
+ with 201 instead of 1 to avoid confusion with 192.88.99.1, the 6to4
+ anycast address of [RFC3068]. Another possibility, not retained,
+ would have been 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
+ starts with 2002::/16, the packet is 6to4, not 6rd.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres Informational [Page 6]
+
+RFC 5569 6rd - IPv6 Rapid Deployment January 2010
+
+
+4. Applicability to ISPs That Assign Private IPv4 Addresses
+
+ ______________________________
+ | |
+ | 10.x.x.x/8 private addresses |
+ | <== |
+ <-----| IPv4 anycast address |----->
+ | of 6rd relays |
+ 6rd-CPEs | ==> | 6rd-relays
+ | |
+ <-----| 0.0.0.0/0 |----->
+ | : |
+ |______________V_______________|
+ __|__
+ ISP-supported NAT(s) | |
+ |_____|
+ |
+ V
+ IPv4 public addresses
+
+ Figure 3: 6rd Applicability to ISPs That Assign
+ IPv4 Private Addresses
+
+ Free currently offers a global IPv4 address to each of its
+ subscribers, which ensures that all IPv4-derived prefixes using 6rd
+ are unique. Service providers may no longer have this luxury as
+ available global IPv4 addresses become more and more scarce. This
+ section describes how 6rd could be used by a service provider who
+ cannot provide global IPv4 addresses to each subscriber.
+
+ If an ISP has assigned to customer sites addresses of an IPv4 private
+ space of [RFC1918], typically 10.x.x.x 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.
+
+ It can be noted that in this case, the 10.0.0.0/8 prefix is common to
+ all IPv4 addresses of the addressing domain in which 6rd is used.
+ Knowing it, gateways and CPEs could avoid including this constant
+ IPv4 prefix in IPv6 prefixes, and thus reduce to 24 the number of
+ bits of IPv4 addresses that are included in IPv6 prefixes (but this
+ was not applicable to Free).
+
+
+
+
+
+
+
+Despres Informational [Page 7]
+
+RFC 5569 6rd - IPv6 Rapid Deployment January 2010
+
+
+ It can also be noted that, if an ISP is large enough to provide
+ service to more IPv4 endpoints than will fit inside a single
+ 10.0.0.0/8 addressing domain, it can configure several such domains,
+ with 6rd-relay IPv6 prefixes specific of each one. Each of these
+ prefixes is then the RIR-allocated ISP prefix followed by a domain
+ identifier chosen by the ISP.
+
+5. Security Considerations
+
+ Security considerations for 6to4 are documented in [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 not 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-
+ 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 (is the IPv6 prefix
+ of 6rd relays of the ISP followed by the IPv4 address).
+
+ 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. 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.
+
+ 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, independently of the above
+ precautions.
+
+6. IANA Considerations
+
+ 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.
+
+
+
+
+
+
+
+
+Despres Informational [Page 8]
+
+RFC 5569 6rd - IPv6 Rapid Deployment January 2010
+
+
+ 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.
+
+7. Acknowledgements
+
+ 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 immediately implement it for a very
+ rapid deployment on Free's operational network.
+
+ Mark Townsley, Brian Carpenter and Patrick Grossetete have to be
+ thanked for their encouragements, and for their suggestions on how to
+ proceed for 6rd to be known in the 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.
+
+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.
+
+8.2. Informative References
+
+ [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+ E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, February 1996.
+
+ [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
+ RFC 3068, June 2001.
+
+ [RFC3964] Savola, P. and C. Patel, "Security Considerations for
+ 6to4", RFC 3964, December 2004.
+
+
+
+
+
+
+
+Despres Informational [Page 9]
+
+RFC 5569 6rd - IPv6 Rapid Deployment January 2010
+
+
+Author's Address
+
+ Remi Despres
+ RD-IPtech
+ 3 rue du President Wilson
+ Levallois,
+ France
+
+ Phone: +33 6 72 74 94 88
+ EMail: remi.despres@free.fr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres Informational [Page 10]
+