[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
Internet Engineering Task Force                          R. Despres, Ed.
Internet-Draft                                                 RD-IPtech
Intended status: Standards Track                           S. Matsushima
Expires: September 8, 2011                                      SoftBank
                                                             T. Murakami
                                                             IP Infusion
                                                                O. Troan
                                                                   Cisco
                                                           March 7, 2011


      IPv4 Residual Deployment across IPv6-Service networks (4rd)
                         ISP-NAT's made optional
                      draft-despres-intarea-4rd-00

Abstract

   This document specifies an automatic tunneling mechanism for
   providing IPv4 connectivity service to end users over a service
   provider's IPv6 network infrastructure.  During the long transition
   period from IPv4-only to IPv6-only, a service provider's network
   infrastructure will have to deploy IPv6.  But it will also have to
   maintain some IPv4 connectivity for a number of customers, 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.

   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.

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 September 8, 2011.




Despres, et al.         Expires September 8, 2011               [Page 1]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


Copyright Notice

   Copyright (c) 2011 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.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Mapping Rules  . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  From an IPv6 Prefix to a 4rd Prefix  . . . . . . . . . . .  5
     4.2.  From a 4rd Prefix longer than 32 bits to a Port-set ID . .  6
     4.3.  From a Port-Set ID to a Port Set . . . . . . . . . . . . .  6
     4.4.  From an IPv4 Address or IPv4 address + Port to a CE
           IPv6 address . . . . . . . . . . . . . . . . . . . . . . .  8
     4.5.  MTU Considerations . . . . . . . . . . . . . . . . . . . .  9
   5.  4rd Configuration  . . . . . . . . . . . . . . . . . . . . . .  9
   6.  BR and CE behaviors  . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Encapsulation and IPv6 Fragmentations  . . . . . . . . . . 10
     6.2.  Domains having only One Mapping rule . . . . . . . . . . . 11
       6.2.1.  BR reception of an IPv4 packet . . . . . . . . . . . . 11
       6.2.2.  BR reception of an IPv4/IPv6 packet  . . . . . . . . . 12
       6.2.3.  CE reception of an IPv4 packet . . . . . . . . . . . . 12
       6.2.4.  CE reception of an IPv4/IPv6 packet  . . . . . . . . . 13
     6.3.  Domains having Multiple Mapping Rules (TBD)  . . . . . . . 13
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15







Despres, et al.         Expires September 8, 2011               [Page 2]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


1.  Introduction

   During the long transition period from only IPv4-only to IPv6-only,
   Internet-service providers (ISP's), will sooner or later deploy
   networks where routing is IPv6-only.  Some of them will do so while
   they still have to offer residual IPv4 connectivity for the service
   to remain dual-stack.  While this connectivity may be offered to
   privileged customers with in exclusive global addresses, more and
   more other customers will only have shared IPv4 addresses.  In this
   document, "ISP" is used as a generic term.  It includes DSL or
   Broadband service providers, mobile operators, and private operators
   of networks of any sizes.

   4rd (IPv4 Residual Deployment) is a generic lightweight solution for
   the residual support of global IPv4 connectivity across IPv6-only
   routing networks.  As such, it is the reverse of 6rd (IPv6 Rapid
   Deployment) whose purpose is to rapidly introduce native IPv6
   connectivity across IPv4-only routing infrastructures.  It applies
   the same principles of automatic tunneling, an stateless address
   mappings between IPv4 and IPv6.

   On the tradeoff scale between efficiency of address sharing ratios
   and simplicity, 4rd is on the side of design and operational
   simplicity.

   Depending on ISP constraints and policies, 4rd can be used either
   alone, with no NAT needed in ISP infrastructures, or in parallel with
   NAT based solutions such as DS-lite
   [I-D.ietf-softwire-dual-stack-lite] and NAT64/DNS64
   [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-dns64].

   At the time of writing, four ISP's in Japan have expressed interest
   for deploying 4rd (www.ietf.org/mail-archive/web/v6ops/current/
   msg05247).

   This draft is still in an early stage.  So far, it specifies details
   only for domains that have one mapping rule.  In order to permit more
   flexible services, a next version is being worked on to deal with
   multiple mapping rules.


2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].





Despres, et al.         Expires September 8, 2011               [Page 3]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


3.  Terminology

   4rd domain (Domain):  an IPv6 routing network operated by an ISP and
                         comprising one or several 4rd relays operating
                         with the same set of parameters.  It offers to
                         its 4rd-capable customers global IPv4
                         connectivity, both outgoing and incoming, and
                         with exclusive or shared IPv4 addresses.

   4rd Border Relay (BR):  A 4rd-enabled router managed by the service
                         provider at the edge of 4rd domain.  A BR has
                         an IPv6-enabled interface connected to the ISP
                         routing network, and an IPv4 virtual interface
                         acting as an endpoint for the automatic 4rd
                         tunnel.  This tunnel (IPv4 in IPv6) is between
                         the BR and all CE's of the Domain.

   4rd Customer Edge (CE):  A node at the border between a customer
                         infrastructure and the 4rd domain.  This node
                         has an IPv6 interface connected to the ISP
                         routing network, and a virtual IPv4 interface
                         acting as the end-point of the automatic 4rd
                         tunnel.  This tunnel (IPv4 in IPv6) is between
                         the CE and all other CE's and all BR's of the
                         Domain.  It may be a host, a router, or both.

   CE IPv6 prefix:       The IPv6 prefix assigned to a CE independently
                         from 4rd.

   CE IPv6 address:      In the context of 6rd, the IPv6 address used to
                         reach a CE from other CE's and from BR's.  A CE
                         typically has another IPv6 address, assigned to
                         it at its IPv6 interface without relationship
                         with 6rd.

   CE 4rd prefix:        The 4rd prefix of the CE.  It is derived from
                         the CE IPv6 prefix by a mapping rule according
                         to Section 4.  Depending on its length, it is
                         an IPv4 prefix, an IPv4 address, or a shared
                         IPv4 address followed by a Port-set ID
                         (Section 4.2).

   Port-set ID:          In a CE 4rd prefix longer than 32 bits, bits
                         that follow the first 32.  It identifies a set
                         of ports exclusively assigned to the CE.  As
                         specified in Section 4.3, the set contains up
                         to 4 port ranges, each range being defined by
                         its port prefix.



Despres, et al.         Expires September 8, 2011               [Page 4]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


   Domain IPv6 prefix:   An IPv6 prefix assigned by an ISP to a 4rd
                         domain.

   Domain 4rd prefix:    A 4rd prefix assigned by an ISP to the 4rd
                         domain.  In typical operator applications, it
                         is an IPv4 prefix.  In a residential site in
                         which an already shared IPv4 address has to be
                         shared even more among several hosts, it may
                         have more than 32 bits.

   CE index:             In a CE IPv6 prefix, all bits that follow the
                         Domain IPv6 prefix.  It is also, in a CE IPv4
                         prefix, all bits that follow the BR IPv4
                         prefix.


4.  Mapping Rules

4.1.  From an IPv6 Prefix to a 4rd Prefix

   A 4rd mapping rule establishes a 1:1 mapping between CE IPv6 prefixes
   and CE 4rd prefixes.


          <---------------- CE IPv6 prefix (max 64) -------------->
          +-------------------------------+------------------------+
          |      Domain IPv6 prefix       |        CE index        |
          +-------------------------------+------------------------+
          <-- Domain IPv6 Prefix length -><--- CE index length --->:
                                          :                        :
                                          :         ||             :
                                          :         \/             :
                                          :                        :
                                          <--- CE index length --->:
                     +-------------------+------------------------+
                      | Domain 4rd prefix |        CE index        |
                      +-------------------+------------------------+
                      <----------- CE 4rd prefix (max 47) -------->

               Figure 1: From an IPv6 Prefix to a 4rd Prefix

   A CE derives its CE 4rd prefix from the IPv6 prefix it has been
   delegated on the IPv6-routing network, using for this parameters of
   the applicable mapping rule.  If the domain has several mapping
   rules, that which applies is that whose Domain IPv6 prefix is at the
   beginning of the CE IPv6 prefix.  As shown in Figure 1, the CE 4rd
   prefix is made of the Domain 4rd prefix followed by the CE index,
   where the CE index is the remainder of the CE IPv6 prefix after the



Despres, et al.         Expires September 8, 2011               [Page 5]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


   Domain IPv6 prefix (the length of the Domain IPv6 prefix is defined
   by the mapping rule).

4.2.  From a 4rd Prefix longer than 32 bits to a Port-set ID

   Depending on its length, a CE 4rd prefix is either an IPv4 prefix, a
   full IPv4 address, or a shared IPv4 address followed by a Port-set ID
   (Figure 2).  If it includes a port set ID, this ID specifies which
   ports are assigned to the the CE for its exclusive use.  This set,
   composed of up to 4 port ranges, is algorithmically derived from the
   Port-set ID (see Section 4.3).


                          <-- CE 4rd prefix length -->
                          +--------------------------+- - -+
     Shorter than 32 bits |       IPv4 prefix        | ... |
                          + -------------------------+- - -+


                          <----- CE 4rd prefix length ----->
                          +--------------------------------+
           32 bits        |          IPv4 address          |
                          +--------------------------------+
                          <--------------- 32 ------------->


                          <----------- CE 4rd prefix length ---------->
                          +-------------------------------+-----------+
         33 to 47 bits    |      IPv4 shared address      |Port-set ID|
                          +-------------------------------+-----------+
                          <--------------- 32 -----------><- max 15 -->

                   Figure 2: Variants of CE 4rd prefixes

4.3.  From a Port-Set ID to a Port Set

   Each value of a Port-set ID specifies which ports can be used by any
   protocol whose header format starts with source and destination ports
   (UDP, TCP, SCTP, etc.).  Design constraint of the algorithm are the
   following:

   "Fairness with respect to special-value ports"
        No port-set must contain any port from 0 to 4095.  (These ports,
        which have more value than others in OS's, are normally not used
        in dynamic port assignments to applications).






Despres, et al.         Expires September 8, 2011               [Page 6]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


   "Fairness with respect to the number of ports"
        For a Port-set-ID's having the same length, all sets must have
        the same number of ports.

   "Exhaustiveness"
        For a any Port-set-ID length, the aggregate of port sets
        assigned for all values must include all ordinary-value ports
        (from 4,096 to 16,384).

   If the Port-set ID has 1 to 12 bits, the set comprises 4 port ranges.
   As shown in Figure 3, each port range is defined by its port prefix,
   made of a range-specific "head" followed by the Port-set ID.  Head
   values are in binary 1, 01, 001, and 0001.  They are chosen to
   exclude ports 0-4095 and only them.


                   <------- Port (16 bits) -------->
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Port-range a    |1|x x x x x x x x|             |  0xF780 - 0xF7FF
    (head = 1)     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      \               \
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Port-range b    |0 1|x x x x x x x x|           |  0x7BC0 - 0x7BFF
    (head = 01)    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        \               \
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Port-range c    |0 0 1|x x x x x x x x|         |  0x3DE0 - 0x3DFF
    (head = 001)   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          \               \
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Port-range d    |0 0 0 1|x x x x x x x x|       |  0x1EF0 - 0x1EFF
    (head = 0001)  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   <- head-><--Port-set ID->                 /\
                   <-- Port-range prefix --><-tail->         ||
                                                             ||
                                                Example of Port-ranges
                                              if the Port-set ID is 0xEF

                 Figure 3: From Port-set ID to Port ranges

   In the Port-set ID has 13 bits, only the 3 port ranges are assigned,
   having heads 1, 01, and 001.  If it has 14 bits, only the 2 port
   ranges having heads 1 and 01 are assigned.  If it has 15 bits, only
   the port range having head 1 is assigned.  (In these three cases, the
   smallest port range has only one element).

   Note: The port set assigned to a CE may be further subdivided by the
   CE among several functions such as the following: (1) an IPv4 NAPT



Despres, et al.         Expires September 8, 2011               [Page 7]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


   (possibly configurable to do port forwarding, and possibly doing
   dynamic port assignments to hosts with UPnP and/or NAT-PMP); (2) an
   API for applications in the CE that need dynamic port assignments;
   (3) a new 4rd BR which assigns to its CE's subsets of its own port
   set.  How to chose among these functions and/or combine them is
   beyond the scope of this specification.  Readers are referred to
   documents dealing with operational applicability in diverse
   environments, e.g. [draft-sun-intarea-4rd-applicability] prepared in
   parallel of this one.

4.4.  From an IPv4 Address or IPv4 address + Port to a CE IPv6 address



                       Port-set ID
                            |
      <--- CE 4rd prefix ---|->
      +---------------+---+-|--+
      |IPv4 shared address| '  |
      +---------------+---+----+
                      <-------->
                    CE-index length
                      :        :
                      :   ||   :
                      :   ||   :
                      :   \/   : Domain IPv6 suffix
                      :        :  |
   +------------------+--------+--|-+----------------------------------+
   |Domain IPv6 prefix|CE index|  ' |                  0               |
   +------------------+--------+----+----------------------------------+
   <------------ max 64 ------------>
   <---------------------- CE IPv6 address (128) --------------------->

           Figure 4: From a CE 4rd Prefix to the CE IPv6 address

   In order to find whether a CE IPv6 address can be derived from an
   IPv4 address, or an IPv6 address + a port, a mapping rule has to be
   found that matches the IPv4 information:

   o  If a mapping rule has a length L of CE IPv4 prefixes which does
      not exceed 32 bits, there is a match if the IPv4 address starts
      with the Domain 4rd prefix.  The CE 4rd prefix is then the first L
      bits of the IPv4 address.

   o  If a mapping rule has a length L of CE IPv4 prefixes which exceeds
      32 bits, the match can only be found with the IPv4 address and the
      port.  For this, the port is examined to determine which port-
      range head it starts with: 1, 01,001, or 0001.  The N bits that



Despres, et al.         Expires September 8, 2011               [Page 8]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


      follow this head are taken as Port-set ID, where N is the length
      of Port set ID of the mapping rule.  The CE 4rd prefix is then
      made of the IPv4 address followed by the Port-set ID.

      If a match has been found, the CE IPv6 prefix is then made of the
      Domain IPv6 prefix followed by bits of the CE 4rd prefix that
      follow the Domain 4rd prefix, followed by the Domain IPv6 prefix
      of the mapping rule if there is one, and followed by 0's up to 128
      bits to satisfy [RFC4291].  Figure 4 illustrates this process in
      the case of a shared IPv4 address.

4.5.  MTU Considerations

   The maximum size of IPv4 packets that are forwarded across a 4rd
   domain must be the path MTU of the domain minus the 40 octets (the
   length of the encapsulation header).  (Otherwise, due to the
   impossibility of intermediate IPv6 nodes to fragment packets, they
   might be discarded during domain traversal.)  Absent more specific
   indication, this path MTU has to be set to 1280, the minimum size
   that all IPv6 networks must support.

   o  In domains where IPv4 addresses are not shared, IPv6 destinations
      are derived from IPv4 addresses alone.  Thus, each IPv4 packet can
      be encapsulated and decapsulated independently of each other. 4rd
      processing is completely stateless.

   o  On the other hand, in domains where IPv4 addresses are shared,
      BR's and CE's can have to encapsulate IPv4 packets whose IPv6
      destinations depend on destination ports.  Precautions are needed,
      due to the fact that the destination port of a fragmented datagram
      is available only in its first fragment.  A sufficient precaution
      consists in reassembling each datagram received in multiple
      packets, and to treat it as though it would have been received in
      single packet.  This function is such that 4rd is in this case
      stateful at the IP layer.  (This is common with DS-lite and NAT64/
      DNS64 which, in addition, are stateful at the transport layer.)

      In the encapsulating direction, this permits to address all pieces
      of a received datagram to the right IPv6 destination.  In the
      decapsulating direction, this permits to ensure that all pieces of
      received datagram do come from the right CE.


5.  4rd Configuration

   Both CE's and BR's have to know parameters of their 4rd domain.
   These include the BR IPv6 address plus, for each mapping rule, the
   following:



Despres, et al.         Expires September 8, 2011               [Page 9]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


   o  Domain IPv6 prefix

   o  CE-index length
      or CE-IPv6-prefix length (derivable from one another)

   o  Domain IPv6 suffix (optional - default ::/0)

   o  Domain 4rd prefix

   A CE can acquire 4rd parameters of its 4rd domain in various ways.

   o  The simplest one, which requires no protocol, can be used if the
      CE software is provided by the ISP and is downloadable. 4rd
      parameters can be included in update packages.  (This case is
      similar to that which permitted the first 6rd deployment
      [RFC5569].)

   o  Another way is based on DHCPv6 [RFC3315].  As such, it is similar
      to that of 6rd in [RFC5969] where CE parameters are acquired in
      IPv4 DHCP.  How to format these parameters in a DHCPv6 option, or
      for other ways to advertise them to CE's has still to be
      specified.  The design may be influenced by the following facts:
      (1) if the length of the Domain IPv6 prefix is known, the length
      of the CE index or that of the CE IPv6 prefix can be derived from
      one another; (2) if a single mapping rule applies to all CE's,
      each CE can derive the Domain IPv6 prefix from its CE IPv6 prefix
      by just knowing the length of this Domain IPv6 prefix; (3)
      sateless DHCPv6 servers are simpler to manage than stateful.

   o  Other methods of parameter acquisition are for further study.


6.  BR and CE behaviors

   BR's and CE's MAY have the behaviors specified in the following
   sections.  Different behaviors are permitted, but MUST be equivalent
   as far as exchanged packets are concerned.

6.1.  Encapsulation and IPv6 Fragmentations

   For 4rd domain traversal, IPv4 packets are encapsulated in IPv6
   packets whose Next header is set to 4 (i.e.  IPv4).  If fragmentation
   of IPv6 packets is needed (see Section 4.5), it is performed
   according to [RFC2460], as shown in Figure 5.  All IPv6 packets
   except the last one have the same length, namely the IPv6 path MTU of
   the Domain.

   Received encapsulating packets are reassembled before being processed



Despres, et al.         Expires September 8, 2011              [Page 10]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


   according to Section 6.2.4 and Section 6.2.4.



                              +--------------------//---------------+
                              |             IPv4 packet             |
                              +--------------------//---------------+
                              :                                     :
                              :                                     :
                              +-----//----+-----//----+--//--+--//--+
                              |   frag 1  |   frag 2  |      |frag n|
                IPv6          +-----//----+----//-----+--//--+------+
      fragmentation extension :           :           :      :      :
                            \ :           :           :      :      :
                  |0         \|48         :           :      :      :
                  +----------++-----//----+           :      :      :
                  |   IPv6   ||   frag 1  |           :      :      :
                  +----------++-----//----+           :      :      :
                  <---- IPv6 path MTU --->:           :      :      :
                                          :           :      :      :
                              +----------++-----//----+      :      :
                              |   IPv6   ||   frag 1  |      :      :
                              +----------++-----//----+      :      :
                              <---- IPv6 path MTU --->       :      :
                                                       ...   :      :
                                                             :      :
                                                 +----------++--//--+
                                                 |   IPv6   ||frag n|
                                                 +----------++------+



         Figure 5: IPv4 packet fragmentation for Domain traversal

6.2.  Domains having only One Mapping rule

6.2.1.  BR reception of an IPv4 packet

   Step 1  When a BR receives an IPv4 packet at its IPv4 interface, its
           process depends on whether the length of CE 4rd prefix
           exceeds 32 bits.  If not, the BR proceeds to the next step.
           If yes, there are three cases: (1) if the packet is a single-
           packet datagram, the BR proceeds to the next step; (2) if it
           is a fragment of an datagram that is still incomplete, the
           packet is kept for later reassembly of a complete IPv4
           datagram (with a timeout protection as usual for this
           function); (3) if it is the last fragment that was missing to
           assemble a complete datagram, the BR proceeds to the next



Despres, et al.         Expires September 8, 2011              [Page 11]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


           step with the datagram considered as received in a single
           packet.

   Step 2  The BR first checks that no CE IPv6 address can be derived
           per Section 4.4) from the IPv4 source.  If this is the case,
           it derives from the IPv4 destination the IPv6 address of the
           destination CE from per Section 4.4).  The CE then transmits
           the packet via its IPv6 interface, duly fragmented in IPv6 if
           necessary.

6.2.2.  BR reception of an IPv4/IPv6 packet

   Step 1  When a BR receives an IPv6 packet at its IPv6 interface, with
           the BR IPv6 address as destination, its process depends on
           whether the length of CE 4rd prefix exceeds 32 bits.  If not,
           or if the IPv4 packet is a complete datagram, the BR proceeds
           to the next step.  If yes, there are two cases: (1) if the
           packet contains the last fragment that was missing to
           assemble a complete IPv4 datagram, the BR proceeds to the
           next step with the reassembled datagram as if it had been
           received in a single IPv4 packet; (2) otherwise, the packet
           is kept for later reassembly of a complete IPv4 datagram
           (with a timeout protection as usual for this function).

   Step 2  The BR checks that the IPv6 source address of the packet is
           not the BR IPv6 address, and is that which is derived per
           Section 4.4 from the IPv4 destination.  If this is the case,
           the BR transmits the IPv4 packet via its IPv4 interface, duly
           fragmented in IPv4 if necessary for the link MTU.

6.2.3.  CE reception of an IPv4 packet

   Step 1  When a CE receives an IPv4 packet at its IPv4 interface, its
           process depends on whether the length of CE 4rd prefix
           exceeds 32 bits.  If not, the BR proceeds to the next step.
           If yes, there are three cases: (1) if the packet is a
           complete IPv4 datagram, the CE proceeds to the next step; (2)
           if it is a fragment of datagram that is still incomplete, the
           packet is kept for later reassembly with other fragments
           (with a timeout protection as usual for this function); (3)
           if it is the last fragment that was missing to assemble a
           complete datagram, the CE proceeds to the next step with the
           datagram considered as received in a single packet.

   Step 2  The CE tries to derive an IPv6 address from the IPv4
           destination per Section 4.4.  In case of success, this
           address taken as IPv6 destination of the encapsulating
           packet.  Otherwise, it is the BR IPv6 address that is taken.



Despres, et al.         Expires September 8, 2011              [Page 12]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


           The CE then transmits the packet via its IPv6 interface, duly
           fragmented in IPv6 if necessary.

6.2.4.  CE reception of an IPv4/IPv6 packet

   Step 1  When a CE receives an IPv6 packet at its IPv6 interface, with
           the BR IPv6 address as destination, its process depends on
           whether the length of CE 4rd prefix exceeds 32 bits.  If not,
           or if the IPv4 packet is a complete datagram, the BR proceeds
           to the next step.  If yes, there are two cases: (1) if the
           packet contains the last fragment that was missing to
           assemble a complete IPv4 datagram, the CE proceeds to the
           next step with the reassembled datagram as if it had been
           received in a single IPv4 packet; (2) otherwise, the packet
           is kept for later reassembly of a complete IPv4 datagram
           (with a timeout protection as usual for this function).

   Step 2  The CE tries to derive an IPv6 address from the IPv4 source
           per Section 4.4.  If this succeeds, it checks that the
           obtained address is the same as the IPv6 source address.
           Otherwise, it checks that the IPv6 source address is the BR
           IPv6 address.  In case of success, the CE transmits the IPv4
           packet via its IPv4 interface, duly fragmented in IPv4 if
           necessary for the link MTU.

6.3.  Domains having Multiple Mapping Rules (TBD)


7.  Security considerations

   Spoofing attacks

      With consistency checks between IPv4 and IPv6 sources that are
      performed on IPv4/IPv6 packets received by BR's and CE's
      (Section 6), 4rd does not introduce any opportunity for spoofing
      attack that would not pre-exist in IPv6.

   Denial-of-service attacks

      In 4rd domains where IPv4 addresses are shared, the fact that IPv4
      datagram reassembly may be necessary introduces an opportunity for
      DOS attacks (see Section 4.5).  This is inherent to address
      sharing, and is common with other address sharing approaches such
      as DS-lite and NAT64/DNS64.







Despres, et al.         Expires September 8, 2011              [Page 13]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


      The best protection against such attacks is to accelerate IPv6
      enablement in both clients and servers so that, where 4rd is
      supported, it is less and less used.

   Routing-loop attacks

      Routing-loop attacks that may exist in some automatic-tunneling
      scenarios are documented in [I-D.ietf-v6ops-tunnel-loops].  They
      cannot exist with 4rd because each BRs checks that the IPv6 source
      address of an IPv4/IPv6 packet it receives is not the 4rd-relay
      IPv6 address (Section 6.2.2).


8.  IANA Considerations

   IANA is requested to assign a DHCPv6 option number for 4rd
   (Section 5).


9.  Acknowledgments

   The authors wish to thank Mark Townsley for his active encouragements
   to pursue the 4rd approach since it was first introduced in
   [I-D.despres-softwire-sam].  Olivier Vautrin, who independently
   proposed a similar approach with the same acronym deserves special
   recognition.  Particular gratitude is due to decision makers of the
   Japan ISP's that have announced actual 4rd deployment projects (see
   Section 1).


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

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





Despres, et al.         Expires September 8, 2011              [Page 14]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


10.2.  Informative References

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

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

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

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work
              in progress), March 2011.

   [I-D.ietf-v6ops-tunnel-loops]
              Nakibly, G. and F. Templin, "Routing Loop Attack using
              IPv6 Automatic Tunnels: Problem Statement and Proposed
              Mitigations", draft-ietf-v6ops-tunnel-loops-03 (work in
              progress), February 2011.

   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd)", RFC 5569, January 2010.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.











Despres, et al.         Expires September 8, 2011              [Page 15]


Internet-Draft        IPv4 Residual Deployment(4rd)           March 2011


Authors' Addresses

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

   Email: remi.despres@free.fr


   Satoru Matsushima
   SoftBank
   1-9-1 Higashi-Shinbashi, Munato-ku
   Tokyo
   Japan

   Email: satoru.matsushima@tm.softbank.co.jp


   Tetsuya Murakami
   IP Infusion
   1188 East Arques Avenue
   Sunnyvale
   USA

   Email: tetsuya@ipinfusion.com


   Ole Troan
   Cisco
   Bergen, Norway
   France

   Email: ot@cisco.com
















Despres, et al.         Expires September 8, 2011              [Page 16]