Internet Engineering Task Force                               R. Despres
Internet-Draft                                                 RD-IPtech
Intended status: Informational                         December 29, 2011
Expires: July 1, 2012


 IPv4 Residual Deployment via IPv6 - Unified Stateless Solution (4rd-U)
                    draft-despres-softwire-4rd-u-02

Abstract

   This document specifies an automatic tunneling mechanism tailored for
   residual deployment of public IPv4 via IPv6 networks (the reverse of
   6rd whose purpose is rapid deployment of IPv6 via IPv4).  In order to
   deal with the IPv4-address shortage, customers can be assigned shared
   IPv4 addresses with statically assigned restricted port sets.
   Operation is stateless, with no per-customer state in network nodes.

   4rd-U unifies in a synthesis features of double-translation-based
   solutions (in particular compatibility with some IPv6-only middle-box
   tools inside IPv6 networks), and those of IP-in-IP encapsulation
   solutions (in particular complete end-to-end transparency to IPv4
   packets).  It is proposed as a unified standard replacing the two
   standards that are otherwise envisaged.

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 July 1, 2012.

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



Despres                   Expires July 1, 2012                  [Page 1]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   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.  The 4rd-U Model  . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Protocol Specification . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Reversible Header Mapping from IPv4 to IPv6  . . . . . . .  6
     5.2.  Mappings Rules . . . . . . . . . . . . . . . . . . . . . . 10
     5.3.  Mappings from IPv6 prefix to Residual-IPv4 prefix  . . . . 10
     5.4.  Mapping from Residual-IPv4 address to IPv6 address . . . . 12
       5.4.1.  From Residual-IPv4 address to IPv6 prefix  . . . . . . 12
       5.4.2.  From IPv6 prefix to IPv6 address . . . . . . . . . . . 14
     5.5.  Fragmentation Considerations . . . . . . . . . . . . . . . 16
       5.5.1.  Ports of Fragments sent to Shared-Address CEs  . . . . 17
       5.5.2.  Datagram-Identification Updates in BRs . . . . . . . . 17
     5.6.  Translating Tunnel-Generated ICMPv6 into ICMPv4  . . . . . 17
     5.7.  Provisioning 4rd-U parameters to CEs . . . . . . . . . . . 18
     5.8.  BR and CE Behaviors  . . . . . . . . . . . . . . . . . . . 19
   6.  Use-Case Examples  . . . . . . . . . . . . . . . . . . . . . . 25
     6.1.  Moving from IPv4-only to IPv6 and Residual IPv4  . . . . . 25
     6.2.  Residual-IPv4 Service via a Third-Party IPv6 Network . . . 27
     6.3.  Adding Residual IPv4 to an IPv6-only network . . . . . . . 28
     6.4.  IPv6 and Residual-IPv4 added to a net-10 network . . . . . 29
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   9.  Contributors and Acknowledgements  . . . . . . . . . . . . . . 31
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 31
     10.2. Informative References . . . . . . . . . . . . . . . . . . 31
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34










Despres                   Expires July 1, 2012                  [Page 2]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


1.  Introduction

   This specification addresses the need for a stateless solution
   permitting deployments of residual IPv4 service via IPv6 networks
   (ref.  [I-D.ietf-softwire-stateless-4v6-motivation]).  The solution,
   4rd-U, is stateless in that no per-customer state is needed in
   network nodes.  It does it with an approach reversed from that of 6rd
   [RFC5969], i.e. with IPv4 tunneled via IPv6 instead of IPv6 tunneled
   via IPv4.

   In order to deal with the IPv4-address shortage, customers can be
   assigned shared IPv4 addresses with statically assigned restricted
   port sets.

   The design of 4rd-U builds on previous proposals made for IPv4-via-
   IPv6 transition technologies, in particular for encapsulation
   approaches ([I-D.despres-sam][I-D.murakami-softwire-4rd]), for double
   translation approaches ([RFC6219] [I-D.xli-behave-divi]
   [I-D.murakami-softwire-4v6-translation] [I-D.xli-behave-divi-pd]),
   and for attempts at unifying address mappings of the two
   ([I-D.mdt-softwire-mapping-address-and-port]
   [I-D.despres-softwire-4rd-addmapping]).  It can be viewed as a
   synthesis that is neither double translation (IP payloads are kept
   unchanged at tunnel entry and exit), nor encapsulation (there is no
   IPv4 header between the IPv6 header and the IP payload), but has
   positive features of both.

   Implementations may differ depending on whether they start from
   developments previously made for double translation or for
   encapsulation, or start from neither, but interworking does not
   depend on it.  ISPs that provide their own CPEs know may implement
   significantly simplified versions of 4rd-U, taking advantage that
   they know which 4rd-U parameters apply to their networks.

   Terminology is defined in Section 3.  How the 4rd-U model fits in the
   Internet architecture is summarized in Section 4.  The protocol
   specification is detailed in Section 5.  Section 6 illustrates a few
   typical 4rd-U use cases.  Section 7 and Section 8 respectively deal
   with security and IANA considerations.


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                   Expires July 1, 2012                  [Page 3]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


3.  Terminology

   Residual IPv4:  A extension of the IPv4 service where public-IPv4
        addresses can be statically shared between some customers.

   Residual-IPv4 prefix:  A prefix that may be an IPv4 prefix, an IPv4
        address or an IPv4 address followed the identifier of a
        restricted port set.

   Residual-IPv4 address:  A non-shared IPv4 address or a shared IPv4
        address plus a transport-layer port.

   Port-set Identifier (PSID):  A flexible-length number that
        algorithmically identifies a set of ports.

   ISP: Internet-Service Provider.  In this document, the offered
        service can be DSL, fiber-optics, cable, or mobile.  The ISP can
        also be a private-network operator.

   4rd-U domain:  An ISP-operated IPv6 network in which Residual-IPv4
        service is offered according to the present specification.

   Border Relay (BR):  A 4rd-U-capable node at the border between a
        4rd-U domain and the IPv4 Internet.  Because its operation is
        stateless, it can, for scalability, be replicated in as many
        instances as needed.

   Customer Edge node (CE):  A 4rd-U-capable customer node attached to a
        4rd-U domain.  It can be a host, a router, or both.  For
        Residual IPv4, it includes a NAT44 which maps internal ports
        used within the CE site into external ports (ref.  [RFC1631]).
        These ports may belong to a restricted port set.

   IPv4-mapped IPv6 packet:  An IPv6 packet used to transparently tunnel
        an IPv4 packet across a 4rd-U domain.  Its payload is the
        original IPv4 payload.  Its addresses are IPv4-mapped IPv6
        addresses.

   Mapping rule:  A set of parameters used by BRs and CEs to derive
        destinations of IPv4-mapped IPv6 packets from IPv4 destinations
        and port fields of tunneled IPv4 packets, and used by CEs to
        derive their Residual-IPv4 prefixes from their IPv6 prefixes.

   Embedded Address bits (EA bits):  Bits that are common to a Residual-
        IPv4 address and the IPv6 address derived from it.






Despres                   Expires July 1, 2012                  [Page 4]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


4.  The 4rd-U Model

   How the 4rd-U model fits in the Internet architecture is represented
   in Figure 1.



                                                     Border-relay(s)
                                                (No per-connexion state)
                                                 (No per customer state)
                                                           |
                                    4rd-U DOMAIN           |
                          - IPv6 routing (native or 6rd)   v
                          - Enforced ingress filtering
                          +-------------------------------+
                          |                               | +----------
                          |                               | |
                     ...  |                               | |
                          |                             +----+  IPv4
       Customer site      |                             | BR | Internet
   +--------------------+ |                             +----+
   |CE Residual-IPv4    | |                               | |
   |    prefix     +----+ |                               | |
   | statelessly   | CE +-+ <-- IPv6 prefix               | +----------
   | derived from  +----+ |                               |
   | the CE IPv6 prefix | |                               +------------
   +--------------------+ |                               |
                          |- CE-CE IPv4 tunnels           |
                     ...  |  follow CE-CE IPv6 routes     |   IPv6
                          |  (mesh or hub-and-spoke)      |  Internet
                          |- Some middle-boxes can treat  |
                          |  tunneled IPv4 packets        |
                          |  as native IPv6 packets       +------------
                          +-------------------------------+
                          <== Mapping rules announced to CEs
                              (e.g. in stateless DHCPv6)

                              The 4rd-U Model

                                 Figure 1











Despres                   Expires July 1, 2012                  [Page 5]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


5.  Protocol Specification

5.1.  Reversible Header Mapping from IPv4 to IPv6

   At domain entry, IPv4 headers that have no IPv4 option are reversibly
   mapped into IPv6 headers as shown in Figure 2.  Those that have
   options are discarded with the ICMPv4 error message specified for
   this in [RFC0792] returned to their sources (Type = 12, Code = 0,
   Pointer = 20).  At domain exit, IPv6 headers are mapped back to
   original IPv4 headers.  Source and destination addresses of IPv6
   headers are derived from Residual-IPv4 addresses contained in IPv4
   packets as specified in Section 5.4.

                               Reversible
         IPv4 packet            mapping        IPv6-mapped IPv4 packet
     +--------------------+ _                _ +--------------------+
     |     IPv4 Header    | _|    =(1)=>    |  |    IPv6 Header     |
     +--------------------+       <=(2)=    |  +--------------------+
     |      IP Payload    |                 |_ |IPv6 Fragment Header|
     +--------------------+                    +--------------------+
                                               |      IP Payload    |
                                               +--------------------+

                                 Figure 2

   For full transparency to the DF bit of IPv4 (the bit which forbids
   fragmentation within the network if set to 1), a specific technique
   is needed because there is no DF bit in IPv6 (fragmentation within
   the network is always forbidden).  For this, an IPv6 Fragment header
   is systematically present after the IPv6 header, and IPv4 DF bit is
   copied in one of the 16 unused bits of its Identification field
   contained in this header.  These unused bits exist because the
   Identification field used for reassembly of fragmented datagrams has
   32 bits in IPv6, while it has 16 bits in IPv4.

   In order to support the two variants of the explicit-congestion-
   notification mechanism specified in [RFC6040] for tunnels, the IPv4
   DSCP and IPv4 ECN are also copied in eight other unused bits of the
   IPv6 Identification field of the Fragment header.

   Other than that, the logic of the IPv4 to IPv6 reversible header
   mapping is straightforward.  It is detailed in Table 1, with field
   names and locations of Figure 3.  The reverse header mapping from
   IPv6 to IPv4 is detailed in Table 1.







Despres                   Expires July 1, 2012                  [Page 6]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Vers=4 |HeadL=5|    DSCP   |ECN|      Total Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    IPv4 Identification        |0|D|M|  IPv4 Fragment Offset   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time to Live |    Protocol   |        Header Checksum        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      /\
                                      ||
                                      \/
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Vers=6 |    DSCP   |ECN|            Flow Label = 0              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Payload Length        |Next Header=44 |   Hop Limit   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Source Address                          +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                     Destination Address                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |2nd Next Header|  Reserved = 0   | IPv6  Fragment Offset | 0 |M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D| Reserved = 0|  IPv4 DSCP  | . |    IPv4 Identification      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   IPv4 ECN

           IP Fields used in the 4rd-U Reversible Header Mapping

                                 Figure 3





Despres                   Expires July 1, 2012                  [Page 7]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   +--------+-------------------+--------------------------------------+
   |        | IPv6 field name   | Value (with reference to IPv4 field  |
   |        |                   | names)                               |
   +--------+-------------------+--------------------------------------+
   | 1      | DSCP              | DSCP or ISP parameter                |
   | ------ | ----------------- | ------------------------------------ |
   | 2      | ECN               | ECN or 0 per [RFC6040] (NOTE 1)      |
   | ------ | ----------------- | ------------------------------------ |
   | 3      | Payload length    | Total_ Length - 20                   |
   | ------ | ----------------- | ------------------------------------ |
   | 4      | Hop limit         | Time_to_live                         |
   | ------ | ----------------- | ------------------------------------ |
   | 5      | Source address    | AddMapping4to6(Source address)       |
   | ------ | ----------------- | ------------------------------------ |
   | 6      | Dest. address     | AddMapping4to6(Destination address)  |
   | ------ | ----------------- | ------------------------------------ |
   | 7      | 2nd Next header   | Protocol                             |
   | ------ | ----------------- | ------------------------------------ |
   | 8      | Frag. offset      | Frag. offset                         |
   | ------ | ----------------- | ------------------------------------ |
   | 9      | M                 | MF                                   |
   | ------ | ----------------- | ------------------------------------ |
   | 10     | D                 | DF                                   |
   | ------ | ----------------- | ------------------------------------ |
   | 11     | IPv4 DSCP         | DSCP or 4rd-U-domain parameter       |
   | ------ | ----------------- | ------------------------------------ |
   | 12     | IPv4 ECN          | ECN                                  |
   | ------ | ----------------- | ------------------------------------ |
   | 13     | IPv4              | Identification                       |
   |        | Identification    |                                      |
   +--------+-------------------+--------------------------------------+

                 Table 1: Header Mapping from IPv4 to IPv6

   NOTE 1:   [RFC6040] specifies how to process ECNs of IP-in-IP tunnels
        at their entry and exit endpoints.  Whatever applies to "outer-
        header ECN" and "inner-header ECN" in this RFC applies here to
        "ECN" and "IPv4 ECN" of IPv4-mapped IPv6 packets.













Despres                   Expires July 1, 2012                  [Page 8]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   NOTE 2: Compared to IP-in-IP tunneling of [RFC2473]), 4rd-U has the
   advantage that tunneled packets look like native IPv6 packets, at
   least as far as their UDP/TCP port fields are concerned.  Thus, IPv6
   middle-boxes that check port numbers for access-control have their
   applicability extended to tunneled IPv4 packets.  With the additional
   precaution of Section 5.4 that IPv6-converted headers have the same
   contribution to TCP checksums as IPv4 addresses from which they are
   derived, tunneled TCP/IPv4 packets are also valid as TCP/IPv6
   packets.  Applicability of IPv6 web caches is thus extended to
   tunneled IPv4 packets.  This is how 4rd-U achieves both the end-to-
   end transparency of IP-in-IP encapsulation solutions and the
   compatibility with some IPv6-only middle boxes of double-translation
   solutions.

   +--------+-------------------+--------------------------------------+
   |        | IPv4 field name   | Value (with reference to IPv6 field  |
   |        |                   | names)                               |
   +--------+-------------------+--------------------------------------+
   | 1      | DSCP              | IPv4 DSCP                            |
   | ------ | ----------------- | ------------------------------------ |
   | 3      | ECN               | Per [RFC6040] (NOTE 1)               |
   | ------ | ----------------- | ------------------------------------ |
   | 4      | Total Length      | Payload length + 20                  |
   | ------ | ----------------- | ------------------------------------ |
   | 5      | Identification    | Bits_16-31(Identification)           |
   | ------ | ----------------- | ------------------------------------ |
   | 6      | Reserved (1 bit)  | 0                                    |
   | ------ | ----------------- | ------------------------------------ |
   | 7      | DF flag           | Bit_0(Identification)                |
   | ------ | ----------------- | ------------------------------------ |
   | 8      | MF flag           | M                                    |
   | ------ | ----------------- | ------------------------------------ |
   | 9      | Frag. offset      | Fragment offset                      |
   | ------ | ----------------- | ------------------------------------ |
   | 10     | Time to live      | Hop limit                            |
   | ------ | ----------------- | ------------------------------------ |
   | 11     | Protocol          | Next_header(Fragment header)         |
   | ------ | ----------------- | ------------------------------------ |
   | 12     | Header checksum   | 1's complement of the 9 other 16-bit |
   |        |                   | words of the IPv4 header             |
   | ------ | ----------------- | ------------------------------------ |
   | 13     | Source address    | AddMapping6to4(Source address)       |
   | ------ | ----------------- | ------------------------------------ |
   | 14     | Dest. address     | AddMapping6to4(Destination address)  |
   +--------+-------------------+--------------------------------------+

                 Table 2: Header Mapping from IPv6 to IPv4




Despres                   Expires July 1, 2012                  [Page 9]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


5.2.  Mappings Rules

   A 4rd-U domain has one or several Mapping rules, each one having the
   following parameters:

   o  Rule IPv4 prefix

   o  Rule IPv6 prefix

   o  EA-bits length

   o  Rule IPv6 suffix (optional, default ::/0)

   BRs of a 4rd-U domain are administratively configured with Mapping
   rules of the domain.  CEs are informed of Mapping rules by some
   automatic tool (see Section 5.7).

   The first three parameters determine how Residual-IPv4 addresses are
   mapped into IPv6 addresses, as detailed in Section 5.4.  They are
   also used, in the reverse direction, by each CE to derive its
   Residual-IPv4 prefix from its delegated IPv6 prefix, as detailed in
   Section 5.3.

   Rule IPv6 suffixes are only used in particular cases where CEs are
   placed behind third-party CPEs, and where these CPEs use some address
   bits to route packets among their physical ports (see Section 6.2).
   Where applicable, these suffixes are appended to customer-site IPv6
   prefixes to obtain CE-delegated IPv6 prefixes, as detailed in
   Section 5.3.

   For IPv4 packets that go from CEs to the IPv4 Internet to always have
   an IPv6 address derived fro their IPv4 destinations, one Mapping rule
   MUST apply to IPv4 address whose first bits are arbitrary.  This rule
   is characterized by a Rule IPv4 prefix equal to 0.0.0.0/0.  It MUST
   be unique.

5.3.  Mappings from IPv6 prefix to Residual-IPv4 prefix

   How each CE derives its Residual-IPv4 prefix from its delegated IPv6
   prefix is detailed in Figure 4.  The first step consists in finding
   the Mapping rule whose IPv6 prefix has the the longest match with the
   CE delegated prefix.









Despres                   Expires July 1, 2012                 [Page 10]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


       +--------------------------------------------+
       |           CE delegated IPv6 prefix         |
       +--------------------------+-----------+-----+
       :     Longest match        :           :<-.->:
       :           ||             :           :   \
       :           \/             :           :  Length of the
       +--------------------------+           : Rule IPv6 suffix
       |    Rule IPv6 prefix      |           :
       +--------------------------+           :
         Rule-based substitution  :           :
                       ||         :           :
                       \/         :           :
                +-----------------+-----------+
                |Rule IPv4 prefix |  EA bits  |
                +-----------------+-----------+
               / \                 \         / \
              /   \                 \       /   \
             /     \                 \     /     \
            /       \                 \   /       \
           /         \                 \ /         \
          /           \                 /           \
         /             \               / \           \
        /               \             /   \           \
       /                 \           /     :           \
      /                   \         /      :            \
     :                     \       /       :             \
     :       SHORT CASE     \     /     LONG CASE         \
     :                       \   /         :               \
     :                        \ /          +---------+------+
     :                         /           |         |      |
     :                        / \          +---------+------+
     :                       /   \         :         :\ PSID \
     :                      /     :        :         : :length\
     :                     /      :        :         : :  ||   \
     :                    :       :        :         :4:  \/   :
     +--------------------+--+    +--------+---------+-+-------+---+
     |      IPv4 address     | OR |   IPv4 address   |   Port set  |
     +--------------------+|-+    +--------+---------+|+-------+-|-+
     :          32         | :    :       32         :|    16    | :
                           |                          |          |
                     any value                        > 0    any value

      Mapping between IPv6 prefix and set of Residual-IPv4 addresses

                                 Figure 4






Despres                   Expires July 1, 2012                 [Page 11]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   Whether the resulting Residual-IPv4 prefix defines a set of exclusive
   IPv4 addresses (the SHORT CASE) or a shared IPv4 address with a set
   of exclusive ports (the LONG CASE), depends on the length of this
   prefix.  Once the Mapping rule that has the longest match is found,
   this length is determined (it is the sum of the Rule-IPv4-prefix
   length and the EA-bits length).  The LONG CASE applies if this length
   exceeds 32 bits, the SHORT CASE otherwise.

   In the LONG CASE, the restricted port set assigned to each CE is
   specified by the PSID as shown on the Figure 4.  The NAT44 of the CE
   MUST only use ports that belong to this set.

   NOTE: The choice of the PSID position in Port fields has been guided
   by the following objectives: (1) for fairness, have the first 1024
   ports (the well-known ports) excluded from port sets defined by all
   PSID value; (2) have in each each port set the two consecutive ports
   that are required for RTP/RTCP [RFC4961] (for this, PSID length MUST
   be limited to 11); (3) in order to facilitate operation and training,
   have the PSID at a fixed position in port fields; (4) in order to
   facilitate documentation in hexadecimal notation and to facilitate
   maintenance, have this position nibble aligned.  With the first 4
   bits of ports required not to be 0, the first 4096 ports are all
   excluded instead of just the first 1024; this is a trade-off due to
   other objectives, in particular nibble alignment.

5.4.  Mapping from Residual-IPv4 address to IPv6 address

   CEs and BRs derive IPv6 destinations of tunneled IPv4 packets in two
   steps: (1) derivation of the IPv6 prefix from the Residual-IPv4
   address found in the IPv4 packet, as detailed in Section 5.4.1; (2)
   derive from this prefix an IPv6 address, as detailed in
   Section 5.4.2.

5.4.1.  From Residual-IPv4 address to IPv6 prefix

   The first action consists in finding the Mapping rule whose IPv4
   prefix has the the longest match with the IPv4 address.  Next
   actions, detailed in Figure 5, depend on the Rule-IPv4-prefix length
   plus the EA-bits length.  If this sum exceeds 32, the LONG CASE
   applies, the SHORT CASE otherwise.











Despres                   Expires July 1, 2012                 [Page 12]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


        +-------------------------------------------+
        |                 IPv6 prefix               |
        +-------------------------------------------+
        :                                           :
        +--------------------------+-----------+----+
        |    Rule IPv6 prefix      |  EA bits  |    |
        +--------------------------+-----------+----+
                        /\         :           :  /\
                        ||         :           :  ||
           Rule-based substitution :           :  Rule
                 +-----------------+-----------+  IPv6
                 | Rule IPv4 prefix|  EA bits  | suffix
                 +-----------------+-----------+
                / \               / \         / \
               /   \             /   \       /   \
              /     \           /     \     /     \
             /       \         /       \   /       \
            /         \       /         \ /         \
           /           \     /           /           \
          /             \   /           / \           \
         /               \ /           /   :           \
        /                 \           /    :            \
       /                 / \         /     :             \
      :                 /   \       /      :              \
      :       SHORT CASE     \     /    LONG CASE          \
      :               /       \   /        :                \
      :              /         \ /         +----------+------+
      :             :           /          |IPv4 infix| PSID |
      :             :          / \         +----------+------+
      :             :   /\    /   \   /\   :          :\  /\  \
      :     /\      :   ||   /     :  ||   :          : : ||   \
      :     ||      :EA-bits/      :longest:          : : PSID  \
      :longest match:length:       :  match:          :4:length  :
      +-------------+------+--+    +-------+----------+-+--------+---+
      |      IPv4 address     | OR |    IPv4 address  |  Port field  |
      +-------------+------+--+    +-------+----------+-+--------+---+
      :          32           :    :       32         :     16       :


          Mapping between Residual-IPv4 address and IPv6 address

                                 Figure 5









Despres                   Expires July 1, 2012                 [Page 13]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   In the LONG CASE, the Port field is found in the IPv4-packet payload
   as follows:

   o  If the packet Protocol is not ICMP, the Port field is where UDP/
      TCP have their port numbers (bits 0-15 for an IPv4 source address;
      bits 16-31 for a destination address).

   o  If the packet is an ICMPv4 error message, the Port field is where
      TCP has its port number in the returned part of the erroneous
      packet, with due reversal of source and destination (bits 240-255
      for a source address; bits 224-239 for a destination address).

   o  If the packet is an ICMPv4 echo or echo-reply message, the Port
      field is the ICMPv4 Identification field (bits 32-47).

   NOTE: For CEs to be able to send Echo-requests across the IPv4
   Internet ICMP Identifier fields are used as substitute to transport-
   layer port fields.  CEs can thus send Echo requests to any remote
   host that has exclusive IPv4 addresses, and receive its response,
   both if the host is accessible via the IPv4 Internet or if it is in
   the 4rd-U domain itself.  This does not permit however to exchange
   Echo requests between two hosts having each one a shared address.
   (This limitation is due to address sharing, not to 4rd-U in
   particular.  Dynamic address sharing schemes such as NAT64 of
   [RFC6146] have it too.)

5.4.2.  From IPv6 prefix to IPv6 address

   Derivation from IPv6 prefix to IPv6 address has two variants which
   depend on the IPv6-prefix length (see Figure 6):

   o  If the IPv6 prefix is /64 or shorter, variant (A) is used.

   o  If the IPv6 prefix is a /80, variant (B) is used.  In this case,
      the Rule is necessarily that that which applies to off-domain IPv4
      addresses).















Despres                   Expires July 1, 2012                 [Page 14]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


    (A):<-- IPv6 prefix =< /64  -->:
       :                           :   : 8 : 8 :       32      :   16  :
       +---------------------------+---+---+---+---------------+-------+
       |       CE or BR prefix     | 0 | V | 0 |  IPv4 address |  CNP  |
       +---------------------------+-|-+---+-|-+---------------+--|----+
       :                        Padding:   : Reserved        Checksum- :
       :                               :   :                neutrality :
       :<-- 4rd-U-specific prefix in CE -->:                 preserver :
                                       :                               :
                                       :<----- Interface-ID field ---->:


    (B):<------------------ IPv6 prefix /112 ----------------->:
       :<------- Rule IPv6  prefix /80 ------->:<-- EA bits -->:
       :                                       :               :
       :                64             : 8 : 8 :       32      :   16  :
       +-------------------------------+---+---+---------------+-------+
       |             BR prefix         | V | 0 |  IPv4 address |  CNP  |
       +-------------------------------+---+---+---------------+-------+
       :                               :                       :       :
       :<-- 4rd-U specific prefix in BR -->:                   :       :
       :<----------- 4rd-U specific prefix in CE  ------------>:       :
                                       :                       :       :
                                       :<----- Interface-ID field ---->:


                 Mapping from IPv6 prefix to IPv6 Address

                                 Figure 6


   THE V OCTET

   A design objective is that CE or BR IPv6 prefixes that are used for
   IPv4 tunneling can be those that are delegated have for native IPv6,
   without any constraint native-IPv6 addresses.  For this, IPv4-mapped
   IPv6 addresses are made distinguishable from any valid native IPv6
   address.  (This can also facilitates maintenance of 4rd-U domains, by
   making IPv4 tunneled packets recognizable without knowledge of
   mapping rules, which this is a bonus side effect.)

   Technically, this is achieved with a 4rd-U specific mark (V) in the
   first octet of Interface-ID fields.  Its "u" and "g" bits of
   [RFC4291] have to be both set to 1 to differ from their values in
   native IPv6 unicast addresses.  The proposed value of other bits of
   this octet is 0, giving V = 3 (a value to be endorsed by IANA).





Despres                   Expires July 1, 2012                 [Page 15]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   NOTE 1: Both "u" and "g" = 1 is an escape value from native IPv6
   addresses because [RFC4291] specifies that: (1) "u" = 0 is reserved
   for local-scope Interface IDs; (2) "u" = 1 is reserved for addresses
   that conform to the modified EUI-64 format.  These addresses always
   have "g"=0 because they are unicast while this bit set to 1 would
   mean "group" address.  Using this escape value amounts to a backward
   compatible update of [RFC2460].  If approved in Softwire, it should
   therefore to be submitted to the 6man working group for endorsement.

   NOTE 2: The name V is chosen to evoke its being different the u octet
   of IPv4-embedded IPv6 addresses specified for NAT64s in [RFC6146].
   These IPv4-embedded addresses also contain IPv4 addresses but do not
   meet the above-mentioned design objective: their Interface IDs are
   not distinguishable from those of valid private-scope IPv6 addresses.

   CHECKSUM NEUTRALITY

   In order to ensure that IPv4 payloads are also valid as IPv6 payloads
   for transport-layer protocols that have TCP-like checksums (TCP, UDP,
   DCCP, possibly some others in the future), IPv4-mapped IPv6 addresses
   MUST have the same contribution to these checksums as their contained
   IPv4 addresses.  For this, a 16-bit Checksum-neutrality-preserver
   field (CNP) is placed in the end of these IPv6 addresses.  With IPv4
   addresses themselves copied in address bits 72-103, i.e. at 16-bit
   word boundaries, the CNP value needs only to be the opposite of the
   checksum of other address bits.

5.5.  Fragmentation Considerations

   Absent more specific information, the path MTU of a 4rd Domain SHOULD
   be set to 1280 (the value all IPv6 networks MUST support according to
   [RFC2460]).  ISPs that know that a larger PMTU applies everywhere in
   4rd-U domain SHOULD announce it to CEs to achieve better performance.

   If an IPv4 packet enters a CE or BR with a size that exceeds the
   Domain PMTU minus 28, the size of the IPv4-mapped IPv6 packet derived
   from it would exceed the PMTU.  If the packet has DF=1, it MUST be
   discarded, with an ICMP error message returned to the source.
   Otherwise, fragmentation is necessary.  It is part of BR and CE
   behaviors specified in Section 5.8.

   Combining fragmentation processing with shared-address processing
   imposes two specific precautions, as detailed below.  (Note: this is
   due to stateless address sharing, independently from whether the
   technology used for IPv6-network traversal is 4rd-U, or
   encapsulation-based, or double-translation based).





Despres                   Expires July 1, 2012                 [Page 16]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


5.5.1.  Ports of Fragments sent to Shared-Address CEs

   Because ports are available only in first fragments of fragmented
   datagrams, a BR or CE needs a mechanism to send all fragments of a
   fragmented datagrams to the right shared-address CEs.

   This can be done by systematically reassembling fragmented IPv4
   datagrams destined to shared-address CEs before tunneling them.
   However, for less memory space consumption, for less sensitivity to
   denial of service attacks, and for less forwarding delays, all
   fragments SHOULD preferably be forwarded on the fly.

   For this, the BR or CE SHOULD note which destination port applies to
   which partially transmitted datagram, and use this information to
   address all fragments to the right CE.  BR and CE behaviors of
   Section 5.8 include this function.  (Note: this need is due to
   stateless address sharing, independently from whether the technology
   used for IPv6-network traversal is 4rd-U or another).

5.5.2.  Datagram-Identification Updates in BRs

   When a BR forwards IPv4 packets that come from two CEs sharing the
   same IPv4 address, and that go to the same destination, it has to
   guarantee that their Identifications have different values.
   Otherwise, the reassembly process, which is based on source address,
   destination address, and Identification, can be confused in the
   destination.  (Note: this also is due to stateless address sharing,
   independently from whether the technology used for IPv6-network
   traversal is 4rd-U, or encapsulation-based, or double-translation
   based).

   This need applies even to forwarded IPv4 packets that are not
   fragmented because they may be fragmented farther on their way to
   their destinations.

   Section 5.8 describes a particular way to do it.

5.6.  Translating Tunnel-Generated ICMPv6 into ICMPv4

   If an IPv4-mapped IPv6 packet is discarded on its way across a 4rd-U
   domain, an ICMPv6 error message is returned to the IPv6 source, i.e.
   to the BR anycast address or to a CE address.  For the source of the
   IPv4 packet to be informed, an ICMPv4 packet MUST be sent to it.

   Type, or Type and Code, of the ICMPv4 packet MUST be for this
   translated from those the ICMPv6 message, and the ICMP checksum MUST
   be updated, according to what is specified for error messages in
   Section 5.2 of [RFC6145].



Despres                   Expires July 1, 2012                 [Page 17]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   A source IPv4 address is needed for such ICMPv4 packets.  The
   proposed value is 192.70.192.254.  (It is taken in the /24 range
   proposed in [I-D.xli-behave-icmp-address] for a similar purpose).

5.7.  Provisioning 4rd-U parameters to CEs

   CEs MUST be configured with Mapping rules of their domain (ref.
   Section 5.2).  In addition they SHOULD be configurable with the
   following optional parameters:

   1.  Domain path MTU (16 bits, default = 1280)

   2.  ECN compatibility mode (1 bit, default = No) - ref.  Section 5.1

   3.  Tunnel DSCP (6 bits, default N/A)

   In order to guarantee that all independently provisioned CEs can work
   on all 4rd-U domain, the a number of Mapping rules every CEs must
   support has to be standardized.  The proposed value is 32, a tradeoff
   between flexibility, maximum processing times, and volume of
   parameters to be provisioned to CEs.  (Editor's note: this number is
   neither critical nor easy to change, a working-group consensus for
   another value wouldn't be a problem.)


         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       OPTION_4RD_RULE         |         option-length         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  prefix4-len  |  prefix6-len  |    ea-len     |  suffix-len   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       rule-ipv4-prefix                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                           ipv6-prefix                         +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         rule-ipv6-suffix      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      DHCPv6 format for Mapping rules

                                 Figure 7

   This document describes how to configure the necessary parameters
   with DHCPv6 options.



Despres                   Expires July 1, 2012                 [Page 18]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   CEs may also be configured in a variety of other manners, including
   provisioning methods such as the Broadband Forum's "TR-69" [TR069]
   Residential Gateway management interface, an XML-based object
   retrieved after IPv4 connectivity is established, a DNS record, an
   SMIv2 MIB [RFC2578], PPP IPCP, or manual configuration by an
   administrator.  For consistency and convenience of implementation on
   CEs that support multiple configuration methods, these other
   configuration and management methods may use formats chose for
   DHCPv6.

   The proposed format for Mapping-rule parameters is presented in
   Figure 7.

   If the prefix6-len is less than 64, the provided ip-v6-prefix is
   taken as Rule IPv6 prefix.  If this length is 64, the Rule IPv6
   prefix has format B in Figure 6, i.e. is a /80.  It is built by
   appending to the provided ip-v6-prefix a V octet and a null octet.
   In this case, the rule IPv4 prefix is 0.0.0.0/0, and EA-bits length
   is 32.  If provided values are different, they SHOULD be ignored.

   The proposed format for other parameters is presented in Figure 8.


         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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        OPTION_4RD_PARAM       |         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            path-mtu           |C| reserved = 0|  tunnel-dscp  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+|+-+-+-+-+
                                    |                     |
                Compatibility mode of RFC6040    (= -1 if non applicable)
                      (= 1 if applicable)

                 DHCPv6 format for 4rd-U-domain parameters

                                 Figure 8

5.8.  BR and CE Behaviors

   BRs and CEs MUST have the behaviors that, as far as CE-BR and CE-CE
   protocols are concerned, are equivalent to what follows.









Despres                   Expires July 1, 2012                 [Page 19]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   BR INITIALIZATION

   When a BR is configured with 4rd-U parameters, it MUST note, for
   anti-spoofing and anti-routing-loop protection, the set of its
   incoming IPv4 prefixes from the Internet.  Also, it SHOULD compute
   the first 80 bits and the CNP part of its IPv4-mapped IPv6 addresses
   to avoid doing it repeatedly.

   If at least one Mapping rule concerns CE shared IPV4 addresses, i.e.
   if the sum of its Rule-IPv4-prefix length and EA-bits length exceeds
   32, the BR MUST initialize an "IPv6-ID table" and an "IPv4-ID table"
   to be used for fragmentation processing (see Section 5.5).  These
   tables are initially empty.

   Each record of the IPv6-ID table is specific of a shared-address CE
   that is currently transmitting a fragmented datagram.  It contains:

   o  The CE IPv6 prefix.

   o  A CE IP identification.  This is the IPv4 Identification provided
      by the CE for the current fragmented datagram.

   o  A BR IP identification or NIL.  This is the IPv4 Identification
      provided by the BR to replace the CE IP Identification
      Section 5.5.  It is NIL for a fragmented datagram that the BR is
      currently discarding because a fragment has been found to be
      missing.

   The BR also initializes a generator of BR IP identifications.  It
   provides different values at each request, with a time between value
   re-use much longer than any realistic time for any fragmented
   datagram reception.

   Each record of the IPv4-ID table is specific of a fragmented datagram
   whose fragments are currently being relayed toward a shared address
   CE.  It contains:

   o  The IPv4 source address.

   o  The IP identification.

   o  The Destination port.

   A garbage collection has to be set up for records of the two tables
   that remain unchanged for much more than the maximum time a
   fragmented-datagram reception may take.  This value, which is not
   critical, MAY be set to 30 seconds.




Despres                   Expires July 1, 2012                 [Page 20]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   BR RECEPTION OF AN IPv4 PACKET

   When a BR receives an IPv4 packet:

   1.  For anti-spoofing protection, the BR checks that the source
       address of the IPv4 packet does not start with one of BR incoming
       prefixes from the Internet.  If the check fails, the packet is
       silently discarded.  Otherwise, the BR completes the IPv4-mapped
       IPv6 address to be used as IPv6 source address by including in it
       the IPv4 source address.

   2.  If the IPv4 packet is longer than the 4rd-U-domain PMTU minus 28,
       and has its DF bit set, the packet is silently discarded, and its
       processing is terminated.

   3.  If the packet is not a complete datagram (i.e. has MF=1 or Offset
       > 0), and if the Mapping rule whose Rule IPv4 prefix matches the
       IPv4 source address is one of shared-address CEs (i.e. if Rule-
       IPv4-prefix length plus EA-bits length exceeds 32), the the BR
       searches the IPv4-ID table for a record whose IPv4 source address
       and IP identification match those of the received packet.  It
       then does the following:

       *  If NO matching record is found:

          +  If the packet is a first fragment (i.e. has Offset = 0), a
             new record is created with values found in the packet.

          +  If the packet is an intermediate or last fragment (i.e. has
             Offset > 0), it is discarded, and packet processing is
             terminated.

       *  If a matching record is found:

          +  If the packet is a first fragment (i.e. has Offset = 0): it
             is discarded; the record is deleted, and packet processing
             is terminated.

          +  If the packet is an intermediate or last fragment (i.e. has
             Offset > 0), the Destination port of the record is taken a
             the port of this packet to be used to derive the
             destination IPv6 address.

          +  If the packet is a last fragment (i.e. has Offset > 0 and
             MF = 0): the record is deleted.






Despres                   Expires July 1, 2012                 [Page 21]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   4.  The BR derives the destination IPv4-mapped IPv6 address from the
       Residual-IPv4 destination of the IPv4 packet according to
       Section 5.4.

   5.  The BR derives the IPv6 header and its Fragment extension from
       the IPv4 header according to Section 5.1, and forwards the
       resulting packet in IPv6, fragmented if necessary.


   BR RECEPTION OF AN IPv6 PACKET

   When a BR receives an IPv6 packet, it does the following steps:

   1.  If the packet is an ICMPv6 packet, the BR translates it to an
       ICMPv4 packet according to Section 5.6, and forwards it in IPv4.

   2.  If the Mapping rule whose Rule IPv6 prefix matches the IPv6
       source address is one of shared-address CEs (i.e. if Rule-IPv4-
       prefix length plus EA-bits length exceeds 32), the BR searches
       the IP-identification table for a record whose CE IPv6 prefix
       matches the IPv6 source address, and does the following:

       *  If NO matching record is found:

          +  If the packet is a complete datagram (i.e. has Offset = 0
             and MF = 0), a new BR IP identification is obtained from
             the generator; the CE replaces the IPv4 identification by
             the new one.

          +  If the packet is a first fragment (i.e. has Offset = 0 and
             MF = 1), a new BR IP identification is obtained from the
             generator; the CE replaces the IPv4 identification by the
             new one; a record is created containing, (1) the CE IPv6
             prefix (the Rule IPv6 prefix followed by EA bits whose
             length is found in the Mapping rule), (2) the received IPv4
             identification as CE IP identification, (3) the new BR IP
             identification.

          +  If the packet is an intermediate or last fragment (i.e. has
             Offset > 0), it is discarded, and packet processing is
             terminated.










Despres                   Expires July 1, 2012                 [Page 22]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


       *  If a matching record is found:

          +  If the packet is a complete datagram (i.e. has Offset = 0
             and MF = 0), a new BR IP identification is obtained from
             the generator; the CE replaces the IPv4 identification by
             the new one; the record is deleted.

          +  If the packet is a first fragment (i.e. has Offset = 0 and
             MF = 1), a new BR IP identification is obtained from the
             generator; the CE replaces the IPv4 identification by the
             new one; the record is updated with it.

          +  If the packet is an intermediate fragment (i.e. has Offset
             > 0 and MF = 1), it is discarded if the record has NIL as
             BR IP identification.  It is also discarded, and BR IP
             identification is set to NIL, if the received CE IP
             identification differs from that of the record.  Otherwise,
             the CE replaces the IPv4 identification by the BR IP
             identification of the record.

          +  If the packet is a last fragment (i.e. has Offset > 0 and
             MF = 0): if the record has NIL as BR IP identification, or
             if the received CE IP identification differs from that of
             the record, the record is deleted, the packet is discarded,
             and packet processing is terminated.  Otherwise, the the CE
             replaces the IPv4 identification by the BR IP
             identification of the record, and the record is deleted.

   3.  The BR checks that the IPv6 source address of the received packet
       matches the IPv6 prefix that is derived from the source Residual-
       IPv4 address (this Residual-IPv4 address is the IPv4 address
       found in the source IPv6 address followed by the port field of
       the IP payload).  It also checks, for anti-routing-loop
       protection, that the destination IPv4 address does not start with
       one of the list of incoming prefixes from the Internet.  In case
       of failure of either check, the packet is silently discarded and
       packet processing is terminated.

   4.  The IPv6 header and its Fragment extension are mapped back to the
       original IPv4 header.  The packet is forwarded in IPv4.











Despres                   Expires July 1, 2012                 [Page 23]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   CE INITIALIZATION

   When a CE receives 4rd-U parameters, it checks that there is one and
   only one rule that has a 0.0.0.0/0 as Rule IPv4 prefix.  If yes, it
   computes its CE Residual-IPv4 prefix according to Section 5.4, and
   activates its 4rd-U function.  It informs its NAT44 of the IPv4
   prefix, or IPv4 address, or IPv4 address plus restricted port set,
   which is specified by this Residual-IPv4 prefix.  If this prefix is a
   /32 or longer, the CE derives from it its IPv4-mapped IPv6 address.
   If it is shorter, the CE computes the first 80 bits and the CNP part
   of its multiple IPv4-mapped IPv6 addresses.


   CE TRANSMISSION OF AN IPv6 PACKET

   When a CE has an IPv4 packet to transmit, coming from its NAT44:

   1.  If the IPv4 packet is longer than the 4rd-U-domain PMTU minus 28,
       and has its DF bit set, the packet is silently discarded, and its
       processing is terminated.

   2.  If the CE has a Residual-IPv4 prefix shorter than /32, it
       completes the IPv4-mapped IPv6 address to be used as source by
       copying in it the IPv4 source of the packet.

   3.  The CE derives the destination IPv4-mapped IPv6 address from the
       Residual-IPv4 destination of the IPv4 packet.

   4.  The CE derives an IPv6 header and it Fragment extension from the
       IPv4 header.  The resulting packet is forwarded in IPv6.


   CE RECEPTION OF AN IPv6 PACKET

   When a CE receives an IPv6 packet:

   1.  If the packet is an ICMPv6 packet, it translates it to an ICMPv4
       packet according to Section 5.6, and forwards it in IPv4.

   2.  If the packet contains a fragment of an incomplete datagram: the
       CE submits the fragment to IPv6 reassembly; if the datagram is
       the last one needed to reassemble a datagram the CE proceeds to
       the next step with the completed datagram; if not this terminates
       packet processing.







Despres                   Expires July 1, 2012                 [Page 24]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   3.  The CE checks that the IPv6 source address of the received packet
       matches the IPv6 prefix that is derived from the source Residual-
       IPv4 address (this Residual-IPv4 address is the IPv4 address
       found in the source IPv6 address followed by the port field of
       the IP payload).

   4.  The IPv6 header and its Fragment extension are mapped back to the
       original IPv4 header.  The packet is forwarded in IPv4.


6.  Use-Case Examples

   Examples presented in this section are selected to illustrate a few
   reference use cases from which real ones can be inspired.  Looking at
   details of each of these use case, or even to one of them, is not
   necessary to understand how 4rd-U works.  This may however be useful
   to check one's understanding, and to get an idea of the diversity of
   possible use cases.

   Mapping rules of examples of this section are noted as follows: {Rule
   IPv6 prefix, Rule IPv4 prefix, EA-bits length, Rule IPv6 suffix}.
   The Rule IPv6 suffix can be omitted if it has its ineffective value
   ::/0.  Examples: {198.32.0.0/13, 2001:db8::/33, 23, 5000::/4},
   {198.32.0.0/13, 2001:db8::/33, 23}

6.1.  Moving from IPv4-only to IPv6 and Residual IPv4

   We consider an ISP that offers IPv4 service to its customers.  Each
   customer is assigned an IPv4 address starting with one of the two
   following IPv4 prefixes: 198.32.0.0/13, 192.16.0.0/14. and wishes to
   assign to a new class of customers shared IPv4 addresses, using for
   this a distinct iPv4 prefix, 192.24.0.0/14, and 16 as sharing ratio.
   The ISP, because it provides its own CPEs to customers, can for this
   generalize 4rd-U.  It also wants to switch from IPv4-only routing to
   IPv6-only routing, planning for this two phases: during the first
   one, all CPE's are updated to support IPv6 and 4rd-U, and the IPv6
   routing plan that parallels the IPv4 routing plan is deployed; during
   the second phase, the IPv4 routing plan is deleted.

   The IPv6 prefix to be used by the ISP, its "common IPv6 prefix", is
   supposed to be 2001:db8::/32.  Delegated IPv6 prefixes are chosen to
   be /56s.  The IPv6 prefix assigned to BRs chosen to be 2001:db8:8000:
   1::/64








Despres                   Expires July 1, 2012                 [Page 25]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   Mapping rules for this network can then be the following.

    {192.32.0.0/13, 2001:db8:1800:/37,    19}
    {198.16.0.0/14, 2001:db8:1400::/38,   18}
    {198.24.0.0/14, 2001:db8:4000::/34,   22} (shared addresses)
    {0.0.0.0/,      2001:db8:8000:1::/64, 32} (domain exit)

   A CE that had IPv4 address 198.32.1.1 (0xc6200101) now derives its
   IPv4 address from its delegated IPv6 prefix 2001:db8:1801:100::/56 as
   follows:
                 Useful bits in nibbles => First Last
                                             |    |
   CE IPv6 prefix       2001 0DB8 1801 01    4    4
   Rule IPv6 prefix     2001 0DB8 18         4    1
   EA bits                         001 01    3    4
   Rule IPv4 prefix             C6 20        4    1 (198.32.0.0/13)
   IPv4 address                 C6 2001 01   4    4
                           i.e. 198.32.1.1

   The IPv6 address derived from IPv4 address 198.32.1.1 (0xC6200101);
   and any value 0xZZZZ in the port field is obtained as follows:

                           Useful bits in nibbles => First Last
                                                       |    |
   Residual-IPv4 address           C620 0101 ZZZZ      4    4
   Rule IPv4 prefix                C620                4    2
   EA bits                            0 0101           2    4
   Rule IPv6 prefix        20 010D B818                4    2
   Derived IPv6 prefix     20 010D B818 0101           4    4

   Derived IPv6 address    2010 0DB8 1801 1000 0300 C620 0101 XXXX
                      i.e. 2001:db8:1801:100:300:c618:0101:XXXX
      where XXXX = - UDP_Checksum(2001:db8:1801:100:300::/80)

   A new CE has shared IPv4 address 198.24.1.1 and PSID 0x2.  It derives
   its IPv4 address and PSID from its delegated IPv6 prefix 2001:db8:
   4010:1200::/56 as follows :
                 Useful bits in nibbles => First Last
                                             |    |
   CE IPv6 prefix       2001 0DB8 4010 12    4    4
   Rule IPv6 prefix     2001 0DB8 4          4    1
   IPv4 infix                     0010 0     2    4
   PSID                                 2    4    4 (0x2)
   Rule IPv4 prefix           C61 8          4    2 (198.24.0.0/14)
   IPv4 address               C61 8010 1     4    4
                         i.e. 198.24.1.1
   Ports in set                        Y2XX
                                with Y > 0, and XX any value



Despres                   Expires July 1, 2012                 [Page 26]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   The IPv6 address derived from IPv4 address 198.24.1.1 (0xC6180101)
   and 0x1200 in the port field is obtained as follows:


                           Useful bits in nibbles => First Last
                                                       |    |
   Residual-IPv4 address           C618 0101 1200      4    4
   Rule IPv4 prefix                C618                4    2
   IPv4 infix                         0 0101           2    4
   PSID                                       2        4    4
   Rule IPv6 prefix        2  0010 DB84                4    2
   Derived IPv6 prefix     2  0010 DB84 0101  2        4    4

   Derived IPv6 address    2001 0DB8 4010 1200 0300 C618 0101 XXXX
                      i.e. 2001:db8:4010:1200:300:c618:0101:XXXX
      where XXXX = - UDP_Checksum(2001:db8:4010:1200:300::/80)

6.2.  Residual-IPv4 Service via a Third-Party IPv6 Network

   An ISP wants to offer Internet service to its customers, both IPv4
   and IPv6, using for this an IPv6-only service deployed by a third
   party.  This third party provides its own CPEs and uses an
   hexadecimal digit to index their physical ports.  This digit is
   appended to site IPv6 prefixes to build prefixes that reach CPE ports
   to which 4rd-U CEs are attached.  On the third-party network,
   customer sites of the ISP are delegated /56 prefixes, all starting
   with 2001:db8::/32.

   The ISP supplies its own CEs to its customers, with NAT44s adapted to
   restricted port sets.  All CEs are attached to CPEs at their ports
   whose index is 0x5.  The IPv6 prefix routed to BRs sites is supposed
   to be 2001:db8:8080:8080::/56.

   To offer IPv4 connectivity to its potential 2^(56-32)=2^24 CEs, the
   ISP is supposed to have an IPv4 space of only 2^20 addresses.  Each
   IPv4 address has thus to be shared among 16 customers.  The IPv4
   address space available is supposed to have three prefixes
   198.32.0.0/13, 192.16.0.0/14, and 192.24.0.0/14, (the same as in
   Section 6.1).

   The following Mapping rules provide the desired Residual-IPv4
   service:

    {192.32.0.0/13, 2001:DB8::/33,           23, 5000::/4}
    {c610::/14,     2001:DB8:8000::/34,      22, 5000::/4}
    {198.24.0.0/14, 2001:DB8:C000::/34,      22, 5000::/4}
    {0.0.0.0/,      2001:DB8:8080:8080::/56,  0, 5000::/4}




Despres                   Expires July 1, 2012                 [Page 27]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   With these Mapping rules, a CE whose IPv6 prefix is 2001:db8:d111:
   1100::/56 derives its IPv4 address and its port set as follows:
                 Useful bits in nibbles => First Last
                                             |    |
   CE allocated prefix  2001 0DB8 C111 115   4    4
   Rule IPv6 prefix     2001 0BB8 C          4    2
   EA bits                        0111 11    2    4
   Rule IPv4 prefix           C61 8          4    2
   IPv4 address               C61 8111 1     4    4 (192.24.33.33)
   PSID                                 1    4    4
   Ports in port set                   Y1XX  4    4
                             (Y > 0, any xx)

   The IPv6 address that is derived from IPv4 address 192.24.33.33:4352
   (0xC6181111), is obtained as follows:

                          Useful bits in nibbles => First Last
                                                      |    |
  Residual-IPv4 address           C618 1111 1100      4    4
  Rule IPv4 prefix                C618                4    2
  IPv4 infix                         0 1111           2    4
  PSID                                       1        4    4
  EA bits                            0 1111 1         2    4
  Rule IPv6 prefix         2 0010 DB8C                4    2
  Derived IPv6 prefix      2 0010 DB8C 1111 15        4    4

  Derived IPv6 address     2001 0DB8 C111 1150 0300 C618 1111 XXXX
                      i.e. 2001:0db8:c111:1150:0300:c618:1111:XXXX
           in which XXXX = - UDP_Checksum(2001:0db8:c111:1150:0300::/80)

6.3.  Adding Residual IPv4 to an IPv6-only network

   An ISP offers an IPv6-only service on one of its infrastructures.  It
   wishes to also offer on it residual IPv4 connectivity, both outgoing
   and incoming.  For this, it wishes to offer a simpler solution for
   that of NAT64/DNS64 and PCP [RFC6146][RFC6147][I-D.ietf-pcp-base].
   It assigns /56 prefixes to its customers, all starting with 2001:
   db8::/32.  The available IPv4 prefix is 192.16.0.0/16 (0xC620), so
   that a sharing ratio of 256 is needed.

   The ISP then installs one or several identical BRs at its border to
   the IPv4 Internet, accessible for example at IPv6 prefix 2001:db8:0:
   100::/56, and can use the following Mapping rules:

    {192.16.0.0/16, 2001:db8::/32,      24}
    {0.0.0.0/,      2001:db8:0:100:/56,  0}





Despres                   Expires July 1, 2012                 [Page 28]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


6.4.  IPv6 and Residual-IPv4 added to a net-10 network

   An ISP has deployed an IPv4 network with [RFC1918] addresses
   10.x.x.x, and with one or several NAT44s at its border to the public
   IPv4 Internet.  It wishes to add IPv6 service to this "net-10
   network" but, because some of its network hardware is not ready for
   IPv6 yet, plans to deploy IPv6 with 6rd (xref target="RFC5969"/> It
   also wishes to offer incoming IPv4 connectivity to its customers with
   a simpler solution than that of PCP [I-D.ietf-pcp-base].  The IPv6
   prefix to be used for 6rd is 2001:db8::/32, and the public IPv4
   prefix to be used for shared addresses is 192.16.0.0/16 (0xc610).

   In conformance with [RFC5969], 6rd BRs are configured with the
   following parameters IPv4MaskLen = 8, 6rdPrefix = 2001:db8::/32;
   6rdBRIPv4Address = 192.168.0.1 (0xC0A80001).

   4rd-U is supported with one or several 4rd-U BRs, at the ISP border
   to the IPv4 Internet, which support both 6rd CE function in addition
   to their 4rd-U BR function.  They are supposed to be reachable at the
   IPv4 anycast address 10.0.0.1.

   The following 4rd-U Mapping rules are then configured in BRs and
   announced to CEs:

    {192.16.0.0/16, 2001:db8::/32,            24}
    {0.0.0.0/,      2001:db8:c0a8:2:3000:/80, 32}

   Once this is done, any customer device that supports 4rd-U can freely
   use its assigned public-IPv4 address subject to its assigned
   restricted port set of 240 ports.  Packets that use this address are
   mapped into IPv6 packets and encapsulated in IPv4 private-address
   packets.


7.  Security Considerations

   Spoofing attacks

      With checks of Section 5.8 that Residual-IPv4 source addresses are
      consistent with IPv6 sources addresses, and that source IPv4
      addresses coming from the Internet are not among those allocated
      to the 4rd-U domain, no opportunity for spoofing attacks in IPv4
      is introduced by 4rd-U.








Despres                   Expires July 1, 2012                 [Page 29]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   Routing-loop attacks

      Routing-loop attacks that may exist in some automatic-tunneling
      scenarios are documented in [RFC6324].  They cannot exist in 4rd-U
      because of BRs checks that IPv4 destination of packets they
      forward to the IPv4 Internet do not start with IPv4 prefixes for
      which BRs have incoming routes from the Internet.

   Denial-of-service attacks

      As discussed in Section 5.5, BRs that support shared-address rules
      must maintain dynamic tables of fragmented datagrams that
      currently traverse them.



      *  In the CE to Internet direction, this brings no new DOS-attack
         vulnerability because the table has at most one record per CE.

      *  In the Internet to CE direction, a vulnerability remains: a
         single remote hosts may send a large number of first datagram
         fragments without sending the next ones, thus occupying many
         table records.  Note however that the occupied space in memory
         is much lower than if datagrams should be reassembled before
         being forwarded, and that table overflow has no impact on non-
         fragmented datagrams, which normally are the vast majority in
         TCP.


8.  IANA Considerations

   IANA is requested to allocate the following:

   o  An IPv6 Interface-ID type reserved for 4rd-U (the V octet of
      Section 5.4, whose proposed value is 0x03).  This value needs to
      belong to a new registry to be created, for Interface-ID types
      that have neither local scope nor Modified EUI-64 format (ref.
      [RFC4291]).

   o  A reserved IPv4 address to be used as source of ICMPv4 messages
      translated from ICMPv6 error messages.  Its proposed value is
      192.70.192.254 (Section 5.6).

   o  Two DHCPv6 option codes, to be defined, for the OPTION_4RD_RULE
      and OPTION_4RD_PARAM of Section 5.7.






Despres                   Expires July 1, 2012                 [Page 30]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


9.  Contributors and Acknowledgements

   TBD.  This version is expected to be discussed, on the Softwire
   mailing list or otherwise, and to be improved following remarks and
   suggestions from interested contributors.

   So far, it has benefited from productive discussions with Maoke Chen
   and Qiong Sun following IETF 82, in particular concerning the
   relationship between 4rd-U an [RFC6145].


10.  References

10.1.  Normative References

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

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

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

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

   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
              Notification", RFC 6040, November 2010.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

10.2.  Informative References

   [I-D.despres-sam]
              Despres, R., "Stateless Address Mappings (SAMs) IPv6 &
              extended IPv4 via local routing  domains - possibly
              multihomed", draft-despres-sam-01 (work in progress),
              November 2008.

   [I-D.despres-softwire-4rd-addmapping]
              Despres, R., Qin, J., Perreault, S., and X. Deng,



Despres                   Expires July 1, 2012                 [Page 31]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


              "Stateless Address Mapping for IPv4 Residual Deployment
              (4rd)", draft-despres-softwire-4rd-addmapping-01 (work in
              progress), September 2011.

   [I-D.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-19 (work in progress), December 2011.

   [I-D.ietf-softwire-stateless-4v6-motivation]
              Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
              Borges, I., and G. Chen, "Motivations for Stateless IPv4
              over IPv6 Migration Solutions",
              draft-ietf-softwire-stateless-4v6-motivation-00 (work in
              progress), September 2011.

   [I-D.mdt-softwire-mapping-address-and-port]
              Troan, O., "Mapping of Address and Port (MAP)",
              draft-mdt-softwire-mapping-address-and-port-02 (work in
              progress), November 2011.

   [I-D.murakami-softwire-4rd]
              Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual
              Deployment on IPv6 infrastructure - protocol
              specification", draft-murakami-softwire-4rd-01 (work in
              progress), September 2011.

   [I-D.murakami-softwire-4v6-translation]
              Murakami, T., Chen, G., Deng, H., Dec, W., and S.
              Matsushima, "4via6 Stateless Translation",
              draft-murakami-softwire-4v6-translation-00 (work in
              progress), July 2011.

   [I-D.shirasaki-nat444]
              Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
              and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work
              in progress), July 2011.

   [I-D.xli-behave-divi]
              Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
              Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03
              (work in progress), July 2011.

   [I-D.xli-behave-divi-pd]
              Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun,
              "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix
              Delegation", draft-xli-behave-divi-pd-01 (work in
              progress), September 2011.



Despres                   Expires July 1, 2012                 [Page 32]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


   [I-D.xli-behave-icmp-address]
              Li, X., Bao, C., Wing, D., Vaithianathan, R., and G.
              Huston, "Stateless Source Address Mapping for ICMPv6
              Packets", draft-xli-behave-icmp-address-04 (work in
              progress), May 2011.

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

   [RFC1631]  Egevang, K. and P. Francis, "The IP Network Address
              Translator (NAT)", RFC 1631, May 1994.

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

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

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

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4961]  Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
              BCP 131, RFC 4961, July 2007.

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

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              April 2011.

   [RFC6219]  Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
              China Education and Research Network (CERNET) IVI
              Translation Design and Deployment for the IPv4/IPv6



Despres                   Expires July 1, 2012                 [Page 33]


Internet-Draft  Unified IPv4 Residual Deployment (4rd-U)   December 2011


              Coexistence and Transition", RFC 6219, May 2011.

   [RFC6324]  Nakibly, G. and F. Templin, "Routing Loop Attack Using
              IPv6 Automatic Tunnels: Problem Statement and Proposed
              Mitigations", RFC 6324, August 2011.


Author's Address

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

   Email: despres.remi@laposte.net



































Despres                   Expires July 1, 2012                 [Page 34]