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

Versions: (draft--remi-despres--ipv6-rapid-deployment-) 00 01

Internet Engineering Task Force                               R. Despres
Internet-Draft                                                 RD-IPtech
Intended status: Informational                              May 10, 2008
Expires: November 11, 2008


          IPv6 Rapid Deployment on IPv4 infrastructures (6rd)
            draft-despres-v6ops-6rd-ipv6-rapid-deployment-01

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 November 11, 2008.

Abstract

   IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056)
   to enable a service provider to rapidly deploy IPv6 unicast service
   to its existing IPv4 sites.  Like 6to4, it utilizes stateless IPv6 in
   IPv4 encapsulation in order to transit IPv4-only network
   infrastructure.  Unlike 6to4, 6rd requires a service provider to use
   one of its own IP prefixes rather than the fixed 6to4 prefix.  A
   service provider has used this mechanism for its own "rapid
   deployment" of IPv6 (five weeks from first exposure to "opt-in"
   deployment for 1,500,000 residential sites).






Despres                 Expires November 11, 2008               [Page 1]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


Table of Contents

   1.  Introduction and 6rd purpose . . . . . . . . . . . . . . . . .  3
   2.  Specification  . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Participating entities and their addresses . . . . . . . .  4
     2.2.  Derivation of the 6rdSiteV6Prefix of a 6rd-site from
           its SiteV4Address  . . . . . . . . . . . . . . . . . . . .  6
       2.2.1.  General format . . . . . . . . . . . . . . . . . . . .  6
       2.2.2.  Simple format  . . . . . . . . . . . . . . . . . . . .  8
     2.3.  Encapsulations-decapsulations  . . . . . . . . . . . . . .  9
     2.4.  ICMP consideration . . . . . . . . . . . . . . . . . . . .  9
   3.  6rd Applicability to IPv4 private addresses  . . . . . . . . . 10
   4.  6rd-CPE parameters - the 6rd DHCPv4 option . . . . . . . . . . 11
   5.  6rd-relay implementation variants  . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   Appendix A.  PSEUDO-CODE EXAMPLE WITH SECURITY CHECKS FOR
                6RD-CPES  . . . . . . . . . . . . . . . . . . . . . . 14
   Appendix B.  PSEUDO-CODE EXAMPLE WITH SECURITY CHECKS FOR
                6RD-RELAYS  . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

























Despres                 Expires November 11, 2008               [Page 2]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


1.  Introduction and 6rd purpose

   After having had a succinct presentation of the 6rd idea, a major
   French Internet service provider (ISP), FREE , 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 of a few applications;

   6.  finish deployment;

   7.  announce IPv6 availability at no extra charge for all its
       customers wishing to have it.

   More than 1,500,000 residential customers thus became able to use
   IPv6 with the same look and feel as with any native IPv6 solutions.
   The only condition was a conscious activation of IPv6 in their
   Freeboxes and in their individual hosts.

   This story is reported to illustrate that ISPs that differ IPv6
   deployment, typically because of anticipated investment and
   operational costs, can, if circumstances are favorable, drastically
   reduce these costs and rapidly offer IPv6 to their customers.

   This first deployment had the limitation that customer site prefixes
   were 64 bit longs, which limited each of them to only one IPv6
   subnet.  The reason was that FREE, although it had several IPv4 ISP
   prefixes to support millions of customer sites, had only a /32 IPv6
   prefix.  With a shorter IPv6 prefix, as FREE has obtained one since
   then, multiple subnets are possible with 6rd.











Despres                 Expires November 11, 2008               [Page 3]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


   The purpose of this draft is that:

   o  Manufacturers of ISP-infrastructure routers, gateway devices, and
      router CPEs, can consider supporting 6rd-relay functions in their
      products.

   o  ISPs that have not offered IPv6 to their customers yet, or that
      did it only on a limited scale, can consider doing it on a large
      scale with 6rd, leaving for a later time generalization of more
      native IPv6 support.

   Readers are supposed to be familiar with IPv6 address formats and
   notation.


2.  Specification

2.1.  Participating entities and their addresses

   Figure 1 presents network entities that are concerned with 6rd.

   A "6rd-zone", or "zone" for short, is an IPv4 routing area to which
   are attached one or more 6rd-relays, and a number of customer sites.

   A "6rd-relay" performs encapsulation-decapsulation functions of IPv6
   in IPv4.  It is accessible on its IPv6 interface at the
   6rdRelayV6Prefix of the 6rd-zone, and on its IPv4 interface at the
   6rdRelayV4Address of the zone.  Its encapsulation and decapsulation
   functions being stateless, load sharing among several 6rd-relays is
   possible, even on a per packet basis.

   The "6rdRelayV6Prefix" of a 6rd-zone must be in the IPv6 address
   space of the ISP that controls the zone.  This is the essential
   difference with the 6to4 of [RFC3056].  It ensures that IPv6 traffic
   toward 6rd customer sites can be routed from ANY hosts that have IPv6
   connectivity, independently of how they have it (native IPv6, tunnel
   broker [RFC3056], softwires [RFC4925], Teredo [RFC4380], 6rd [this
   draft]...).

   The "6rdRelayV4Address" of a 6rd-zone is an IPv4 anycast address
   shared by all 6rd-relays of the zone.

   A "6rd-CPE" is a dual stack CPE (customer premise equipment) that
   supports 6rd.  It can be a host-only CPE, or a router CPE via which a
   number of other hosts access the Internet.

   A "6rd-site" is a customer site of a 6rd-zone the CPE of which is a
   6rd-CPE.  Within the CPE, both IPv4 and IPv6 applications can be



Despres                 Expires November 11, 2008               [Page 4]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


   supported.  If the 6rd-CPE is a router, it extends behind it its IPv6
   connectivity.

   The "SiteV4Address" of a 6rd-site is its IPv4 unicast address.

   The "6rdSiteV6Prefix" of a 6rd-site is implicitly derived from the
   SiteV4Addresss of the site and from parameters of the 6rd-zone
   according to Section 2.2.

   Between two customer sites of a same 6rd-zone, the IPv6 traffic is
   directly routed in IPv4 from one to the other.


      6rd-sites             6rd-zone
        __/\__     _____________/\______________
      /        \ /                               \           6rd-zone

      6rd-CPEs
         |                               6rd-relays
         |                               (stateless)
         V            (IPv4 routing)           |
                 _________________________     |
        IPv4    |                         |    V
       & IPv6   |                         |    ___
         _|__   <= SiteV4Address(X)       |   |   |
        | |  |  |        .----------------|---|   |----
        |  X |--|-.     /                 |   |___|
        |____|  |  \   /                  |          (IPv6 routing)
      Host-only |   \ /                   |
         CPE    |    O      6rdRelayV4Address => <= 6rdRelayV6Prefix
          ___   |   / \         (anycast) |
      |  |   |  |  /   \                  |    ___
      |--| Y |--|-'     \                 |   |   |
      |  |___|  |        '----------------|---|   |----
      |  Router <= SiteV4Address(Y)       |   |___|
      |   CPE   |                         |
      |         |_________________________|
      IPv4       IPV6 ENCAPSULATED IN IPV4
      & IPv6
             <= 6rdSiteV6Prefixes
                (derived from SiteV4Addresses and 6rd-zone parameters)


                          THE 6RD MODEL

                                 Figure 1





Despres                 Expires November 11, 2008               [Page 5]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


2.2.  Derivation of the 6rdSiteV6Prefix of a 6rd-site from its
      SiteV4Address

2.2.1.  General format

   Figure 2 shows how the 6rdSiteV6Prefix of a 6rd-site is derived from
   the SiteV4Address of the site.

   The parameters of the zone that influence the derivation are the
   following:

   1.  The "6rdZoneV6Prefix".  It is a prefix that, in the zone, will
       appear at the beginning of all 6rdSiteV6prefixes.

   2.  The "6rdZoneV4PrefixLength".  It is the length of an IPv4 prefix
       that, in the zone, appears at the beginning of all
       SiteV4Addresses.  If the ISP of the zone has only one IPv6 prefix
       allocated by its RIR, the length of this prefix SHOULD be taken
       as the 6rdZoneV4PrefixLength.  If the ISP has several IPv6
       prefixes, this length SHOULD be 0 (simple format case of
       Section 2.2.2).

   3.  The "6rdTag".  Defined only if the 6rdZoneV4PrefixLength is not
       0, it is a sequence of bits chosen by the ISP of the zone to
       appear, in all 6rdSiteV6Prefixes of the zone, immediately after
       the 6rdZoneV6Prefix.

   With these parameters, the 6rdSiteV6Prefix of a customer site is
   derived as follows:

   o  The "6rdZoneV6Prefix" is composed of the 6rdRelayV6Prefix of the
      zone(see Figure 1) followed by the 6rdTag.

   o  If "6rdSiteV4Suffix" of a site is composed of all bits that, in
      its SiteV4Address, come after the 6rdZoneV4PrefixLength.  (In the
      simple format case, where the 6rdZoneV4PrefixLength is 0, the
      6rdSiteV4Suffix is the full IPv4 address.)

   o  The "6rdSiteV6Prefix" is composed of the 6rdZoneV6Prefix of the
      zone followed by the 6rdSiteV4Suffix of the site.











Despres                 Expires November 11, 2008               [Page 6]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


   For example, if an ISP has QQQQ:Q000/20 as its only IPv4 prefix,
   PPPP:PPPP/32 as its only IPv6 prefix, and C000/4 as its chosen
   6rdTag, the 6rdSiteV6Prefix of a site that has QQQQ:QAAA as its
   SiteV4Address is PPPP:PPPP:TAAA/48.


          .-//---------.
          | R6P        |                   6rdRelayV6Prefix
          '-//---------'                   (zone parameter)
          .            .
          .            .-//--.
          .            |  T  |             6rdTag
          .            '-//--'             (zone parameter)
          .            .     .
          .-//---------+-----.
          | Z6P              |             6rdZoneV6Prefix
          '-//---------+-----'
          .                  .
          .-//---------------+-//------.
          | S6P                        |   6rdSiteV6Prefix
          '-//---------------+-//------'
                             .         .
                             .-//------.
                             | S4S     |   6rdSiteV4Suffix
                             '-//------'
                             .         .
              6rdZoneV4PrefixLength
                 (zone parameter)
                   <--------->         .
                   .         .         .
                   .---------+---------.
                   | S4A               |   SiteV4Address
                   '---------+---------'
                   <----- 32 bits ----->
                   .         .
                   .         .
                   .-//------.
                   | Z4P     |            6rdZoneV4Prefix
                   '-//------'


        RELATIONSHIPS BETWEEN IPv4-SITE-ADDRESSES AND 6RD-SITE-PREFIXES

                                 Figure 2







Despres                 Expires November 11, 2008               [Page 7]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


   Note that, even if the 6rdZoneV4Prefix is not a multiple of 4 bits,
   the 6rdTag can be chosen so that hexadecimal digits of IPv4 addresses
   are kept readable in 6rdSiteV6Suffixes.  For example, if the
   6rdZoneV4Prefix is QQQQ:QR00/22 (not a multiple of 4 bits), and if
   the 6rdRelayV6Prefix is PPPP:PPPP/32, by choosing TR00/6 as 6rdTag
   (purposely terminated with the same partial nibble of 4 bits as the
   6rdZoneV4Prefix), it is ensured that the 6rdSiteV6Prefix derived from
   SiteV4Address QQQQ:QXAA will be PPPP:PPPP:QXAA/48.

2.2.2.  Simple format

   If an ISP as several IPv4 prefixes, substituting the 6rdTag to the
   6rd-zoneV4Prefix in 6rdSiteV6Prefixes to shorten them is no longer
   possible, but the general relationship can be simplified, as shown on
   Figure 3.

   For example, if an ISP has several IPv4 prefixes and has PPPP:PP00/24
   as its 6rdRelayV6Prefix, the 6rdSiteV6Prefix derived from
   SiteV4Address AAAA:AAAA is PPPP:PPAA:AAAA:AA00/56.

   A limit case is that of an ISP that has several IPv4 prefixes but
   only a /32 IPv6 prefix.  It can deploy 6rd with /64 prefixes assigned
   to its 6rd-sites, but it should better ask for shorter an IPv6
   prefix, so that it can assign shorter than /64 prefixes to its
   customers sites and thus let them have several subnets per site.


       .-//-----------.                       6rdZoneV6Prefix
       | 6ZP          |                       (= 6rdRelayV6Prefix)
       '-//-----------'
       .              .
       .-//-----------+-------------------.
       | 6SP                              |   6rdSiteV6Prefix
       '-//-----------+-------------------'
                      .                   .
                      .-------------------.
                      |  4SA              |   SiteV4Address
                      '-|-----------------'
                        |
                  first 4 bits
                other than 1110

       RELATIONSHIPS BETWEEN IPv4-SITE-ADDRESSES AND 6RD-SITE-PREFIXES
                      (A)  SIMPLE PREFIX FORMAT


                                 Figure 3




Despres                 Expires November 11, 2008               [Page 8]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


   An ISP, , after having deployed IPv6 with the 6rd simple format, may
   wish to start deploying native IPv6 addresses without having obtained
   a new IPv6 prefix from its RIR.  For this, a precaution must have
   been taken from the outset: if the simple format is used, an IPv6
   prefix MUST be recognized as that of a 6rd-site ONLY IF its four bits
   next to the 6rdZoneV6Prefix are not 1110.  (Being in IPv4 the first
   four bits reserved for multicast addresses, 1110 may never appear at
   the beginning of a valid IPv4 unicast address).  Thus, non-6rd
   prefixes can be allocated freely with 1110 as their four bits next to
   the 6rdZoneV6Prefix.

   For example, if an ISP has PPPP:PP00::/24 as its only IPv6 prefix
   and, having several IPv6 prefixes, has assigned PPPP:PPAA:AAAA:
   AA00::/56 as 6rdSiteV6Prefixes of its sites of IPv4 addresses AAAA:
   AAAA, it can allocate to non-6rd sites all prefixes that begin with
   PPPP:PPPe::/32.

2.3.  Encapsulations-decapsulations

   An IPv6 packet the source or destination of which is a 6rd-site
   traverses the 6rd-zone of this site encapsulated in an IPv4 packet.
   The encapsulation format is that of [RFC2893] section 3.5. (protocol
   field set to 41).

   Source and destination addresses of an IPv4 encapsulating packet must
   be related to those of its IPv6 encapsulated packet as follows:

   o  If the IPv6 address is not that of a 6rd-site of the zone, the
      IPv4 address MUST be the 6rdRelayV4Address of the zone.

   o  Otherwise, the IPv4 address MUST be that from which the IPv6
      prefix is derived according to Section 2.2.

2.4.  ICMP consideration

   In 6rd-zones, ISPs MUST ensure that IPv4 maximum transfer units
   (MTUs) are at least 1300, i.e. 1280, the minimum IPv6 MTU, plus 20,
   the length of the IPv4 encapsulating header.  (Supported MTUs on
   Ethernet links being 1500, this leaves on them 200 octets for various
   lower layer encapsulations that may be used between routers of these
   zones, a good margin.)

   If a packet to be encapsulated is longer than 1280 octets,
   encapsulation functions of 6rd-CPEs and 6rd-relays SHOULD return to
   its source a "packet too big" ICMPv6 packet with 1280 as indicated
   MTU ([RFC2893] section 3.2).

   Received ICMPv6 packets are encapsulated like any other IPv6 packets.



Despres                 Expires November 11, 2008               [Page 9]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


   Decapsulation functions of 6rd-CPEs and 6rd-relays, when they receive
   an ICMPv4 packet the type of which is "unreachable" (type field = 3),
   SHOULD forward an ICMPv6 packets signaling "destination unreachable"
   (type field = 1 and code field = 0).  The IPv6 destination has to be
   the source of the IPv6 packet that has been discarded.

   For this destination address to be found, ISPs that support 6rd
   SHOULD ensure that all routers of their IPv4 infrastructures return
   long enough ICMPv4 packets.  To contain IPv6 source addresses of
   discarded packets, their minimum length is 20 + 8 + 20 + 40 = 88
   octets, for IPv4 header, ICMPv4 header, IPv4 header, IPv6 header
   ([RFC2893] section 3.4).  Note that this is necessarily the case if
   these routers comply with requirements of [RFC1812] section 4.3.2.3.


3.  6rd Applicability to IPv4 private addresses


                 ______________________________
                | 10.x.x.x/8 private addresses |
                |  <==                         |
          <-----|                              |----->
                |            6rdRelayV4Address |
       6rd-CPEs |                          ==> |  6rd-relays
                |                              |
          <-----|          0.0.0.0/0           |----->
                |              :               | <== 6rdRelayV6Prefix
                |              V               |
                |______________________________|
                               |
                             __|__
       ISP-supported NAT(s) |     |
                            |_____|
                               |
                               |
                               V
                    IPv4 public addresses

       EXAMPLE OF 6rd WITH ISP ASSIGNED IPV4 PRIVATE ADDRESSES

                                 Figure 4










Despres                 Expires November 11, 2008              [Page 10]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


   ISPs that allocate IPv4 private addresses of [RFC1918] to some of
   their customer sites, and that therefore operate NATs in their IPv4
   infrastructures, can allocate 6rdSiteV6Prefixes based on these IPv4
   private addresses.

   Figure 4 presents an example where allocated IPv4 private addresses
   start with 10.0.0.0/8, a typical choice based on [RFC1918].

   Note that, if an ISP supports several NAT functions in its
   infrastructure, parallel or cascaded, it has, for 6rd, to ensure that
   IPv4 private address spaces behind these NATS are all disjoint.


4.  6rd-CPE parameters - the 6rd DHCPv4 option

   A 6rd-CPE needs to know the three zone parameters of Section 2.2.1.

   If an ISP provides its own router CPEs to all its customer sites (as
   was the case for the first 6rd deployment), these parameters can be
   set up as a byproduct of CPE software updates.

   But if 6rd-CPEs may be provisioned by customers themselves, these
   parameters need to be configured otherwise.  For this, suppliers of
   these CPEs SHOULD include in their user interface means to set up
   these parameters (or their equivalent).

   This parameter setting can be fully automatized where both DHCPv4
   servers of ISPs and 6rd-CPEs of customers support the 6rd ad hoc
   DHCPv4 option [RFC2131],.

   The format retained for the DHCPv4 message specific of this option is
   presented on Figure 5.

   To preserve open-endedness of the message format, 6rd-CPEs that
   support the 6rd-DHCPv4-option MUST accept messages longer than 12
   octets, and ignore what appears beyond fields they know.

   The value of the 6rdDHCPV4Code is under the responsibility of the
   IANA.












Despres                 Expires November 11, 2008              [Page 11]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 6rdDHCPv4Code |     Length    |   6rdZoneV6-  |   6rdZoneV4-  |
     |               |      = 12     |  PrefixLength |  PrefixLength |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        6rdRelayV4Address                      |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     +          6rdZoneV6Prefix      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    FORMAT OF THE 6rd-DHCPv4-OPTION

                                 Figure 5


5.  6rd-relay implementation variants

   In the simplest implementation of 6rd-relays, each physical device
   (or processor) supports only one 6rd-zone.  It has for this only one
   set of zone parameters.

   Although this may be sufficient in practice, the following richer
   implementations are mentioned for suppliers that would consider
   implementing them based on their own market expectations:

   1.  Multiple 6rd-relays in a single device (or using the same
       processor).  Provided each 6rd-relay has a 6rdRelayv6Prefix and a
       6rdRelayV4Address that differ from those of others, the behavior
       is the same as though 6rd-relays would be is separate devices.

   2.  Multiple 6rd-zones in a single 6rd-relay.  Provided each 6rd-zone
       of the 6rd-relay has a 6rdTag and that all 6rdTags are different,
       the 6rdRelayV6Prefix and the 6rdRelayV4Address of a 6rd-relay can
       be shared by several zones.  The relay SHOULD then perform by
       itself the hairpin routing, from and to the IPv4 routing area,
       that encapsulated packets from one of it zones to another
       require.  For ISPs that have several IPv4 prefixes, this
       configuration has the advantage that 6rdSiteV6prefixes allocated
       to 6rd-sites may be shorter than those the simple format.  It has
       however the drawback, beyond its additional complexity, that
       packets that go from one zone to another have to cross a 6rd-
       relay rather than traversing once the IPv4 infrastructure.



Despres                 Expires November 11, 2008              [Page 12]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


6.  Security Considerations

   For security:

   o  Encapsulation functions SHOULD verify that IPv6 source addresses
      of received packets are compatible with where their IPv4
      encapsulating packets come from.

   o  Decapsulation functions SHOULD verify that IPv4 source addresses
      of encapsulating packets are consistent with IPv6 source and
      destination addresses of encapsulated packets.

   Appendix A and Appendix B present pseudo-codes that illustrate these
   verifications, respectively for 6rd-CPEs and 6rd-relays.

   Also, the 6rdRelayV4Address of a 6rd-zone SHOULD NOT be in any range
   of addresses that are advertised by its ISP out of the 6rd-zone.
   Conversely, the ISP SHOULD make sure that routes toward this address
   can only lead to 6rd-relays, even if some peers of the ISP, by
   mistake or malevolently, advertise this address or a prefix leading
   to it.

   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.


7.  IANA Considerations

   The 6rdDHCPV4Code of Section 4 needs to be specified by IANA.


8.  Acknowledgements

   The author warmly acknowledge the major contribution of Rani Assaf to
   6rd's credibility.  He readily appreciated 6rd's potential, and made
   the daring decision to immediately implement it in view of its
   deployment on FREE's operational network.  Patrick Grossetete made
   useful suggestions on multi-subnet sites and on 6rd anycast
   addresses.  Tony Hain contributed on how to support shorter
   6rdSiteV6Prefixes than with just the simple format.

   Acknowledgments are also due to confirmed IPv6 experts, in particular
   Laurent Toutain, Francis Dupont, Alain Durand, who, when the author
   was a late newcomer on IPV6, taught him subtleties of the subject.
   Without them, designing 6rd would probably not have been possible.



Despres                 Expires November 11, 2008              [Page 13]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


Appendix A.  PSEUDO-CODE EXAMPLE WITH SECURITY CHECKS FOR 6RD-CPES


                6rd-CPE ENCAPSULATION

        IF      v6-packet > 1280 octets
        THEN    Send back ICMPv6 pkt "Pkt too big"
        ELSE-IF src6 starts with 6rdZoneV6Prefix
        THEN    src4 <-- SiteV4Address
                dst4 <-- IF  (dst6 starts with the 6rdZoneV6Prefix
                              AND NOT (6rdZoneV4PrefixLength = 0
                                       AND next dst6 bits = 1110) )
                         THEN  6rdZoneV4Prefix(SiteV4Address)
                               followed by 6rdSiteV4Suffix(dst6)
                         ELSE  6rdRelayV4Address
                         END-IF
                Encapsulate v6-packet in v4-packet
                Send v4-packet
        END-IF


                 6rd-CPE DECAPSULATION

        IF      (v4-packet = ICMPv4 "Unreachable"
                AND Protocol in returned header is 41)
        THEN    v6-packet <-- ICMPv6 "Destination unreachable"
                          with the returned encapsulated IPv6 header
                src6 <-- 6rdSiteV6Prefix(SiteV4Address)
                dst6 <-- src6(returned IPv6 header)
                Send v6-packet
        ELSE-IF Protocol of v4-packet = 41
        THEN    v6-packet <-- Data field of v4-packet
                IF      dst6 starts with 6rdSiteV6Prefix)
                THEN    IF ( src6 starts with 6rdZoneV6Prefix
                            AND NOT (6rdZoneV4PrefixLength = 0
                                      AND next src6 bits = 1110) )
                        THEN    IF scr4 is not 6rdRelayV4Address
                                THEN   Forward v6-packet
                                END-IF
                        ELSE    IF src4 is 6rdRelayV4Address
                                THEN   Forward v6-packet
                                END-IF
                END-IF
        END-IF







Despres                 Expires November 11, 2008              [Page 14]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


Appendix B.   PSEUDO-CODE EXAMPLE WITH SECURITY CHECKS FOR 6RD-RELAYS


              6rd-relay ENCAPSULATION

        IF      v6-packet > 1280 octets
        THEN    Send back ICMPv6 pkt "Pkt too big"
        ELSE-IF src6 doesn't start with 6rdZoneV6Prefix
        THEN    IF    (dst6 starts with the 6rdZoneV6Prefix
                       AND NOT (6rdZoneV4PrefixLength = 0
                                  AND next src6 bits = 1110)
                THEN   src4 <-- IPv4-6rd-relay-address;
                       dst4 <-- 6rdZoneV4Prefix followed by
                                6rdSiteV4Suffix(dst6);
                       Encapsulate v6-packet in v4-packet;
                       Send v4-packet
                END-IF
        END-IF


           6rd-relay DECAPSULATION

        IF      (v4-packet = ICMPv4 "Unreachable"
                AND Protocol in returned IPv4 header is 41)
        THEN    v6-packet <-- ICMPv6 "Destination unreachable"
                          with the returned encapsulated IPv6 header
                src6 <-- 6rdSiteV6Prefix(6rdRelayV4Address)
                dst6 <-- src6(returned IPv6 header)
                Send v6-packet
        ELSE-IF Protocol of v4-packet = 41
        THEN    v6-packet <-- Data field of from v4-packet
                IF      dst6 starts with 6rdSiteV6Prefix
                THEN    IF  (src6 starts with 6rdZoneV6Prefix
                            AND NOT (6rdZoneV4PrefixLength = 0
                                       AND next src6 bits = 1110)
                        THEN    IF scr4 is not 6rdRelayV4Address
                                THEN    Forward v6-packet
                                END-IF
                        ELSE-IF src4 is 6rdRelayV4Address
                        THEN    Forward v6-packet
                        END-IF
                END-IF
        END-IF








Despres                 Expires November 11, 2008              [Page 15]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


9.  References

9.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998.

   [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 2893, August 2000.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC4925]  Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
              Problem Statement", RFC 4925, July 2007.

9.2.  Informative References

   [IPv4 addresses]
              Internet Assigned Numbers Authority, "Internet Protocol v4
              Address Space -
              http://www.nro.net/documents/pdf/nro46.pdf",



Despres                 Expires November 11, 2008              [Page 16]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 2008


              February 2008.

   [Protocol Numbers]
              Internet Assigned Numbers Authority, "PROTOCOL NUMBERS -
              http://www.iana.org/assignments/protocol-numbers",
              January 2008.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3053]  Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
              Tunnel Broker", RFC 3053, January 2001.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
              RFC 3068, June 2001.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RIR Policy]
              Number resource Organization, "RIR Comparative Policy
              Overview -
              http://www.iana.org/assignments/ipv4-address-space",
              November 2007.


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                 Expires November 11, 2008              [Page 17]

Internet-Draft         6rd - IPv6 Rapid Deployment              May 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 November 11, 2008              [Page 18]


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