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

Versions: 00

Internet Engineering Task Force                               R. Despres
Internet-Draft                                                 RD-IPtech
Intended status: Experimental                               July 5, 2010
Expires: January 6, 2011


        Rapid Deployment of Native IPv6 Behind IPv4 NATs (6rd+)
                   draft-despres-softwire-6rdplus-00

Abstract

   The [6rd] mechanism permit IPv6 "rapid deployment" across IPv4
   infrastructures of Internet Service Providers, but only in cases
   where customer-premise equipments can be upgraded to support it. 6rd+
   extends this IPv6 rapid deployment capability to hosts behind
   customer-premise equipments that cannot be upgraded (provided these
   hosts can be upgraded themselves to support 6rd+).  Like [6rd], 6rd+
   provides native IPv6 addresses, so that quality of service can be
   guaranteed by Internet Service Providers; it operates statelessly,
   which ensures simplicity and scalability; and it transmits
   encapsulated IPv6 packets along optimized paths, which contributes to
   efficiency and acceptability.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 6, 2011.

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



Despres                  Expires January 6, 2011                [Page 1]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The 6rd+ Protocol  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Participating Entities and IPv6 Paths  . . . . . . . . . .  5
     3.2.  6rd+C Locator Formats  . . . . . . . . . . . . . . . . . .  7
     3.3.  6rd+ Datagram Formats  . . . . . . . . . . . . . . . . . .  9
     3.4.  Mapping Rules of 6rd+Cs and 6rd+Ps . . . . . . . . . . . . 11
     3.5.  Acquisition of 6rd+ parameters by 6rd+Cs . . . . . . . . . 14
     3.6.  Anti-Spoofing and Anti-Routing-Loop Protections  . . . . . 16
   4.  Security considerations  . . . . . . . . . . . . . . . . . . . 17
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19

























Despres                  Expires January 6, 2011                [Page 2]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


1.  Introduction

   Although most operating systems now support IPv6, the large installed
   base of IPv4-only customer-premise equipments (CPEs) acts as a
   deterrent to IPv6 rapid deployment.  Mechanisms such as [Tunnel
   Broker] and [Teredo] are designed to provide IPv6 connectivity behind
   such CPEs, but with too severe limitations to be generalized: [Tunnel
   Broker] necessitates that hosts be individually registered in tunnel-
   broker servers, and tends to produce unnecessarily long IPv6 paths;
   [Teredo] does not work with all types of customer-site NATs, and,
   because it uses IPv6 addresses that start with a Teredo-specific
   prefix, prevents Internet Service Providers (ISPs) to control the
   IPv6 quality of service (QoS) experienced by their customers.

   6rd+ is designed to avoid these limitations:

   o  All types of NATs are supported.

   o  IPv6 addresses obtained behind IPv4-only CPEs are "native"
      (unicast starting with ISP-allocated prefixes), so that ISPs can
      control the IPv6 QoS experienced by their customers.

   o  IPv6 paths are optimized.

   o  Hosts don't need to be individually registered in any specific
      server.

   The name 6rd+ is derived from that of [6rd], to express that it
   extends its IPv6 "rapid deployment" to cases not covered so far.
   Like [6rd], 6rd+ uses IPv6-packet encapsulations and stateless
   address mappings, but where [6rd] necessitates CPEs to be upgraded,
   6rd+ does not.  The counterpart is that hosts behind non-upgraded
   CPEs have to support 6rd+ to obtain their native IPv6 connectivity.
   Their upgrade is expected to be feasible with a downloadable module,
   at least with Linux for which similar stateless functions have been
   shown to be downloadable.

   Other approaches to extend [6rd] to traverse IPv4-only CPEs have been
   proposed in [6rd UDP] and [SAMPLE], but without optimization of IPv6
   paths.  As this optimization is expected to be important for a wide
   use of native IPV6, 6rd+ is proposed as a more complete solution.






   Formats 6rd+ based IPv6 addresses presuppose that the rule of



Despres                  Expires January 6, 2011                [Page 3]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   [RFC4291] that IPv6 addresses must contain 64-bit-IIDs is partially
   relaxed.  This relaxation is needed to keep formats of 6rd+ based
   addresses simple, and does not conflict with the technical rationale
   for this rule.  The 64-bits IID is indeed justified for addresses
   that, on some link, are subject to the neighbor discovery protocol
   [ND], but only for these.  As 6rd+ addresses that don't have 64-bits
   IIDs are only assigned to host interfaces on virtual links, where the
   [ND] protocol is not used, the conflict doesn't exist.  (Note that
   the viability of virtual links having no [ND] has been abundantly
   validated with [6to4], and that an independent proposal to partially
   relax the 64-bits-IID rule is available in [IPv6 /127 prefix].)

   At this stage, the 6rd+ design is so new that some fixes are likely
   to be needed, in particular after running code has been developed.
   This is the reason why it is proposed as experimental.  But the
   intent is to progress it to the standard track as soon as possible:
   the urgency of IPv6 actual use continues to grow.


2.  Terminology

   IPv4+:  The extended-address family whose addresses have 48 bits, 32
      of unicast IPv4 addresses plus 16 of a port numbers.

   Locator:   Any routable address or prefix, in a specified address
      space among IPv4, IPv6, and IPv4+.

   IPv4+ datagram :  An IPv4 datagram that contains a 6rd+ message, or
      an IPv6 packet in which at least one address has been obtained
      with 6rd+.  The protocol above IPv4 is either UDP or the SAM
      protocol whose ID has to be assigned by IANA (see Section 3.3.  If
      it is UDP, at least one of the two UDP ports is one of the two
      6rd+ well-known ports, to be also assigned by IANA.

   NAT:  In this document, only IPv4-to-IPv4 network address
      translations are considered (NAT44s).  They typically translate
      address plus ports couples, as described in [RFC2663].

   EIM, EDM:  An EIM NAT is one that does endpoint-independent mappings
      as specified in [RFC4787] (also known as a "full-cone" NAT).  An
      EDM NAT is one that does endpoint-dependent mappings (the opposite
      of an EIM NAT).

   6rd+C, 6rd+P:  A 6rd+C is a 6rd+ "customer" function, and a 6rdP is a
      6rd+ "provider" function.  Each one has one lower-layer interface,
      and two upper-layer interfaces.  The lower-layer interface is that
      of an IPv4 link layer.  One of its upper-layer interfaces is a
      replication of the lower-layer interface? the other is an IPv6



Despres                  Expires January 6, 2011                [Page 4]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


      pseudo interface (as in [6to4].  Between two 6rd+Cs, or between a
      6rd+C and a 6rd+P, IPv6 packets are encapsulated in IPv4+
      datagrams.

   6rd+ domain:  A network domain delimited by 6rd+Ps and 6rd+Cs of a
      given ISP.

   Local, Interior:  The "local" address space of a 6rd+C is that
      available at its lower-layer interface.  Its interior address
      space is that available after traversal of all NATs that may exist
      between this 6rdC and 6rd+Ps.  It is the same for all 6rd+Cs of
      the domain.  (A 6rd+C that has no NAT between itself and 6rd+Ps
      has identical local an interior address spaces.)

   Shortcut:  An path, between two 6rd+Cs of the same 6rd+ domain, that
      doesn't go via any domain 6rd+P.


3.  The 6rd+ Protocol

3.1.  Participating Entities and IPv6 Paths

   In a 6rd+ domain, participating entities are the following
   [Figure 1]:

   o  6rd+Ps (6rd+ Provider functions)

   o  6rd+Cs (6rd+ Customer functions)

   o  CPE NATs of two types

      *  EIM CPE NAT (doing endpoint-independent mapping)

      *  EDM CPE NAT (doing endpoint-dependent mapping)

   o  ISP NATs

   6rd+Ps are stateless.  They can be duplicated in any number of nodes.
   Their interior unicast address is then routed like any other anycast
   address.

   6rd+C functions are also stateless.  However, if there are NATs
   between them and 6rd+Ps, their operation depends on states that are
   maintained in these NATs.  In this case, they cannot be duplicated in
   several nodes.






Despres                  Expires January 6, 2011                [Page 5]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


           <================= 6rd+ domain =================>
          local address spaces           interior address space
    IPv6
     +-----+Private IPv4   +-----+    Public or private IPv4
     |     |------->O------|     |------------.----.
     +-----+       /       +-----+             \    \
      6rd+C    <--'      EIM CPE NAT            :    :
                                                :    :
    IPv6                                        :    :
     +-----+Private IPv4   +-----+              :    :
     |     |------->O------|     |-----------------. |
     +-----+       /       +-----+              :   \:
      6rd+C    <--'      EDM CPE NAT         ^  :    '              IPv6
                                              \ :    :        +-----+
                                               \:    :       +-----+|
                                                O     \      |     ||
                                               /:      :---->O     |----
                                              / :     /     /|     |+
                                             v  :    :  <--' +-----+
                           possibly             :    :        6rd+Ps
    IPv6                    other               .    .
     +-----+Private IPv4    NATs    +-----+    /:   /:
     |     |-------- - - - - - ---->O     |---'----' :
     +-----+                       /+-----+     :    :
      6rd+C                    <--' ISP NAT     :    :
                                                :    :
    IPv6                                        .    .
     +-------+Public or private IPv4    No NAT /    /
     | 6rd+C |--------------------------------'----'
     +-------+

                6rd+ PARTICIPATING ENTITIES AND IPv6 PATHS

                                 Figure 1

   The distinction between EIM and EDM NATs is key, like in [STUN] and
   in [Teredo], to find some shortcuts that are possible only with EIM
   NATs.  CPE NATs, being in legacy devices of unknown types, may be
   either EIM or EDM.  ISP NATs are assumed to be EIM and to support
   hairpinning, as specified in [RFC4787].

   Paths that can be followed by IPv6 packets are illustrated in
   Figure 1.  Possible shortcuts are the following:

   Intra-site shortcut:  This shortcut concerns two 6rd+Cs that are on
      the same LAN behind a common CPE NAT (EIM CPE NAT or EDM CPE NAT).
      IPv6 packets are exchanged via the LAN, without going to the CPE.




Despres                  Expires January 6, 2011                [Page 6]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   Intra-ISP shortcut:  This shortcut concerns 6rd+Cs that are behind
      EIM CPE NATs, or ISP NATs, or no NAT.  IPv6 packets between them,
      unless intra-site shortcuts which are shorter are possible,
      traverse the IPv4 routing infrastructure of the domain without
      going to any of its 6rd+Ps.

   ISP-NAT hairpin shortcut:  If two 6rd+Cs are behind the same ISP NAT,
      IPv6 packets they exchange follow an hairpin path whose turning
      point is in this ISP NAT.

3.2.  6rd+C Locator Formats

   Formats of IPv6 locators that 6rd+Cs obtain depend on the types of
   NATs that exist between themselves and 6rd+Ps of the domain.  Each
   such IPv6 locator is chosen to contain all addressing information
   that is needed to reach it via with or without shortcut, and nothing
   more.  The different formats that result from this principle are
   detailed in Figure 2 (where the dot is used as concatenation
   operator).

   The three NAT-type codes, C, C' and C", because they must be
   distinguishable in a prefix-match search, have to be be disjoint
   prefixes (no one starting with another).  Besides that, they may have
   different lengths:

   o  NAT-type code C", which is that of 6rd+Cs that have no NAT to
      traverse, should typically be short so that IPv6 locators E=D.C".X
      remain within a 64-bits limit.  These locators can thus be used as
      link prefix on ordinary IPv6 links (subject to [ND]).

   o  NAT-type codes C and C', which are those of 6rd+Cs behind NATs,
      appear in IPv6 locators E=D.C.X.Z, E=D.C.X.Z.Y, and E=D.C'.X.Z.Y,
      which contain too much information to have a chance to fit in 64-
      bits.  In order to limit the amount of ISP IPv6 address space
      devoted to 6rd+, C and C' may therefore be chosen significantly
      longer than C".  These locators, which are too long to be used as
      link prefixes on ordinary IPv6 links, can be used to obtain
      native-IPv6 host addresses (duly completed with trailing 0s if
      needed to reach 128 bits).  Other possible uses of these locators
      are beyond the scope of this draft.











Despres                  Expires January 6, 2011                [Page 7]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   E=D.C.X.Z.Y   A=Q.Y     +-----+
    +-------+    L=A:W     | EIM | N=P.X
    | 6rd+C |----->O-------| CPE |------------.----.
    +-------+     /        | NAT |             \    \
              <--'         +-----+              :    :
                         L<->I=P.X:Z            :    :
                                                :    :
   E=D.C'.X.Z.Y  A=Q.Y     +-----+              :    :
    +-------+    L=A:W     | EDM | N=P.X        :    :
    | 6rd+C |----->O-------| CPE |-----------------. |
    +-------+     /        | NAT |              :   \:
              <--'         +-----+         ^    :    '
                          L<->I=N:Z        |    :    :  B.W  +-----+
                                            \   :     \ B'.W'|6rd+P| D
                                             :--O      :-----|-->O-|----
                                            /   :     /      |     |
                                           |    :    :       +-----+
                                           v    :    : 6rd+P PARAMETERS:
   E=D.C.X.Z   A         possibly   +-----+     .    .   D,P,C,C',C"
    +-------+  L=A:W    other NATs  | ISP |    /:   /:   ISP-NAT locators
    | 6rd+C |-------- - - - - - --->|O----|---'----' :
    +-------+             L<->x    /| NAT |     :    :
                                  / +-----+     :    :
                              <--' x<->I=P.X:Z  :    :
                                                :    :
   E=D.C".X    A=P.X                            .    .
    +-------+  L=A:W                  No NAT   /    /
    | 6rd+C |---------------------------------'----'
    +-------+                          I=L

   E       : 6rd+C IPv6 locator
   D       : ISP prefix assigned to 6rd+
   C,C',C" : NAT-type code (resp. EIN or ISP, EDM, NoNAT)
   X       : complement of P in N
   Z       : complement to N in I (port number)
   Y       : complement to Q in L
   A       : 6rd+C local IPv4 address (= Q.Y)
   W,W'    : 6rd+ well-known UDP ports (to be assigned by IANA)
   Q       : prefix of RFC 1918 in A (10/8, 172.16/12, or 192.168/16)
   L       : 6rd+C local locator (= A.W)
   I       : 6rd+C interior locator (IPv4+)
   N       : IPv4 part of the interior locator I
   P       : common prefix of the interior address space (possibly /0)
   B,B'    : 6rd+ well-known IPv4 public addresses (to be assigned by IANA)

                           6RD+ LOCATOR FORMATS

                                 Figure 2



Despres                  Expires January 6, 2011                [Page 8]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


3.3.  6rd+ Datagram Formats

   6rd+Cs and 6rd+Ps encapsulate IPv6 packets they have to forward
   across their 6rd+ domain.  For this they have to derive the interior
   destination address of each encapsulating packet from addresses
   contained in the IPv6 packet it encapsulates.  If this interior
   destination has 32bits, encapsulation is in an IPv4 datagram, with
   the protocol field set to 41 (IP in IP).  If it has 48 bits,
   encapsulation is in a UDP datagram.  Its destination port is copied
   from the last 16 bits of the interior destination, and its source
   port is the 6rd+ well-known prefix W. Formats of IPv4+ datagrams are
   shown on Figure 3 and Figure 4.


   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 2
   +=======+=======================================================+----
   |Vrsn=4 |                                                       |
   +-------+                                                       +
   |                                                               |
   +               +---------------+                               +
   |               | Prot.=17 (UDP)|                               |IPv4
   +---------------+---------------+-------------------------------+
   |                       IPv4 Source Address                     |
   +---------------------------------------------------------------+
   |                     IPv4 Destination Address                  |
   +=======+=======================+===============================+----
   |          Source Port (*)      |     Destination port (*)      |
   +-------------------------------+-------------------------------| UDP
   |                                                               |
   +===============================================================+----
   .                                                               .
   .             IPv6 packet      OR     6rd+ message              .
   .                                                               .
   +                      + ---------------------------------------+
   |                      |
   +=========//===========+

   (*) At least one of the two ports is one of the two
         6rd+ well-known prefixes W and W'.

         FORMATS OF 6RD+ DATAGRAMS FOR IPV4+ INTERIOR DESTINATIONS

                                 Figure 3







Despres                  Expires January 6, 2011                [Page 9]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   +=======+=======================================================+----
   |Vrsn=4 |                                                       |
   +-------+                                                       +
   |                                                               |
   +               +---------------+                               +
   |               |Prot=41 (IP/IP)|                               |IPv4
   +---------------+---------------+-------------------------------+
   |                       IPv4 Source Address                     |
   +---------------------------------------------------------------+
   |                     IPv4 Destination Address                  |
   +===============================================================+----
   .                                                               .
   .                        IPv6 packet                            .
   .                                                               .
   +                      + ---------------------------------------+
   |                      |
   +=========//===========+

   +=======+=======================================================+----
   |Vrsn=4 |                                                       |
   +-------+                                                       +
   |                                                               |
   +               +---------------+                               +
   |               |Prot=SAM (TBD)|                               |IPv4
   +---------------+---------------+-------------------------------+
   |                       IPv4 Source Address                     |
   +---------------------------------------------------------------+
   |                     IPv4 Destination Address                  |
   +===============================================================+----
   .                                                               .
   .                        6rd+ message                           .
   .                                                               .
   +                      + ---------------------------------------+
   |                      |
   +=========//===========+

         FORMATS OF 6RD+ DATAGRAMS FOR IPV4 INTERIOR DESTINATIONS

                                 Figure 4

   Recommendations of [RFC4213] that concern these encapsulations have
   to be followed.

   Since IPv6 packets are encapsulated in IPv4 datagrams which may be
   fragmented on their way, a large IPv6 packet can in general be
   encapsulated in a single IPv4 datagram, independently of path MTUs of
   the traversed domain.  However, reassembly of multi-fragment
   datagrams tends to consume processing power and can bring some



Despres                  Expires January 6, 2011               [Page 10]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   buffer-size problems.  It is therefore advisable to limit the size of
   accepted IPv6 packets (and to return ICMPv6 packet-too-big error
   messages when received IPv6 packets are too big to be forwarded).
   Forwarding only IPv6 packets that don't exceed the 1280 octets, the
   size that [RFC2460] requests every link to support, is the choice
   that minimizes the risk of such reassembly problems.  Yet, accepting
   somewhat larger sizes may be preferred to obtain a different trade-
   off between reassembly avoidance and accepted IPv6 packet sizes.

   The protocol ID to be used for 6rd+ messages exchanged directly in
   IPv4 datagrams is that of the more general [SAM] protocol, of which
   the 6rd+ protocol is a subset.

3.4.  Mapping Rules of 6rd+Cs and 6rd+Ps

   Mapping rules that, in 6rd+Cs, determine interior destinations iDSTs
   are detailed in Table 1.  For each NAT type, the listed rules have to
   be tested in the indicated order, until one is found to apply.  If
   none applies, the IPv6 packet is invalid, and silently discarded.

   The logic of these mapping rules directly results from shortcuts that
   have to be supported, and from IPv6 locator formats of Section 3.2.

   In Table 1:

   o  Lower-case letters represent lengths of fields whose symbols are
      upper-case letters (e.g. d is the number of bits of D).

   o  Column 1 indicates the NAT type of the 6rd+C (EIM CPE NAT, EDM CPE
      NAT, ISP NAT, No NAT).

   o  In column 2, a prefix indicates that the rule applies only if the
      IPv6 destination address eDST starts with this prefix.

   o  In column 3, a number of bits n indicates that the rule applies
      only if both the IPv6 destination address and the 6rd+C IPv6
      locator start with the same n bits.

   o  In column 4, a prefix indicates that the rule applies if the IPv6
      source address eSRC starts with this prefix.  A rule has contents
      in one and only one of the first three columns.

   o  In column 5, a prefix indicates that, if the rule applies, this
      prefix has to be included the interior destination iDST.

   o  In column 6, a number of bits n indicates that, if the rule
      applies, n bits in the IPv6 destination address eDST have to be
      skipped, after those that may have already been matched if any.



Despres                  Expires January 6, 2011               [Page 11]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   +------+------+-------------+-------+------+-------+---------+------+
   |  -1- |  -2- |     -3-     | - 4 - |  -5- |  -6-  |   -7-   |  -8- |
   | ---- | ---- |  ---------  |  ---- | ---- |  ---- |  -----  | ---- |
   |  NAT | eDST |  length of  |  eSRC | iDST |  Skip |  Add to | iDST |
   |  Tpe | prfx |    common   |  prfx | prfx |   in  |   iDST  | sffx |
   |      |      |  prefix of  |       |      |  eDST |   from  |      |
   |      |      |    eDST &   |       |      |       |   eDST  |      |
   |      |      |  IPv6-lctr  |       |      |       |         |      |
   +------+------+-------------+-------+------+-------+---------+------+
   |  EIM |      |   d+c+32-p  |       |   Q  |   16  |   32-q  |      |
   |  CPE |      |             |       |      |       |         |      |
   |  NAT |      |             |       |      |       |         |      |
   | ---- | ---- |  ---------  |  ---- | ---- |  ---- |   ----  | ---- |
   |   "  |  D.C |             |       |   P  |       |   48-p  |      |
   | ---- | ---- |  ---------  |  ---- | ---- |  ---- |   ----  | ---- |
   |   "  | D.C" |             |       |   P  |       |   32-p  |   W  |
   | ---- | ---- |  ---------  |  ---- | ---- |  ---- |   ----  | ---- |
   |   "  |      |             |   D   |  B:W |       |         |      |
   | ==== | ==== |  =========  |  ==== | ==== |  ==== |   ====  | ==== |
   |  EDM |      |  d+c'+32-p  |       |   Q  |   16  |   32-q  |      |
   |  CPE |      |             |       |      |       |         |      |
   |  NAT |      |             |       |      |       |         |      |
   | ---- | ---- |  ---------  |  ---- | ---- |  ---- |   ----  | ---- |
   |   "  |      |             |   D   |  B:W |       |         |      |
   | ==== | ==== |  =========  |  ==== | ==== |  ==== |   ====  | ==== |
   |  ISP |  D.C |             |       |   P  |       |   48-p  |      |
   |  NAT |      |             |       |      |       |         |      |
   | ---- | ---- |  ---------  |  ---- | ---- |  ---- |   ----  | ---- |
   |   "  | D.C" |             |       |   P  |       |   32-p  |   W  |
   | ---- | ---- |  ---------  |  ---- | ---- |  ---- |   ----  | ---- |
   |   "  |      |             |   D   |  B:W |       |         |      |
   | ==== | ==== |  =========  |  ==== | ==== |  ==== |   ====  | ==== |
   |  No  |  D.C |             |       |   P  |       |   48-p  |      |
   |  NAT |      |             |       |      |       |         |      |
   | ---- | ---- |  ---------  |  ---- | ---- |  ---- |   ----  | ---- |
   |   "  | D.C" |             |       |   P  |       |   32-p  |   W  |
   | ---- | ---- |  ---------  |  ---- | ---- |  ---- |   ----  | ---- |
   |   "  |      |             |   D   |   B  |       |         |      |
   +------+------+-------------+-------+------+-------+---------+------+

                             6rd+C MAPPING RULES

                                   Table 1








Despres                  Expires January 6, 2011               [Page 12]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   o  In column 7, a number of bits n indicates that, if the rule
      applies, n bits of the IPv6 destination eDST, after those that may
      have already been matched and/or skipped, have to be included in
      the interior destination iDST, after any bits it may have already
      been included.

   o  A column-8 square may contain a suffix.  If the rule applies, it
      is included in the interior destination iDST, after any bits it
      may already contain.

   6rd+P mapping rules are straightforward, as no possible shortcuts
   have to be considered.  Using the same notation as in Table 1, they
   are detailed in Table 2 (without any implication on how they can be
   implemented).

   As shown, packets exchanged between 6rd+Ps and 6rd+cs of the "No NAT"
   type are encapsulated in UDP/IP rather than directly in IPv4 as it
   would have been possible.  This adds a little overhead to these
   packets, but has two advantages: hairpinning in 6rd+Ps for 6rd+Cs of
   the "No NAT" that exchange packets with 6rd+Cs of the EDM CPE NAT"
   type is facilitated, as received and transmitted datagram headers
   have the same length; routing loops with other tunneling mechanisms
   such as [6to4], [6rd], and [ISATAP], are made impossible (these three
   mechanisms encapsulate IPv6 in IPv4 while 6rd+Ps only encapsulate
   IPv6 in IPv4+ (see also Section 3.6.

   +----------------------+---------------------+----------------------+
   |      eDST prefix     |     iDST prefix     |   Add to iDST from   |
   |                      |                     |         eDST         |
   +----------------------+---------------------+----------------------+
   |          d+c         |          P          |         48-p         |
   | -------------------- | ------------------- | -------------------- |
   |         d+c'         |          P          |         48-p         |
   | -------------------- | ------------------- | -------------------- |
   |         d+c"         |          P          |         48-p         |
   +----------------------+---------------------+----------------------+

                            6rd+P MAPPING RULES

                                  Table 2











Despres                  Expires January 6, 2011               [Page 13]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


3.5.  Acquisition of 6rd+ parameters by 6rd+Cs

   This 6rd+ protocol is a particular instance of the more general
   "stateless address mapping" protocol proposed in [SAM], where the
   exterior address family is IPv6 and the interior address family is
   IPv4+.  Rules of the 6rd+ protocol, partially illustrated in
   Figure 5, are the following:

   R1:  If a 6rd+C that has an IPv4 address but no IPv6 address or
        prefix, it tries to obtain its parameters from a 6rd+P (its IPv6
        locator an its mapping rules).  For this, it sends two SAM
        messages containing a "Parameter Request" indication.  The first
        one is sent to IPv4 address B. The second one is sent IPv4+
        address B:W, with the local IPv4 address A as parameter.  These
        two requests are also retransmitted from time to time to check
        whether newly received answers differ from previous ones, and
        for the second one to maintain mappings in all NATs that may
        exist between the 6rd+C and 6rd+Ps.


          6rd+C                                           6rd+P
     v    -----                                           -----
     :
     :\   A -> B          SamMsg("ParamReq")              A -> B
     : '->------------------------>--------------- - ??? - -------->-.
     :                                                                \
     :                                                                 :
     :    A <- B          SamMsg(ParamSetforNoNat)        A <- B      /
     :   <------------------------<--------------------------------<-'
     :
      \   A.W -> B.W      SamMsg("ParamReq", A)           I -> B.W
       '->------------------------<-------------------------------->-.
                                                                      \
                                                        if I belongs   :
                                                        to an ISP NAT  :
          A.W <- B.W      SamMsg(ParamSetForIspNat)       I <- B.W    /:
         <------------------------->-------------------------------<-' :
                                                                       :
                                                         otherwise     :
                                                                       :
          A.W <- B.W      SamMsg(ParamSetForEdm)          I <- B.W     :
         <------------------------->-------------------------------<-. :
                                                                      \.
          A.W <- B':W'    SamMsg(ParamSetForEim)          I <- B'.W'  /
         <------- - ??? - ---------<-------------------------------<-'






Despres                  Expires January 6, 2011               [Page 14]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


                                 6rd+ PROTOCOL

                                    Figure 5

   R2:  If a 6rd+P receives a SAM message at its IPv4 address B without
        a UDP header, it knows that this message crossed no NAT on its
        way.  If the message contains a parameter request, it returns a
        SAM message containing parameters suitable for this 6rd+C, known
        to be of the "No NAT" type.

   R3:  If a 6rd+P receives a SAM message at its IPv4+ address B:W, it
        first tests whether its IPv4 source address starts with the IPv4
        prefix of one ISP NATs of the domain. if yes, it returns an
        answer containing parameters suitable for this 6rd+C, known to
        be of the "ISP-NAT" type.  Otherwise, it returns two answers.
        The first answer is sent from the B:W IPv4+ address so that it
        can reach its destination with on its way NATs of any types.  It
        contains parameters suitable for this 6rd+C if it is of "EDM CPE
        NAT" type.  The second answer is sent from the B':W' IPv4+
        address so that it can reach its destination only if either
        there is no NAT on its way, or if the first traversed NAT is
        EIM.  It contains parameters suitable for this 6rd+C if it is of
        the "EIM CPE NAT' type.

   R4:  If a 6rd+C receives an answer, it first checks that its source
        address is valid (is B, B:W, or B':W').  If the received
        parameters are better than those of its current parameter set or
        if it has no current parameter set, it takes them as the new
        current parameter set.  The decreasing order of best parameter
        sets is: (1) received from B (No NAT); (2) received from B':W'
        (EIM CPE NAT or ISP NAT); (3) received from B:W (EDM CPE NAT).
        If the received parameter set is less good as the current one,
        but has a lifetime longer than the the remaining lifetime of the
        current one, it should be memorized to possibly become current
        one if the current one becomes obsolete.
















Despres                  Expires January 6, 2011               [Page 15]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   R5:  If a 6rd+C receives at its IPv4 address Q.Y a 6rd+ datagram
        without UDP header, in which the IPv6 destination doesn't match
        its IPv6 locator D.X.Z.Y, it infers that an intra-site shortcut
        must have been attempted which cannot be taken.  This may happen
        in the very specific case where: there is at least one NAT,
        internal to the site, between the source 6rd+C and the intended-
        destination 6rd+C; there is no NAT between the source 6rd+C and
        the receiving 6rd+C; the receiving 6rd+C has the same private
        IPv4 local address as the intended-destination 6rd+C. A SAM
        message is then returned to the IPv4 address of the source 6rd+C
        with a "SAM unreachability" indication, and the receiving 6rd+C
        disables its intra-site-shortcut mapping rule if it still has
        one (a rule leading to a 32-bits iDST).

   R6:  If a 6rd+C receives at its IPv4 address a SAM message containing
        a "SAM unreachability" indication, it disables its intra-site-
        shortcut mapping rule if it has one.  With this rule ad the
        previous one, IPv6 connectivity between 6rd+C IPv6 locators is
        always ensured even in complex intra-site configuration with
        internal NATs, with IPv6 packets having in this case to go via
        the CPE.

   Detailed formats of SAM messages used for 6rd+ are beyond the scope
   of this document.  They should be specified in the wider context of
   [SAM].

3.6.  Anti-Spoofing and Anti-Routing-Loop Protections

   Anti-spoofing protection can be ensured by applying the general
   ingress-filtering principle: a packet received at an interface is
   valid only if the same packet with inverses source and destination
   may be transmitted at that same interface:

   o  An IPv6 packet received by a 6rd+C or by a 6rd+P in an IPv4+
      datagram must be silently discarded if the source address of the
      datagram (IPv4 or IPv4+) is not that which mapping rules obtain as
      iDST if applied to a an IPv6 destination eDST equal to the IPv6
      source address of the datagram.

   o  Routing-loop protection is necessary if an ISP operates two point-
      to-multipoint tunneling mechanisms on the same domain with the
      same exterior and interior address families.  (Example with
      [ISATAP] and [6to4] are analyzed in [RoutingLoops].)

   o  As long as 6rd+ as specified here is the only point-to-multipoint
      tunneling mechanism used with IPv6 as exterior address space and
      IPv4+ as interior address space, no particular protection against
      routing loops is needed for IPv4+ tunnels.



Despres                  Expires January 6, 2011               [Page 16]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


4.  Security considerations

   With precautions taken in previous sections, no new security issue
   has been identified so far.  More work on this specification is
   however desirable to improve confidence in this respect.


5.  IANA Considerations

   For plug-and-play operation of 6rd+, the following assignments have
   to be made by IANA:

   o  The two well-known IPv4 addresses B and B' and the two well-known
      UDP ports W and W' of Section 3.2;

   o  The SAM protocol ID of Section 3.3 (to be shared with [SAM]


6.  Acknowledgments

   A very early version of this proposal has been informally submitted
   to a number of delegates at IETF 77.  Thanks are due to Dan Wing and
   Pascal Thubert for their encouragements to pursue in this direction,
   and also to Brian Carpenter for his strong support that the objective
   of 6rd+: native IPv6 across legacy CPEs.


7.  References

7.1.  Normative References

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

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

7.2.  Informative References

   [6rd]      Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider
              Networks - draft-ietf-softwire-ipv6-6rd-10",
              February 2010.

   [6rd UDP]  Lee, Y. and P. Kapoor, "UDP Encapsulation of 6rd -
              draft-lee-softwire-6rd-udp-01", May 2010.



Despres                  Expires January 6, 2011               [Page 17]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


   [6to4]     Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", February 2001.

   [ARP]      Plummer, D., "An Ethernet Address Resolution Protocol --
              or -- Converting Network Protocol Addresses
              to 48.bit Ethernet Address for Transmission on Ethernet
              Hardware", RFC 826, November 1992.

   [IPv6 /127 prefix]
              Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., and L.
              Colitti, "Using 127-bit IPv6 Prefixes on Inter-Router
              Links - draft-kohno-ipv6-prefixlen-p2p-01", March 2010.

   [ISATAP]   Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

   [ND]       Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

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

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

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
              Framework", RFC 5565, June 2009.

   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4



Despres                  Expires January 6, 2011               [Page 18]

Internet-Draft      Native-IPv6 across NAT44s (6rd+)           July 2010


              infrastructures (6rd)", January 2010.

   [RoutingLoops]
              Nakibly, G. and F. Templin, "Routing Loop Attack using
              IPv6 Automatic Tunnels: Problem Statement and Proposed
              Mitigations - draft-nakibly-v6ops-tunnel-loops-02",
              May 2010.

   [SAM]      Despres, R., "Stateless Address Mapping (SAM) for
              Softwire-Lite Solutions (NOTE: only the revised
              draft-despres-softwire-sam-01 will be consistent with this
              draft. It should be posted before the deadline for IETF
              78)", July 2010.

   [SAMPLE]   Carpenter, B. and S. Jiang, "Legacy NAT Traversal for
              IPv6: Simple Address Mapping for Premises - Legacy
              Equipment (SAMPLE) - draft-carpenter-softwire-sample-00",
              June 2010.

   [STUN]     Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

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

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


Author's Address

   Remi Despres
   RD-IPtech
   3 rue du President Wilson
   Levallois,
   France

   Email: remi.despres@free.fr










Despres                  Expires January 6, 2011               [Page 19]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/