Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7600

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

Pages: 45
Experimental
Errata
Part 2 of 2 – Pages 23 to 45
First   Prev   None

Top   ToC   RFC7600 - Page 23   prevText

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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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   ToC   RFC7600 - 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