[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 5569

Internet Engineering Task Force                               R. Despres
Internet-Draft                                          October 23, 2008
Intended status: Informational
Expires: April 26, 2009


          IPv6 Rapid Deployment on IPv4 infrastructures (6rd)
                          draft-despres-6rd-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 April 26, 2009.

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
   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 quasi-native
   IPv6, under the only condition that they activate it.





Despres                  Expires April 26, 2009                 [Page 1]


Internet-Draft         6rd - IPv6 Rapid Deployment          October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem statement and purpose of 6rd . . . . . . . . . . . . .  4
   3.  Specification  . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Remarks on utilization . . . . . . . . . . . . . . . . . . . .  7
     4.1.  6rd and ISPs that assign private IPv4 addresses  . . . . .  7
     4.2.  Deployment of native IPv6 after having deployed 6rd  . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10



































Despres                  Expires April 26, 2009                 [Page 2]


Internet-Draft         6rd - IPv6 Rapid Deployment          October 2008


1.  Introduction

   After having had a succinct presentation of the 6rd idea, a major
   French Internet service provider (ISP), Free of the Iliad group, did
   all of the following in an impressively short delay of only five
   weeks (November 7th to December 11th 2007):

   1.  obtain its first IPv6 prefix from its regional Internet Registry
       (RIR);

   2.  add 6rd support to the software of its Freebox home-gateway
       (upgrading for this an available 6to4 code);

   3.  provision PC-compatible platform with a 6to4 gateway software;

   4.  modify it to support 6rd;

   5.  test IPv6 operation with several operating systems and
       applications;

   6.  finish operational deployment, by means of new downloadable
       software for Freeboxes;

   7.  announce 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 to, with the same look and feel as with a purely
   native IPv6 solution.  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
   CPEs), and that have so far deffered 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.  Also, while IPv6 availability was in december 2007
   limited to only one IPv6 link per customer site (/64 site prefixes),
   it was upgraded to up to 16 IPv6 links per customer site (/60 site
   prefixes) when, a few months later, Free obtained a /28 prefix from
   its regional Internet registry.  (The /32 obtained initially was the
   default value an ISP could be assigned without delay).

   Readers are supposed to be familiar with 6to4 [RFC3056].



Despres                  Expires April 26, 2009                 [Page 3]


Internet-Draft         6rd - IPv6 Rapid Deployment          October 2008


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 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 be 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 to use 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 do the required
   IPv6/IPv4 encapsuation.  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.




Despres                  Expires April 26, 2009                 [Page 4]


Internet-Draft         6rd - IPv6 Rapid Deployment          October 2008


   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 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.

   2.  The ISP operates one or several 6rd gateways (upgraded 6to4
       routers) at its border between its IPv4 infrastructure and the
       IPv6 Internet.

   3.  CPE routers are IPv6 on their customer-site side and support 6rd
       (upgraded 6to4 function).

   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 ------->


             FORMAT OF THE IPV6 PREFIX ASSIGNED TO A 6RD CUSTOMER SITE

                                 Figure 1

   Figure 2 shows which nodes have to be upgraded from 6to4 to 6rd, and
   which addresses or prefixes have to be routed to them.





Despres                  Expires April 26, 2009                 [Page 5]


Internet-Draft         6rd - IPv6 Rapid Deployment          October 2008


          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

   Like with 6to4, IPv6 communication between customer sites is direct
   across the ISP IPv4 infrastructure.  It doesn't need to go through
   6rd relays.

   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.










Despres                  Expires April 26, 2009                 [Page 6]


Internet-Draft         6rd - IPv6 Rapid Deployment          October 2008


4.  Remarks on utilization

4.1.  6rd and ISPs that assign private IPv4 addresses

   If an ISP has assigned addresses of an IPv4 private space RFC 1918 to
   some customer sites (and operates IPv4 NATs in its infrastructure),
   it can also use 6rd to bring IPv6 to these sites.

   IPv4 packets that contain IPv6 packets don't go to NATs: they go
   directly to 6rd relays because of their destination being the 6rd
   relay anycast address.

4.2.  Deployment of native IPv6 after having deployed 6rd

   If an ISP has taken its only assigned IPv6 prefix as its 6rd relay
   prefix, it can still add native IPv6 routing to its infrastructure
   without conflict with 6rd addresses.

   For this, it is sufficient that all native IPv6 prefixes have 1110 as
   the 4 bits next to the IPv6 6rd relay prefix.  The reason is that:

   o  IPv4 addresses that are included in 6rd IPv6 addresses are, like
      in 6to4, only unicast addresses.

   o  1110 (i.e. 240.0.0.0/4) is, in IPv4, the prefix of multicast
      addresses [IPv4 addresses].

   Once native IPv6 has thus been brought to all its customer sites, the
   ISP can abandon all its support of 6rd.  After that, no restriction
   holds any longer on native IPv6 prefixes that may be assigned.


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 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



Despres                  Expires April 26, 2009                 [Page 7]


Internet-Draft         6rd - IPv6 Rapid Deployment          October 2008


      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 star 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,
      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.  Higher layers are then left, like with IPv4, with the
   responsibility to limit consequences.


6.  IANA Considerations

   6rd can be deployed by ISPs without needing any new assignment by
   IANA.


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 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.



8.  References







Despres                  Expires April 26, 2009                 [Page 8]


Internet-Draft         6rd - IPv6 Rapid Deployment          October 2008


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

   [IPv4 addresses]
              Internet Assigned Numbers Authority, "Internet Protocol v4
              Address Space - http://www.iana.org/assignments/
              ipv4-address-space/ipv4-address-space.xhtml",
              February 2008.

   [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.


Author's Address

   Remi Despres
   3 rue du President Wilson
   Levallois,
   France

   Phone: +33 6 72 74 94 88
   Email: remi.despres@free.fr















Despres                  Expires April 26, 2009                 [Page 9]


Internet-Draft         6rd - IPv6 Rapid Deployment          October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Despres                  Expires April 26, 2009                [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/