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

Versions: 00

Internet Engineering Task Force                               R. Despres
Internet-Draft                                                 RD-IPtech
Intended status: Standards Track                        October 18, 2010
Expires: April 21, 2011

      IPv4 Residual Deployment across IPv6-Service networks (4rd)
                          A NAT-less solution


   During the long transition period from IPv4-only to IPv6-only,
   networks will have not only to deploy the IPv6 service but also to
   maintain some IPv4 connectivity for a number of customers, and this
   for both outgoing and incoming connections and for both customer-
   individual and shared IPv4 addresses.  The 4rd solution (IPv4
   Residual Deployment) is designed as a lightweight solution for this.
   It applies not only to ISPs have IPv6-only routing networks, but also
   to those that, during early transition stages, have IPv4-only
   routing, with 6rd to offer the IPv6 service, those that have dual-
   stack routing networks but with private IPv4 addresses assigned to

   In some scenarios, 4rd can dispense ISPs from supporting any NAT in
   their infrastructures.  In some others it can be used in parallel
   with NAT-based solutions such as DS-lite and/or NAT64/DNS4 which
   achieve better IPv4-address sharing ratios (but at a price of
   significantly higher operational complexity).

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 April 21, 2011.

Copyright Notice

Despres                  Expires April 21, 2011                 [Page 1]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  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.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  The 4rd Protocol Specification . . . . . . . . . . . . . . . .  8
     4.1.  Mapping Rules  . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Packet Encapsulations/Decapsulations . . . . . . . . . . .  9
     4.3.  Port sets of IPv4r prefixes longer than /32  . . . . . . . 10
     4.4.  PMTU Considerations  . . . . . . . . . . . . . . . . . . . 12
     4.5.  Parameter Acquisitions by 4rd Clients  . . . . . . . . . . 12
   5.  Example with IPv6-only Routing and Shared IPv4 Addresses . . . 14
   6.  Security considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18

Despres                  Expires April 21, 2011                 [Page 2]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

1.  Introduction

   During the long transition period from only IPv4 to IPv6, networks of
   Internet Service providers (ISPs) will have not only to offer IPv6
   connectivity but also, for some customers, to maintain a residual
   IPv4 connectivity.  Both outgoing and incoming connections will have
   to be supported.  While some privileged customers will still have
   individual IPv4 addresses of their own, more and more others with
   only have shared IPv4 addresses.

   All ISP routing networks will eventually be IPv6-only but, in earlier
   phases, some deployments of the IPv6 service can be done on ISP
   routing networks that only route private IPv4 of [RFC1918], the IPv6
   service being offered by means of 6rd.  Some others will route both
   IPv6 and private IPv4.

   4rd is a solution for the residual support of global IPv4
   connectivity across routing networks that are IPv6-only, private-
   IPv4-only, or IPv6-and-private-IPv4.

   Depending on ISP constraints and policies, 4rd can be used across
   IPv6-only networks either alone, no NAT being then needed in ISP
   infrastructures, or in parallel with NAT based solutions that, at a
   price of more operational complexity, achieve better address sharing
   ratios such as [DS-lite] and [NAT64]/[DNS64].

   This proposal is a more detailed version of what was initially
   described in section 3.2 of the more general Stateless Address
   Mapping proposal of [1]) (SAM).

   At the time of writing, 4 ISPs in Japan have expressed interest for
   the SAM/4rd solution to offer IPv4 connectivity across IPv6-only
   routing networks (www.ietf.org/mail-archive/web/v6ops/current/

Despres                  Expires April 21, 2011                 [Page 3]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

2.  Definitions

   Locator:  in a given address family, an address or a routable prefix.

   IPv4r Address Family:  the "residual IPv4" address family, that of
      IPv4r locators.

   IPv4r Address:  Either a global IPv4 address or the combination of a
      global IPv4 address and a port (an A+P address)

   IPv4r prefix:  Either a global IPv4 prefix (up to /32), or a global
      IPv4 address followed by a port-set identifier whose length is
      from 1 to 15.

   IPv4p Address Family:  That of a private address spaces of (10/8,
      172.16/12, or 192.16/16, prefixes).

   interior address family:  in a tunnel-supporting network, the address
      family of encapsulating packets (in 4rd, IPv6 or IPv4p).

   exterior address family:  in a tunnel-supporting network, the address
      family of encapsulated packets (in 4rd, IPv4r).

   4rd parent network:  For a given 4rd network, the network that
      assigns to it one or several IPv4r prefixes.

   4rd network:  A network whose interior address family is different
      from global IPv4, and that supports one or several 4rd servers at
      its border with its 4rd parent network.

   4rd server (4rd-S):  A function at a border point between a 4rd
      network and its 4rd parent network.  Via automatic tunnels, it
      statically shares among customers of the 4rd network IPv4r
      locators that have been received from the parent network.

   4rd client (4rd-C):  A function that obtains mapping rules from a 4rd
      server, derives from them its own IPv4r locator, and tunnels IPv4r
      packets across its 4rd network.

   4rd BR:  A router that supports one or several 4rd servers (Border

   4rd CE:  A node supports a 4rd client and is in a customer position
      on a 4rd network.  It may be a host, a router, or both.

Despres                  Expires April 21, 2011                 [Page 4]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   network PMTU:  For an identified address family, the packet size that
      must not be exceed to traverse the network without risk of packets
      being discarded (in IPv6) or fragmented (in IPv4).

3.  Applicability

   For 4rd to actually be used across a network, the network must be a
   4rd network, and must have at least one 4rd CE.

                 4rd CE              4rd NETWORK
          ---------------------+   \  .-----.
                               |    \/       \
          IPv6           +-----+    /         \                  IPv6
          <--------------=4rd-C=---= IPv6-only =-------------------->
                         +--.--+    \ routing /
                            |  |    /\       /\
          IPv4r             |  |   /  '-----'  \       +-----+
          <-----------------O  |                \IPv6 +-----+| IPv4r
                            |  |                 '----+4rd-S+------->
                            .  |                      +-----+
           IPv4p +-----+   /   |                     4rd BR(s)
          <------+NAT44+--'    |
                 +-----+       |

                  4rd ACROSS AN IPv6-ONLY ROUTING NETWORK

                                 Figure 1

   If the interior address family is IPv4p, the operator of must know
   the PMTU of its 4rd network.

   Figure 1 shows a scenario where the interior address family is IPv6.
   In the CE, the IPv4r interface of the 4rd client can be used to
   provide global IPv4 addresses and reserved ports to a socket API
   and/or to a NAT44.  This NAT can use them for its port-forwarding
   function, be it configured administratively or by means of UPnP or
   NAT-PMP.  If both a socket API and a NAT44 share the set of available
   addresses and ports, a static switch can do split.

Despres                  Expires April 21, 2011                 [Page 5]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   This scenario doesn't exclude other ways to offer IPv4 connectivity
   across the same IPv6-only routing network (typically DS-lite and/or
   NAT64/DNS64).  Note however that, with each IPv4 address shared
   between 16 customers, each customer obtains with 4rd 3840 global-IPv4
   ports (in addition to its 65 536 ports per IPv6 address), and the
   available IPv4 address space is multiplied by 16.  Since most port-
   consuming applications should quickly be reachable in IPv6 (Google
   Maps in particular is already in this case) this should be largely
   sufficient in many scenarios.

   Figure 2 shows a scenario where the interior address family is IPv4p
   and where the IPv6 service is supported with 6rd.  The 4rd CE
   architecture is similar to that of the previous example with two
   differences: IPv6, instead to be directly available at the network
   interface, is obtained by means of a 6rd-CE function; the NAT44, if
   present, can use as external addresses not only those of its IPv4r
   locator but also the IPv4 address assigned to the CE in the 4rd
   network.  How the NAT44 uses this external address set is an
   implementation matter, but it can be noted that applications that are
   known to traverse cascades of NATs without problem (Web, DNS, and
   Mail, in particular) can use IPv4p addresses.  IPv4r addresses are
   thus kept for IPv4 connections that may need end-to-end transparency.

             4rd CE                                      +-----+
   -----------------------------+                  IPv4p |     |   IPv6
                                |                  .-----+ 6rd +------->
   IPv6                         |   4rd NETWORK   /      | BR  |
   <-----------------.          |                /       +-----+
                      \         |  \  .------.  /
         +-----+    +--'--+-----+   \/        \/         +-----+
         |     |    |     |     |   /          \  IPv4p  |     |   IPv4r
   <-----+NAT44+----= 6rd =4rd-C=--= IPv4p-only =--------+NAT44+-------->
   IPv4p |     |\   | CE  |     |   \ routing  /         |     | or IPv4p
         +-----= \  +-----+--.--+   /\        /\         +-----+
                  \         /   |  /  '------'  \
   <---------------O-------'    |                \         +-----+
   IPv4r                        |                 \ IPv4p +-----+| IPv4r
                                |                  '------+4rd-S+------->
   -----------------------------+                         +-----+
                                                          4rd BR(s)

                 4rd ACROSS AN IPv4p-ONLY ROUTING NETWORK

                                 Figure 2

Despres                  Expires April 21, 2011                 [Page 6]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   Figure 3 shows a scenario where both IPv6 and IPv4p are routed.  The
   main difference with the IPv4p-only routing case is that 6rd is not
   needed.  Tunnels for IPv4r packets can use IPv6 or IPv4p depending on
   local policies.

             4rd CE
   -----------------------------+                                  IPv6
                                |                  .------------------>
   IPv6                         |   4rd NETWORK   /
   <-----------------.          |                /
                      \         |  \  .------.  /
         +-----+       \  +-----+   \/        \/         +-----+
         |     | IPv4p  \ |     |   /   Ipv6   \  IPv4p  |     |   IPv4r
   <-----+NAT44+---------'=4rd-C=--=  and Ipv4p =--------+NAT44+-------->
   IPv4p |     |\         |     |   \  routing /         |     | or IPv4p
         +-----= \        +--.--+   /\        /\         +-----+
                  \         /   |  /  '------'  \  IPv4p
   <---------------O-------'    |                \  or     +-----+
   IPv4r                        |                 \ IPv6 +-----+| IPv4p
                                |                  '------+4rd-S+------->
   -----------------------------+                         +-----+
                                                          4rd BR(s)


                                 Figure 3

   NOTE: The above scenarios can apply not only to 4rd networks operated
   to ISPs but also to private networks.  A CPE that supports a 4rd
   server can, when it has an IPv4r locator, share it among hosts of its
   site that support 4rd clients.  This is in practice a static
   alternative to UPnP and NAT-PMP for hosts to still have some IPv4
   incoming connectivity.

Despres                  Expires April 21, 2011                 [Page 7]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

4.  The 4rd Protocol Specification

4.1.  Mapping Rules

   4rd mapping rules establish 1:1 mappings between interior and
   exterior locators.  Each rule Ri comprises:

   Di :  the "rule exterior prefix"

   Pi :  the "rule interior prefix"

   xi :  the "index length", i.e. the length of the field X that, for a
      given 4rd client is common to its interior and exterior locators.

   Di's of all rules of a 4rd network must be non overlapping prefixes,
   and the same for Pi's.

                                4rd NETWORK
                   IPv6 or IPv4p interior routing
             Mapping rules:  Ri = {Di, Pi, xi}, i=1,2,...

                     ----|                      |     4rd BRs
             4rd CE      |                      |   +-------+
            +-------+    | Interior locator     |  +-------+|
            |       |    | I=Pi.X /pi+xi     G  |  |       || IPv4r
   <--------= 4rd-C =----+<---             ---->+--+ 4rd-S +<---------
            |       |    |                      |  |       |+ D1,D2,...
            +---+---+    |                      |  +-------+
               /         |                      |
   <----------'      ----|                      |
   IPv4r locator         +----------------------+
   E=Di.X /di+xi                            G: 4rd border anycast address

                         4rd LOCATOR MAPPING RULES

                                 Figure 4

   Figure 4 shows how the exterior locator "E" of a 4rd client is
   derived from its interior locator "I".  E comprises the Di of the
   rule whose Pi is recognized at the beginning of I, followed by index
   X whose length is the xi of the rule, and which is copied from the I
   after the its Pi.  In this document field acronyms are uppercase, and
   lengths of fields are the same letters in lower case.  (Thus,

Despres                  Expires April 21, 2011                 [Page 8]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   "/pi.xi" represents a locator length that is the sum of Pi's length
   and xi).

   To derive an interior address from an exterior address, the reverse
   logic is used.  In this document, Y... represents any address that
   starts with prefix Y. The interior locator I derived from exterior
   address E... then comprises the Pi of the rule whose Di matches the
   beginning of E..., followed by index X whose length is the xi of the
   rule and which is copied from E... after its bits used to match Di.
   If the obtained I is shorter than a complete interior address, it is
   completed with zeroes.  If no rule applies (no Di found in E), the
   interior locator is the 4rd-server interior address G (an anycast

4.2.  Packet Encapsulations/Decapsulations

                Mapping rules:  Ri = {Di, Pi, xi}, i=1,2,...

                              iSRC = (Pi.X /pi+xi).0 /g
                              iDST = G
                    4rd CE    iPRO = "SAM"            4rd BR(s)
                   +-------+  eSRC = E...             +-------+
                   |       |  eDST = not any (Dj...)  |       |
                   |       |                          |       |
   E = Di.X /di+xi |       | I=Pi.X /pi+xi         G  |       |D1,D2,...
   <---------------| 4rd-C |<-------------        --->| 4rd-S |<-------
                   |       |                          +-------+
                   |       |    PACKET
                   |       |  iSRC = I.0 /g
                   |       |  iDST = Pj.(eDST-Match(Dj) /xj).0 /g
                   |       |  iPRO = "SAM"
                   |       |  eSRC = E...
                   |       |  eDST = Dj...
                   |       |                 \
                   +-------+                  \
                             other 4rd CEs   /


                                 Figure 5

Despres                  Expires April 21, 2011                 [Page 9]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   When a 4rd client or server receives a packet at its IPv4r interface
   (a pseudo interface in the client case), it checks the validity of
   its source and destination addresses.  It also checks that the packet
   size is acceptable (see Section 4.4).  If yes, it encapsulates it in
   an interior packet and forwards it via its interior interface.

   The Next-header field, if interior addresses are IPv6, of the
   Protocol field if they are IPv4p, a value to be assigned by IANA for
   4rd and for other applications of the SAM of [1] (SAM).  A specific
   value for SAM is preferred to a re-use of Protocol 41, used for IP-
   in-IP encapsulations of 6to4, ISATAP, and 6rd, because this ensures
   that coexistence with these without risk of incompatibility.

   Symmetrically, a 4rd client or 4rd server that receives a packet at
   its interior interface checks the validity of source and destination
   addresses in both its encapsulating and encapsulated packets.  It
   also checks that they are mutually consistent with mapping rules of
   the 4rd network.  If yes it decapsulates the IPv4r packet contained
   in the encapsulating packet, and forwards it its IPv6 interface.

   Details on which addresses are acceptable in which packets are
   detailed in Figure 5, where SRC and DST respectively mean source and
   destination, PRO means protocol, where iXXX and eXXX respectively
   refer to interior and exterior address families.

4.3.  Port sets of IPv4r prefixes longer than /32

   The port-set identifiers S of an IPv4r prefix of length s in the
   range 33 to 47 consists in the s-32 bits beyond the first 32.  The
   port set it identifies is specified with the following constraints:

   "Exclusiveness"  Port sets of two S's must be disjoint if the S's are
      non overlapping prefixes (10 and 1011 do overlap while 10 and 1110

   "No administration"  The port set of S must be algorithmically
      derived from S without depending on any parameter.

   "Fairness-1"  Port sets of two S's of same lengths must contain the
      same number of ports.

   "Fairness-2"  No port-set may contain any port 0 to 4095 (these have
      more value than others in OS's, and are normally not used in
      dynamic port assignments to applications).

Despres                  Expires April 21, 2011                [Page 10]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   "Exhaustiveness"  All ports other than 0-4095 must be assignable.

   Figure 6 shows the relationship between port set identifiers and port
   sets.  Each port set is composed of up to 4 port ranges, each one
   being defined by its port prefix PPk.

          <-------- IPv4r prefix /33 to /47 ---------->
         |                                             |
          <----------- IPv4 address -----------><- S ->
                                             Port-set identifier

       Port prefixes of the the port set identified by S:
           PP1  1<- S ->
           PP2  01<- S ->  (only if s < 15)
           PP3  001<- S ->  (only if s < s14)
           PP4  0001<- S ->  (only if s < s13)

           s < 13    =>    2^(16-s)*15/16 ports
           s = 13    =>    7 ports
           s = 14    =>    3 ports
           s = 15    =>    1 port

          <----- IPv4r address matching a IPv4r prefix > /32 ----->
          |                                                        |
          <-------------------- 32 bits -------><---- 16 bits ---->
          |                                     |                  |
          <-------- global IPv4 address ------->< PPk >< any bits >


                                 Figure 6

   Note that, due to the above constraints on port sets, a 48-bits IPv4r
   address that matches an IPv4r prefix Di longer than /32 doesn't start
   with the complete Di.  Its port number (bits 32 to 48 of the IPv4r
   address) rather starts with one of the PPk prefixes of the set
   identified by the S contained in bits 32 to s-1 of Di.

Despres                  Expires April 21, 2011                [Page 11]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

4.4.  PMTU Considerations

   To properly deal with large size IPv4 datagrams that are fragmented
   before entering a 4rd network, precautions have to be taken because:

   o  In IPv4, intermediate nodes may have to forward packets that are
      longer than the MTU of next links to be traversed.  For this, they
      fragment packets within the network.

   o  In IPv6, such packets are discarded, with ICMP Packet Too Big
      ICMPv6 error packets returned to sources, but with all IPv6 links
      having to support MTUs of at least 1280 octets.

   To cope with these constraints, 4rd clients and 4rd servers can
   reassemble multi-fragment IPv4 datagrams before processing them.
   (This function is stateful at the IP layer like the same function in
   NATs.  But at the transport layer, 4rd remains stateless whereas NATs
   are stateful, a source of operational complexity that is avoided with

   Each datagram, after fragment reassembly if needed, is forwarded
   either in a single packet, if with its encapsulation header it fits
   in the network PMTU, or in as many packets as needed for each one to
   fit in this PMTU.  Optimized treatments are possible, whereby first
   parts of datagrams are forwarded without waiting for complete
   datagram reassembly, but this is an implementation matter that
   doesn't belong to the scope of this specification.)

4.5.  Parameter Acquisitions by 4rd Clients

   The 4rd-server address G may be obtained in various ways.  It may be
   administratively configured (typically applicable if the 4rd network
   operator provides its own 4rd CEs).  It can also be obtained in DHCP
   [RFC2131], DHCPv6 [RFC3315], Radius [RFC2865], or Diameter [RFC3588].
   For these, IANA assigned numbers for 4rd remain to be chosen.  In
   absence of all these means, G can be taken as the well-known address
   of SAM servers in the applicable interior address family (also to be
   assigned by IANA).

   If a 4rd client has Gs for both IPv6 and IPv4p, it may try both and
   settle for either one from which it obtains responses.

   To obtain its mapping rules and their common lifetime, a 4rd client
   sends a 4rd "Parameter Request" message to the 4rd-server anycast
   address G. It retransmits it until it obtains an answer, typically
   with longer time intervals after several unsuccessful attempts.  When
   it receives a 4rd "Parameter Indication" message with the 4rd-server
   anycast address as source, it derives from the contained mapping

Despres                  Expires April 21, 2011                [Page 12]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   rules its own IPv4r locator.  It also stores these rules for its
   future packet encapsulations/decapsulations.

   4rd messages are transmitted in payloads of 4rd interior packets at
   the same place as encapsulated exterior packets.  Their first octet
   is set to 0, a "Message Mark" which permits to distinguish 4rd
   messages from encapsulated packets (IPv4 packet headers all start
   with a 4 in the first 4 bits).

    +-----------+--- ... ---+--     --+--- ... ---+-- ... --+
    | msg mark  |           |         |           |         |
    |   (= 0)   |   rule 1  |   ...   |   rule n  |lifetime |
    +-----------+--- ... ---+--     --+--- ... ---+---------+
      1 octet   |            \______________       parameter
                |                           \
                +-- ... --+-- ... --+---...--+
                |   D1    |   P1    |   x1   |
                +-- ...---+-- ... --+---...--+
                parameter  parameter parameter

                              <--------- L octets ---------->
                       +------+------+------+-- ... --+------+
    Parameter Format:  | Type |   L  |         Value         |
                       +--|---+------+------+-- ... --+------+
                         0x1F :  xi (L = 2)
                         0x2F :  Lifetime (L = 3)
                         0x4n :  IPv4 prefix (L = 2 to 5)
                         0x6n :  IPv6 prefix (L = 2 to 9)
                            n = number of useful bits in the last octet


                                 Figure 7

   A 4rd Parameter Request is sent with no information after the 4rd
   Message Mark.  In order to facilitate future extensions that may
   prove useful, 4rd servers should ignore octets that may be received
   after this mark.

Despres                  Expires April 21, 2011                [Page 13]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   After the Message Mark, a 4rd Parameter Indication contains one or
   several rules, followed by a lifetime expressed in seconds.  Each
   rule starts with its rule exterior prefix Di, followed by its rule
   interior prefix Pi, followed by its index length xi.

   Detailed formats are shown on Figure 7.

5.  Example with IPv6-only Routing and Shared IPv4 Addresses

   With the protocol of Section 4, each public network operator and each
   private network administrator can make its own parameter choices.

                      |     IPv6-ONLY ROUTING    |
                      |                          |
                      | * Common prefix K/24     |
                      | * Assigned prefixes /48  |
     CUSTOMER SITES   |     => 2^24 customers    |
    (3840 ports each) |                          |
             |        |                          | IPv4
             v        |               G /128 --->O<----
    ==================+                          | D1/13 |
                 <----O<--- I1=(P1=K.C1).X /48   | D2/14 |2^20 addresses
                     /|                          | D3/14 |
    E1=D1.X /36  <--' |                          |
        x=23          |                          |
    ==================+                          |
                 <----O<--- I2=(P2=K.C2).X /48   |
                     /|                          |
    E2=D2.X /36 <--'  |                          |
        x=22          |                          |
    ==================+                          |
                 <----O<--- I3=(P3=K.C3).X /48   |
                     /|                          |
    E3=D3.X /36 <--'  |                          |
        x=22          |                          |
    ==================+                          |

          Rules: {D1/13, P1=K.C1/25, x1=23} with C1=0b0
                 {D2/14, P2=K.C2/26, x2=22} with C1=0b10
          Rules: {D3/14, P3=K.C3/25, x3=23} with C1=0b11


                                 Figure 8

Despres                  Expires April 21, 2011                [Page 14]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

   The following example illustrates the case of an ISP that operates an
   IPv6-only routing network and assigns shared global IPv4 addresses to
   its customers.  The ISP has 2^24 customers whose /48 prefixes start
   with a common prefix K/24.  In IPv4, it has three global IPv4
   prefixes, R1/13, R2/14, R3/14, giving a total of 2^20 addresses.
   Each of these addresses must therefore be shared among 16 customers.
   Exterior locators E must therefore be /36s, comprising port-set
   identifiers S having 4 bits (each customer is thus assigned 2^12*15/
   6=3840 reserved ports in global IPv4).  Each interior prefix I/48
   must then be composed of the common prefix K followed by the short
   identifier Ci of one of the three Di's.  Their lengths have to be
   related to lengths of Di's by the formula ci=(i-k)-(e-di), which
   gives c1=1, c2=2, and c3=2.  Within these constraints, bit values of
   the Ci's may be arbitrary non overlapping prefixes, e.g.  C1 = 0bO,
   C2=0b10, C3 =0b11 (with 0bXXX being the binary number XXX).  Rule are


   o  It the ISP would have preferred to have only one rule, this would
      have been possible by using in IPv4 only the /13.  Then port-set
      identifiers S would have had 5 bits, and each customer would have
      had 1920 ports in global IPv4.

   o  If instead of one K/24, the ISP there would have had to use two
      different prefixes, K1/25 and K2/25, mapping rules could have been
      {D1/13, P1=K1/25, x1=23}, {D2/14, P2=K2.C2/26, x2=22}, and {D3/14,
      P3=K2.C2/26, x3=22}, with C2=0b0 and C3=0b1.

   o  If, in a more complex scenario, the ratio between number of
      customers and number of IPv4 addresses would not have been a power
      of two, either some interior addresses or some exterior addresses
      would have had to be sacrificed (not assigned).  For example, with
      K1/25, K2/26, and D1/14, D2/15, D3/15, D4/15, giving 2^23+2^22
      customers and 2^19+2^15 IPv4 addresses, rules could have been
      {D1/14, P1=K1.C1/26, x1=22}, {D2/15, P2=K1.C2/27, x2=21}, {D3/15,
      P3=K1.C3/27, x3=21}, {D4/15, P4=K2.C4, x4=21}, with C1=0b0,
      C2=0b10, C3=0b11, C4=0.

Despres                  Expires April 21, 2011                [Page 15]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

6.  Security considerations

   Spoofing attacks

      With address-consistency checks of Section 4.2, authentication
      verifications that apply interior locators also apply, indirectly,
      to exterior locators.  Similarly, anti-spoofing protections that
      apply to interior addresses also apply, indirectly, to exterior
      locators. 4rd should therefore introduce no opportunity of its own
      for spoofing attacks.

   Denial-of-service attacks

      Reassembly of fragmented exterior datagrams introduces an
      opportunity for some form of DOS attacks, shared with NAT-based
      solutions.  Note that this risk among reason to prefer native IPv6
      to native IPv4 when there is the choice for a transport

      Risks of DOS attacks at the transport-connection layer, to which
      NAT-based solutions are exposed, are avoided in 4rd because of its
      the stateless operation of this layer.

   Faked 4rd servers

      If a 4rd CE uses as 4rd server address one of the two IANA
      assigned well-known address for this in IPv6 and IPv4, and if its
      ISP network has no 4rd server, packets addressed to it can be
      forwarded to the Internet backbone.  They should however not reach
      any faked 4rd server because, this address starting with none of
      prefixes routed to other ISP networks, they will normally be
      discarded in the backbone.  However, whether some additional
      protection in would be appropriate against fake 4rd servers (e.g.
      with a nonce in Parameter Requests and Parameter Indications), is
      still viewed as an open issue.

   Routing-loop attacks

      Routing-loop attacks that may exist in some automatic-tunneling
      scenarios are documented in [3].  They cannot exist with 4rd
      because its address checks of Section 4.2 prevent multiple
      traversals of a 4rd network by the same IPv4r packet, and because,
      4rd using its own Protocol number, routing-loops between nodes of
      nodes working with two different tunnel protocols are also

Despres                  Expires April 21, 2011                [Page 16]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

7.  IANA Considerations

   This specification depends on the following number assignments by

   o  The SAM protocol number (Section 4.2)

   o  The DHCP and DHCPv6 4rd option codes (Section 4.5)

   o  The Radius 4rd attribute type (Section 4.5)

   o  The SAM-server well-known addresses, in IPv4 and IPv6
      (Section 4.5)

8.  Acknowledgments

   The author has benefited from useful informal discussions with a
   number of IETF participants on previous SAM proposals, from which
   this specification is a by-product.  Concerning 4rd in particular,
   Satoru Matsushima deserves special recognition, first for the
   interest in the approach he expressed from the beginning, but also
   for his constructive contributions, including his proposal of the 4rd
   acronym, and for convincing his colleagues to make actual deployment
   plans with this technology.  Olivier Vautrin, by independently
   proposing the same acronym for a similar orientation, has to be
   thanked for the valuable encouragement this has been.

9.  References

9.1.  Normative References

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

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

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,

Despres                  Expires April 21, 2011                [Page 17]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

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

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

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

9.2.  Informative References

   [1]        Despres, R., "Stateless Address Mapping (SAM) - a
              Simplified Mesh-Softwire Model -
              draft-despres-softwire-sam-01 - work in progress",
              July 2010.

   [2]        Vautrin, O., "IPv4 Rapid Deployment on IPv6
              Infrastructures (4rd) - draft-vautrin-softwire-4rd-00 -
              work in progress", July 2010.

   [3]        Nakibly, G. and F. Templin, "Routing Loop Attack using
              IPv6 Automatic Tunnels: Problem Statement and Proposed
              Mitigations - draft-ietf-v6ops-tunnel-loops-00 - Work in
              progress", September 2010.

   [DNS64]    Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers
              [draft-ietf-behave-dns64 - work in progress]",
              October 2010.

   [DS-lite]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4 Exhaustion
              [draft-ietf-softwire-dual-stack-lite - work in progress]",
              August 2010.

   [NAT64]    Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              - Clients to IPv4 Servers
              [draft-ietf-behave-v6v4-xlate-stateful - work in
              progress]", July 2010.

Despres                  Expires April 21, 2011                [Page 18]

Internet-Draft        IPv4 Residual Deployment(4rd)         October 2010

Author's Address

   Remi Despres
   3 rue du President Wilson

   Email: remi.despres@free.fr

Despres                  Expires April 21, 2011                [Page 19]

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