GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5569

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5569.txt · Last modified: 2010/01/22 18:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki