tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7600

 
 
 

IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)

Part 2 of 2, p. 23 to 45
Prev RFC Part

 


prevText      Top      Up      ToC       Page 23 
4.6.  Fragmentation Processing

4.6.1.  Fragmentation at Domain Entry

   R-14: If an IPv4 packet enters a CE or BR with a size such that the
         derived Tunnel packet would be longer than the Domain PMTU, the
         packet has to be either discarded or fragmented.  The
         Domain-entry node MUST discard it if the packet has DF = 1,
         with an ICMP error message returned to the source.  It MUST
         fragment it otherwise, with the payload of each fragment not
         exceeding PMTU - 48.  The first fragment has its offset equal
         to the received offset.  Subsequent fragments have offsets
         increased by the lengths of the payloads of previous fragments.
         Functionally, fragmentation is supposed to be done in IPv4
         before applying reversible header translation to each fragment;
         see Section 4.3.

Top      Up      ToC       Page 24 
4.6.2.  Ports of Fragments Addressed to Shared-Address CEs

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

   For this, a BR MAY systematically reassemble fragmented IPv4 packets
   before tunneling them.  But this consumes large memory space, creates
   opportunities for denial-of-service-attacks, and can significantly
   increase forwarding delays.  This is the reason for the following
   requirement:

   R-15: BRs SHOULD support an algorithm whereby received IPv4 packets
         can be forwarded on the fly.  The following is an example of
         such an algorithm:

         (1)  At BR initialization, if at least one CE Mapping rule
              deals with one or more shared public IPv4 addresses (i.e.,
              length of Rule IPv4 prefix + EA-bits length > 32), the BR
              initializes an empty "IPv4 packet table" whose entries
              have the following items:

                 - IPv4 source

                 - IPv4 destination

                 - IPv4 identification

                 - Destination port

         (2)  When the BR receives an IPv4 packet whose matching Mapping
              rule deals with one or more shared public IPv4 addresses
              (i.e., length of Rule IPv4 prefix + EA-bits length > 32),
              the BR searches the table for an entry whose IPv4 source,
              IPv4 destination, and IPv4 identification are those of the
              received packet.  The BR then performs actions as detailed
              in Table 5, depending on which conditions hold.

Top      Up      ToC       Page 25 
      +-----------------------------+---+---+---+---+---+---+---+---+
      | - CONDITIONS -              |   |   |   |   |   |   |   |   |
      | First Fragment (offset = 0) | Y | Y | Y | Y | N | N | N | N |
      | Last fragment (MF = 0)      | Y | Y | N | N | Y | Y | N | N |
      | An entry has been found     | Y | N | Y | N | Y | N | Y | N |
      | -------------------------   |   |   |   |   |   |   |   |   |
      | - RESULTING ACTIONS -       |   |   |   |   |   |   |   |   |
      | Create a new entry          | - | - | - | X | - | - | - | - |
      | Use port of the entry       | - | - | - | - | X | - | X | - |
      | Update port of the entry    | - | - | X | - | - | - | - | - |
      | Delete the entry            | X | - | - | - | X | - | - | - |
      | Forward the packet          | X | X | X | X | X | - | X | - |
      +-----------------------------+---+---+---+---+---+---+---+---+

                            Table 5: BR Actions

         (3)  The BR performs garbage collection for table entries that
              remain unchanged for longer than some limit.  This limit,
              which is normally longer than the maximum time normally
              needed to reassemble a packet, is not critical.  It should
              not, however, be longer than 15 seconds [RFC791].

   R-16: For the above algorithm to be effective, CEs that are assigned
         shared public IPv4 addresses MUST NOT interleave fragments of
         several fragmented packets.

   R-17: CEs that are assigned IPv4 prefixes and are in nodes that route
         public IPv4 addresses rather than only using NAT44s MUST have
         the same behavior as that described just above for BRs.

Top      Up      ToC       Page 26 
4.6.3.  Packet Identifications from Shared-Address CEs

   When packets go from CEs that share the same IPv4 address to a common
   destination, a precaution is needed to guarantee that packet
   identifications set by sources are different.  Otherwise, packet
   reassembly at the destination could be confused because it is based
   only on source IPv4 address and Identification.  The probability of
   such confusing situations may in theory be very low, but a safe
   solution is needed in order to avoid creating new attack
   opportunities.

   R-18: A CE that is assigned a shared public IPv4 address MUST only
         use packet identifications that have the CE PSID in their
         bits 0 to PSID length - 1.

   R-19: A BR or a CE that receives a packet from a shared-address CE
         MUST check that bits 0 to PSID length - 1 of their packet
         identifications are equal to the PSID found in the source 4rd
         IPv4 address.

4.7.  TOS and Traffic Class Processing

   IPv4 TOS and IPv6 traffic class have the same semantic, that of the
   differentiated services field, or DS field, specified in [RFC2474]
   and [RFC6040].  Their first 6 bits contain a differentiated services
   codepoint (DSCP), and their last 2 bits can convey explicit
   congestion notifications (ECNs), which both may evolve during Domain
   traversal.  [RFC2983] discusses how the DSCP can be handled by tunnel
   endpoints.  The Tunnel Traffic Class option provides permission to
   ignore DS-field evolutions occurring during Domain traversal, if the
   desired behavior is that of generic tunnels conforming to [RFC2473].

   R-20: Unless the Tunnel Traffic Class option is configured for the
         Domain, BRs and CEs MUST copy the IPv4 TOS into the IPv6
         traffic class at Domain entry and copy back the IPv6 traffic
         class into the IPv4 TOS at Domain exit.

   R-21: If the Tunnel Traffic Class option is configured for a Domain,
         BRs and CEs MUST at Domain entry take the configured Tunnel
         Traffic Class as the IPv6 traffic class and copy the received
         IPv4 TOS into the IPv4_TOS of the fragment header (Figure 3).
         At Domain exit, they MUST copy back the IPv4_TOS of the
         fragment header into the IPv4 TOS.

Top      Up      ToC       Page 27 
4.8.  Tunnel-Generated ICMPv6 Error Messages

   If a Tunnel packet is discarded on its way across a 4rd domain
   because of an unreachable destination, an ICMPv6 error message is
   returned to the IPv6 source.  For the IPv4 source of the discarded
   packet to be informed of packet loss, the ICMPv6 message has to be
   converted into an ICMPv4 message.

   R-22: If a CE or BR receives an ICMPv6 error message [RFC4443], it
         MUST synthesize an ICMPv4 error packet [RFC792].  This packet
         MUST contain the first 8 octets of the discarded packet's IP
         payload.  The reserved IPv4 dummy address (192.0.0.8/32; see
         Section 6) MUST be used as its source address.

         As described in [RFC6145], ICMPv6 Type = 1 and Code = 0
         (Destination Unreachable, No route to destination) MUST be
         translated into ICMPv4 Type = 3 and Code = 0 (Destination
         Unreachable, Net unreachable), and ICMPv6 Type = 3 and Code = 0
         (Time Exceeded, Hop limit exceeded in transit) MUST be
         translated into ICMPv4 Type = 11 and Code = 0 (Time Exceeded,
         time to live exceeded in transit).

4.9.  Provisioning 4rd Parameters to CEs

   Domain parameters listed in Section 4.2 are subject to the following
   constraints:

   R-23: Each Domain MUST have a BR Mapping rule and/or a NAT64+ Mapping
         rule.  The BR Mapping rule is only used by CEs that are
         assigned public IPv4 addresses, shared or not.  The NAT64+
         Mapping rule is only used by CEs that are assigned the
         unspecified IPv4 address (Section 4.4) and therefore need an
         ISP NAT64 to reach IPv4 destinations.

   R-24: Each CE and each BR MUST support up to 32 Mapping rules.

         Support for up to 32 Mapping rules ensures that independently
         acquired CEs and BR nodes can always interwork.

         ISPs that need Mapping rules for more IPv4 prefixes than this
         number SHOULD split their networks into multiple Domains.
         Communication between these domains can be done in IPv4 or by
         some other implementation-dependent, but equivalent, means.

Top      Up      ToC       Page 28 
   R-25: For mesh topologies, where CE-CE paths don't go via BRs, all
         Mapping rules of the Domain MUST be sent to all CEs.  For
         hub-and-spoke topologies, where all CE-CE paths go via BRs,
         each CE MAY be sent only the BR Mapping rule of the Domain
         plus, if different, the CE Mapping rule that applies to its CE
         IPv6 prefix.

   R-26: In a Domain where the chosen topology is hub-and-spoke, all CEs
         MUST have IPv6 prefixes that match a CE Mapping rule.
         (Otherwise, packets sent to CEs whose IPv6 prefixes would match
         only the BR Mapping rule would, with longest-match selected
         routes, be routed directly to these CEs.  This would be
         contrary to the hub-and-spoke requirement.)

   R-27: CEs MUST be able to acquire parameters of 4rd domains
         (Section 4.2) in DHCPv6 [RFC3315].  Formats of DHCPv6 options
         to be used are detailed in Figures 7, 8, and 9, with field
         values specified after each figure.

    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 = OPTION_4RD      |         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 encapsulated 4rd rule options                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 7: DHCPv6 Option for 4rd

   o  option code: 97, OPTION_4RD (see Section 6)

   o  option-length: the length of encapsulated options, in octets

Top      Up      ToC       Page 29 
   o  encapsulated 4rd rule options: The OPTION_4RD DHCPv6 option
      contains at least one encapsulated OPTION_4RD_MAP_RULE option and
      a maximum of one encapsulated OPTION_4RD_NON_MAP_RULE option.
      Since DHCP servers normally send whatever options the operator
      configures, operators are advised to configure these options
      appropriately.  DHCP servers MAY check to see that the
      configuration follows these rules and notify the operator in an
      implementation-dependent manner if the settings for these options
      aren't valid.  The length of encapsulated options is in octets.

      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 = OPTION_4RD_MAP_RULE  |         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  prefix4-len  |  prefix6-len  |    ea-len     |W|   Reserved  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    rule-ipv4-prefix                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                        rule-ipv6-prefix                       |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 8: Encapsulated Option for Mapping-Rule Parameters

   o  option code: 98, encapsulated OPTION_4RD_MAP_RULE option (see
      Section 6)

   o  option-length: 20

   o  prefix4-len: number of bits of the Rule IPv4 prefix

   o  prefix6-len: number of bits of the Rule IPv6 prefix

   o  ea-len: EA-bits length

   o  W: WKP authorized, = 1 if set

   o  rule-ipv4-prefix: Rule IPv4 prefix, left-aligned

   o  rule-ipv6-prefix: Rule IPv6 prefix, left-aligned

Top      Up      ToC       Page 30 
      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 =OPTION_4RD_NON_MAP_RULE|         option-length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |H|      0    |T| traffic-class |         domain-pmtu           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 9: Encapsulated Option for Non-Mapping-Rule Parameters
                              of 4rd Domains

   o  option code: 99, encapsulated OPTION_4RD_NON_MAP_RULE option (see
      Section 6)

   o  option-length: 4

   o  H: Hub-and-spoke topology (= 1 if Yes)

   o  T: Traffic Class flag (= 1 if a Tunnel Traffic Class is provided)

   o  traffic-class: Tunnel Traffic Class

   o  domain-pmtu: Domain PMTU (at least 1280 octets)

   Means other than DHCPv6 that may prove useful to provide 4rd
   parameters to CEs are off-scope for this document.  The same or
   similar parameter formats would, however, be recommended to
   facilitate training and operation.

5.  Security Considerations

   Spoofing attacks

      With IPv6 ingress filtering in effect in the Domain [RFC3704], as
      required in Section 3 (Figure 1 in particular), and with
      consistency checks between 4rd IPv4 and IPv6 addresses
      (Section 4.5), no spoofing opportunity in IPv4 is introduced by
      4rd: being able to use as source IPv6 address only one that has
      been allocated to him, a customer can only provide as source 4rd
      IPv4 address that which derives this IPv6 address according to
      Section 4.5, i.e., one that his ISP has allocated to him.

   Routing loop attacks

      Routing loop attacks that may exist in some "automatic tunneling"
      scenarios are documented in [RFC6324].  No opportunities for
      routing loop attacks have been identified with 4rd.

Top      Up      ToC       Page 31 
   Fragmentation-related attacks

      As discussed in Section 4.6, each BR of a Domain that assigns
      shared public IPv4 addresses should maintain a dynamic table of
      fragmented packets that go to these shared-address CEs.

      This leaves BRs vulnerable to denial-of-service attacks from hosts
      that would send very large numbers of first fragments and would
      never send last fragments having the same packet identifications.
      This vulnerability is inherent in IPv4 address sharing, be it
      static or dynamic.  Compared to what it is with algorithms that
      reassemble IPv4 packets in BRs, it is, however, significantly
      mitigated by the algorithm provided in Section 4.6.2, as that
      algorithm uses much less memory space.

6.  IANA Considerations

   IANA has allocated the following:

   o  Encapsulated options OPTION_4RD (97), OPTION_4RD_MAP_RULE (98),
      and OPTION_4RD_NON_MAP_RULE (99).  These options have been
      recorded in the option code space of the "Dynamic Host
      Configuration Protocol for IPv6 (DHCPv6)" registry.  See
      Section 4.9 of this document and Section 24.3 of [RFC3315]).

         Value   |      Description        |  Reference
      -----------+-------------------------+---------------
           97    |       OPTION_4RD        | this document
           98    |   OPTION_4RD_MAP_RULE   | this document
           99    | OPTION_4RD_NON_MAP_RULE | this document

   o  Reserved IPv4 address 192.0.0.8/32 to be used as the "IPv4 dummy
      address" (Section 4.8).

7.  Relationship with Previous Works

   The present specification has been influenced by many previous IETF
   drafts, in particular those accessible at
   <http://tools.ietf.org/html/draft-xxxx>, where "xxxx" refers to the
   following (listed in order, by date of their first versions):

   o  bagnulo-behave-nat64 (2008-06-10)

   o  xli-behave-ivi (2008-07-06)

   o  despres-sam-scenarios (2008-09-28)

   o  boucadair-port-range (2008-10-23)

Top      Up      ToC       Page 32 
   o  ymbk-aplusp (2008-10-27)

   o  xli-behave-divi (2009-10-19)

   o  thaler-port-restricted-ip-issues (2010-02-28)

   o  cui-softwire-host-4over6 (2010-07-06)

   o  dec-stateless-4v6 (2011-03-05)

   o  matsushima-v6ops-transition-experience (2011-03-07)

   o  despres-intarea-4rd (2011-03-07)

   o  deng-aplusp-experiment-results (2011-03-07)

   o  operators-softwire-stateless-4v6-motivation (2011-05-05)

   o  xli-behave-divi-pd (2011-07-04)

   o  murakami-softwire-4rd (2011-07-04)

   o  murakami-softwire-4v6-translation (2011-07-04)

   o  despres-softwire-4rd-addmapping (2011-08-19)

   o  boucadair-softwire-stateless-requirements (2011-09-08)

   o  chen-softwire-4v6-add-format (2011-10-12)

   o  mawatari-softwire-464xlat (2011-10-16)

   o  mdt-softwire-map-dhcp-option (2011-10-24)

   o  mdt-softwire-mapping-address-and-port (2011-10-24)

   o  mdt-softwire-map-translation (2012-01-10)

   o  mdt-softwire-map-encapsulation (2012-01-27)

Top      Up      ToC       Page 33 
8.  References

8.1.  Normative References

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <http://www.rfc-editor.org/info/rfc791>.

   [RFC792]   Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <http://www.rfc-editor.org/info/rfc792>.

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998,
              <http://www.rfc-editor.org/info/rfc2460>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <http://www.rfc-editor.org/info/rfc2474>.

   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
              RFC 2983, DOI 10.17487/RFC2983, October 2000,
              <http://www.rfc-editor.org/info/rfc2983>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315,
              July 2003,
              <http://www.rfc-editor.org/info/rfc3315>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291,
              February 2006,
              <http://www.rfc-editor.org/info/rfc4291>.

Top      Up      ToC       Page 34 
   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", RFC 4443,
              DOI 10.17487/RFC4443, March 2006,
              <http://www.rfc-editor.org/info/rfc4443>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [RFC4925]  Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A.
              Durand, Ed., "Softwire Problem Statement", RFC 4925,
              DOI 10.17487/RFC4925, July 2007,
              <http://www.rfc-editor.org/info/rfc4925>.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
              <http://www.rfc-editor.org/info/rfc5082>.

   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
              Notification", RFC 6040, DOI 10.17487/RFC6040,
              November 2010,
              <http://www.rfc-editor.org/info/rfc6040>.

8.2.  Informative References

   [NAT444]   Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
              and H. Ashida, "NAT444", Work in Progress,
              draft-shirasaki-nat444-06, July 2012.

   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <http://www.rfc-editor.org/info/rfc768>.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              DOI 10.17487/RFC1191, November 1990,
              <http://www.rfc-editor.org/info/rfc1191>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <http://www.rfc-editor.org/info/rfc1918>.

Top      Up      ToC       Page 35 
   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998,
              <http://www.rfc-editor.org/info/rfc2473>.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              DOI 10.17487/RFC3022, January 2001,
              <http://www.rfc-editor.org/info/rfc3022>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704,
              March 2004,
              <http://www.rfc-editor.org/info/rfc3704>.

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
              and G. Fairhurst, Ed., "The Lightweight User Datagram
              Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828,
              July 2004,
              <http://www.rfc-editor.org/info/rfc3828>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed.,
              "A Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
              <http://www.rfc-editor.org/info/rfc4821>.

   [RFC4961]  Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
              BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
              <http://www.rfc-editor.org/info/rfc4961>.

   [RFC5595]  Fairhurst, G., "The Datagram Congestion Control Protocol
              (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595,
              September 2009,
              <http://www.rfc-editor.org/info/rfc5595>.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification", RFC
              5969, DOI 10.17487/RFC5969, August 2010,
              <http://www.rfc-editor.org/info/rfc5969>.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
              <http://www.rfc-editor.org/info/rfc6145>.

Top      Up      ToC       Page 36 
   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011,
              <http://www.rfc-editor.org/info/rfc6146>.

   [RFC6324]  Nakibly, G. and F. Templin, "Routing Loop Attack Using
              IPv6 Automatic Tunnels: Problem Statement and Proposed
              Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011,
              <http://www.rfc-editor.org/info/rfc6324>.

   [RFC6346]  Bush, R., Ed., "The Address plus Port (A+P) Approach to
              the IPv4 Address Shortage", RFC 6346, DOI 10.17487/
              RFC6346, August 2011,
              <http://www.rfc-editor.org/info/rfc6346>.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437,
              DOI 10.17487/RFC6437, November 2011,
              <http://www.rfc-editor.org/info/rfc6437>.

   [RFC6535]  Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
              Using "Bump-in-the-Host" (BIH)", RFC 6535,
              DOI 10.17487/RFC6535, February 2012,
              <http://www.rfc-editor.org/info/rfc6535>.

   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              DOI 10.17487/RFC6887, April 2013,
              <http://www.rfc-editor.org/info/rfc6887>.

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014,
              <http://www.rfc-editor.org/info/rfc7136>.

   [Solutions-4v6]
              Boucadair, M., Ed., Matsushima, S., Lee, Y., Bonness, O.,
              Borges, I., and G. Chen, "Motivations for Carrier-side
              Stateless IPv4 over IPv6 Migration Solutions", Work in
              Progress, draft-ietf-softwire-stateless-4v6-motivation-05,
              November 2012.

Top      Up      ToC       Page 37 
Appendix A.  Textual Representation of Mapping Rules

   In the sections that follow, each Mapping rule will be represented as
   follows, using 0bXXX to represent binary number XXX; square brackets
   ("[ ]") indicate optional items:

   {Rule IPv4 prefix, EA-bits length, Rule IPv6 prefix
      [, WKPs authorized]}

   EXAMPLES:
    {0.0.0.0/0, 32, 2001:db8:0:1:300::/80}
                               a BR Mapping rule
    {198.16.0.0/14, 22, 2001:db8:4000::/34}
                               a CE Mapping rule
    {0.0.0.0/0, 32, 2001:db8:0:1::/80}
                               a NAT64+ Mapping rule
    {198.16.0.0/14, 22, 2001:db8:4000::/34, Yes}
                               a CE Mapping rule
                                 and hub-and-spoke topology

Appendix B.  Configuring Multiple Mapping Rules

   As far as Mapping rules are concerned, the simplest deployment model
   is that in which the Domain has only one rule (the BR Mapping rule).
   To assign an IPv4 address to a CE in this model, an IPv6 /112 is
   assigned to it, comprising the BR /64 prefix, the 4rd Tag, and the
   IPv4 address.  However, this model has the following limitations: (1)
   shared IPv4 addresses are not supported; (2) IPv6 prefixes used for
   4rd are too long to also be used for native IPv6 addresses; (3) if
   the IPv4 address space of the ISP is split with many disjoint IPv4
   prefixes, the IPv6 routing plan must be as complex as an IPv4 routing
   plan based on these prefixes.

   With more Mapping rules, CE prefixes used for 4rd can be those used
   for native IPv6.  How to choose CE Mapping rules for a particular
   deployment does not need to be standardized.

   The following is only a particular pragmatic approach that can be
   used for various deployment scenarios.  It is applied in some of the
   use cases that follow.

   (1)  Select a "Common_IPv6_prefix" that will appear at the beginning
        of all 4rd CE IPv6 prefixes.

   (2)  Choose all IPv4 prefixes to be used, and assign one of them to
        each CE Mapping rule i.

Top      Up      ToC       Page 38 
   (3)  For each CE Mapping rule i, do the following:

        A.  Choose the length of its Rule IPv6 prefix (possibly the same
            for all CE Mapping rules).

        B.  Determine its PSID_length(i).  A CE Mapping rule that
            assigns shared addresses with a sharing ratio of 2^Ki has
            PSID_length = Ki.  A CE Mapping rule that assigns IPv4
            prefixes of length L < 32 is considered to have a negative
            PSID_length (PSID_length = L - 32).

        C.  Derive EA-bits length(i) = 32 - L(Rule IPv4 prefix(i)) +
            PSID_length(i).

        D.  Derive the length of Rule_code(i), the prefix to be appended
            to the common prefix to get the Rule IPv6 prefix of rule i:

              L(Rule_code(i)) = L(CE IPv6 prefix(i))
                                - L(Common_IPv6_prefix)
                                - (32 - L(Rule IPv4 prefix(i)))
                                - PSID_length(i)

        E.  Derive Rule_code(i) with the following constraints: (1) its
            length is L(Rule_code(i)); (2) it does not overlap with any
            of the previously obtained Rule_codes (for instance, 010 and
            01011 do overlap, while 00, 011, and 010 do not); (3) it has
            the lowest possible value as a fractional binary number (for
            instance, 0100 < 10 < 11011 < 111).  Thus, rules whose
            Rule_code lengths are 4, 3, 5, and 2 give Rule_codes 0000,
            001, 00010, and 01.

Top      Up      ToC       Page 39 
        F.  Take Rule IPv6 prefix(i) = the Common_IPv6_prefix followed
            by Rule_code(i).

   :<--------------------- L(CE IPv6 prefix(i)) --------------------->:
   :                                                                  :
   :                       32 - L(Rule IPv4 prefix(i))  PSID_length(i):
   :                                                \             |   :
   :                                      :<---------'--------><--'-->:
   :                                      :              ||           :
   :                                      :              \/           :
   :                            :<------->:<--- EA-bits length(i) --->:
   :                          L(Rule_code(i))
   :                            :         :
   +----------------------------+---------+
   |    Common_IPv6_prefix      |Rule_code|
   |                            |   (i)   |
   +----------------------------+---------+
   :<------ L(Rule IPv6 prefix(i)) ------>:

               Figure 10: Diagram of One Pragmatic Approach

Appendix C.  Adding Shared IPv4 Addresses to an IPv6 Network

C.1.  With CEs within CPEs

   Here, we consider an ISP that offers IPv6-only service to up to 2^20
   customers.  Each customer is delegated a /56, starting with common
   prefix 2001:db8:0::/36.  The ISP wants to add public IPv4 service for
   customers that are 4rd capable.  It prefers to do so with stateless
   operation in its nodes but has significantly fewer IPv4 addresses
   than IPv6 addresses, so a sharing ratio is necessary.

   The only IPv4 prefixes it can use are 192.8.0.0/15, 192.4.0.0/16,
   192.2.0.0/16, and 192.1.0.0/16 (neither overlapping nor
   aggregatable).  This gives 2^(32 - 15) + 3 * 2^(32 - 16) IPv4
   addresses, i.e., 2^18 + 2^16.  For the 2^20 customers to have the
   same sharing ratio, the number of IPv4 addresses to be shared has to
   be a power of 2.  The ISP can therefore give up using one of its
   /16s, say the last one.  (Whether or not it could be motivated to
   return it to its Internet Registry is off-scope for this document.)
   The sharing ratio to apply is then 2^20 / 2^18 = 2^2 = 4, giving a
   PSID length of 2.

Top      Up      ToC       Page 40 
   Applying the principles of Appendix B with L(Common_IPv6_prefix) =
   36, L(PSID) = 2 for all rules, and L(CE IPv6 prefix(i)) = 56 for all
   rules, Rule_codes and Rule IPv6 prefixes are as follows:

   +--------------+--------+-----------+-----------+-------------------+
   | CE Rule IPv4 | EA     | Rule-Code | Code      | CE Rule IPv6      |
   | prefix       | bits   | length    | (binary)  | prefix            |
   |              | length |           |           |                   |
   +--------------+--------+-----------+-----------+-------------------+
   | 192.8.0.0/15 | 19     | 1         | 0         | 2001:db8:0::/37   |
   | 192.4.0.0/16 | 18     | 2         | 10        | 2001:db8:800::/38 |
   | 192.2.0.0/16 | 18     | 2         | 11        | 2001:db8:c00::/38 |
   +--------------+--------+-----------+-----------+-------------------+

   Mapping rules are then the following:

             {192.8.0.0/15, 19, 2001:0db8:0000::/37}
             {192.4.0.0/16, 18, 2001:0db8:0800::/38}
             {192.2.0.0/16, 18, 2001:0db8:0c00::/38}
             {0.0.0.0/0,    32, 2001:0db8:0000:0001:300::/80}

   The CE whose IPv6 prefix is, for example, 2001:db8:0bbb:bb00::/56
   derives its IPv4 address and its port set as follows (Section 4.4):

      CE IPv6 prefix     : 2001:0db8:0bbb:bb00::/56
      Rule IPv6 prefix(i): 2001:0db8:0800::/38 (longest match)
      EA-bits length(i)  : 18
      EA bits            : 0b11 1011 1011 1011 1011
      Rule IPv4 prefix(i): 0b1100 0000 0000 0100 (192.4.0.0/16)
      IPv4 address       : 0b1100 0000 0000 0100 1110 1110 1110 1110
                         : 192.4.238.238
      PSID               : 0b11
      Ports              : 0bYYYY 11XX XXXX XXXX
                           with YYYY > 0, and X...X any value

Top      Up      ToC       Page 41 
   An IPv4 packet sent to address 192.4.238.238 and port 7777 is
   tunneled to the IPv6 address obtained as follows (Section 4.5):

      IPv4 address       : 192.4.238.238 (0xc004 eeee)
                         : 0b1100 0000 0000 0100 1110 1110 1110 1110
      Rule IPv4 prefix(i): 192.4.0.0/16  (longest match)
                         : 0b1100 0000 0000 0100
      IPv4 suffix(i)     : 0b1110 1110 1110 1110
      EA-bits length(i)  : 18
      PSID length(i)     : 2  (= 16 + 18 - 32)
      Port field         : 0b 0001 1110 0110 0001 (7777)
      PSID               : 0b11
      Rule IPv6 prefix(i): 2001:0db8:0800::/38
      CE IPv6 prefix     : 2001:0db8:0bbb:bb00::/56
      IPv6 address       : 2001:0db8:0bbb:bb00:300:c004:eeee:YYYY
                           with YYYY = the computed CNP

C.2.  With Some CEs behind Third-Party Router CPEs

   We now consider an ISP that has the same need as the ISP described in
   the previous section, except that (1) instead of using only its own
   IPv6 infrastructure, it uses that of a third-party provider and (2)
   some of its customers use this provider's Customer Premises Equipment
   (CPEs) so that they can use specific services offered by the
   provider.  In these CPEs, a non-zero index is used to route IPv6
   packets to the physical port to which CEs are attached, say 0x2.
   Each such CPE delegates to the CE nodes the customer-site IPv6 prefix
   followed by this index.

   The ISP is supposed to have the same IPv4 prefixes as those in the
   previous use case -- 192.8.0.0/15, 192.4.0.0/16, and 192.2.0.0/16 --
   and to use the same Common_IPv6_prefix, 2001:db8:0::/36.

   We also assume that only a minority of customers use third-party
   CPEs, so that it is sufficient to use only one of the two /16s for
   them.

   Mapping rules are then (see Appendix C.1):

             {192.8.0.0/15, 19, 2001:0db8:0000::/37}
             {192.4.0.0/16, 18, 2001:0db8:0800::/38}
             {192.2.0.0/16, 18, 2001:0db8:0c00::/38}
             {0.0.0.0/0,    32, 2001:0db8:0000:0001:300::/80}

   CEs that are behind third-party CPEs derive their own IPv4 addresses
   and port sets as described in Appendix C.1.

Top      Up      ToC       Page 42 
   In a BR, and also in a CE if the topology is mesh, the IPv6 address
   that is derived from IPv4 address 192.4.238.238 and port 7777 is
   obtained as described in the previous section, except for the last
   two steps, which are modified as follows:

      IPv4 address       : 192.4.238.238 (0xc004 eeee)
                         : 0b1100 0000 0000 0100 1110 1110 1110 1110
      Rule IPv4 prefix(i): 192.4.0.0/16  (longest match)
                         : 0b1100 0000 0000 0100
      IPv4 suffix(i)     : 0b1110 1110 1110 1110
      EA-bits length(i)  : 18
      PSID length(i)     : 2  (= 16 + 18 - 32)
      Port field         : 0b 0001 1110 0110 0001 (7777)
      PSID               : 0b11
      Rule IPv6 prefix(i): 2001:0db8:0800::/38
      CE IPv6 prefix     : 2001:0db8:0bbb:bb00::/60
      IPv6 address       : 2001:0db8:0bbb:bb00:300:192.4.238.238:YYYY
                           with YYYY = the computed CNP

Appendix D.  Replacing Dual-Stack Routing with IPv6-Only Routing

   In this use case, we consider an ISP that offers IPv4 service with
   public addresses individually assigned to its customers.  It also
   offers IPv6 service, as it has deployed dual-stack routing.  Because
   it provides its own CPEs to customers, it can upgrade all of its CPEs
   to support 4rd.  It wishes to take advantage of this capability to
   replace dual-stack routing with IPv6-only routing, without changing
   any IPv4 address or IPv6 prefix.

   For this, the ISP can use the single-rule model described at the
   beginning of Appendix B.  If the prefix routed to BRs is chosen to
   start with 2001:db8:0:1::/64, this rule is:

      {0.0.0.0/0, 32, 2001:db8:0:1:300::/80}

   All that is needed in the network before disabling IPv4 routing is
   the following:

   o  In all routers, where there is an IPv4 route toward x.x.x.x/n, add
      a parallel route toward 2001:db8:0:1:300:x.x.x.x::/(80+n).

   o  Where IPv4 address x.x.x.x was assigned to a CPE, now delegate
      IPv6 prefix 2001:db8:0:1:300:x.x.x.x::/112.

Top      Up      ToC       Page 43 
   NOTE: In parallel with this deployment, or after it, shared IPv4
   addresses can be assigned to IPv6 customers.  It is sufficient that
   IPv4 prefixes used for this be different from those used for
   exclusive-address assignments.  Under this constraint, Mapping rules
   can be set up according to the same principles as those described in
   Appendix C.

Appendix E.  Adding IPv6 and 4rd Service to a Net-10 Network

   In this use case, we consider an ISP that has only deployed IPv4,
   possibly because some of its network devices are not yet IPv6
   capable.  Because it did not have enough IPv4 addresses, it has
   assigned private IPv4 addresses [RFC1918] to customers, say 10.x.x.x.
   It thus supports up to 2^24 customers (a "Net-10" network, using the
   NAT444 model [NAT444]).

   Now, it wishes to offer IPv6 service without further delay, using 6rd
   [RFC5969].  It also wishes to offer incoming IPv4 connectivity to its
   customers with a simpler solution than that provided by the Port
   Control Protocol (PCP) [RFC6887].

   This appendix describes an example that adds IPv6 (using 6rd) and 4rd
   services to the "Net-10" private IPv4 network.

   The IPv6 prefix to be used for 6rd is supposed to be 2001:db8::/32,
   and the public IPv4 prefix to be used for shared addresses is
   supposed to be 198.16.0.0/16 (0xc610).  The resulting sharing ratio
   is 2^24 / 2^(32 - 16) = 256, giving a PSID length of 8.

   The ISP installs one or several BRs at its border to the public IPv4
   Internet.  They support 6rd, and 4rd above it.  The BR prefix /64 is
   supposed to be that which is derived from IPv4 address 10.0.0.1
   (i.e., 2001:db8:0:100:/64).

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

   4rd Mapping rules are then the following:

               {198.16.0.0/16, 24, 2001:db8:0:0:300::/80}
               {0.0.0.0/0,     32, 2001:db8:0:100:300:/80,}

   Any customer device that supports 4rd in addition to 6rd can then use
   its assigned shared IPv4 address with 240 assigned ports.

Top      Up      ToC       Page 44 
   If its NAT44 supports port forwarding to provide incoming IPv4
   connectivity (statically, or dynamically with Universal Plug and Play
   (UPnP) and/or the NAT Port Mapping Protocol (NAT-PMP)), it can use it
   with ports of the assigned port set (a possibility that does not
   exist in Net-10 networks without 4rd/6rd).

Acknowledgements

   This specification has benefited over several years from independent
   proposals, questions, comments, constructive suggestions, and useful
   criticisms from numerous IETF contributors.  The authors would like
   to express recognition of all of these contributors, and especially
   the following, in alphabetical order by their first names: Behcet
   Sarikaya, Bing Liu, Brian Carpenter, Cameron Byrne, Congxiao Bao, Dan
   Wing, Derek Atkins, Erik Kline, Francis Dupont, Gabor Bajko, Hui
   Deng, Jacni Quin (who was an active coauthor of some earlier versions
   of this specification), James Huang, Jan Zorz, Jari Arkko, Kathleen
   Moriarty, Laurent Toutain, Leaf Yeh, Lorenzo Colitti, Marcello
   Bagnulo, Mark Townsley, Mohamed Boucadair, Nejc Skoberne, Olaf
   Maennel, Ole Troan, Olivier Vautrin, Peng Wu, Qiong Sun, Rajiv Asati,
   Ralph Droms, Randy Bush, Satoru Matsushima, Simon Perreault, Stuart
   Cheshire, Suresh Krishnan, Ted Lemon, Teemu Savolainen, Tetsuya
   Murakami, Tina Tsou, Tomek Mrugalski, Washam Fan, Wojciech Dec,
   Xiaohong Deng, Xing Li, and Yu Fu.

Authors' Addresses

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

   Email: despres.remi@laposte.net


   Sheng Jiang (editor)
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No. 156 BeiQing Road
   Hai-Dian District, Beijing  100095
   China

   Email: jiangsheng@huawei.com

Top      Up      ToC       Page 45 
   Reinaldo Penno
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   United States

   Email: repenno@cisco.com


   Yiu Lee
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   United States

   Email: yiu_lee@cable.comcast.com


   Gang Chen
   China Mobile
   29, Jinrong Avenue
   Xicheng District, Beijing  100033
   China

   Email: phdgang@gmail.com, chengang@chinamobile.com


   Maoke Chen (a.k.a. Noriyuki Arai)
   BBIX, Inc.
   Tokyo Shiodome Building, Higashi-Shimbashi 1-9-1
   Minato-ku, Tokyo  105-7310
   Japan

   Email: maoke@bbix.net