IPv4 Residual Deployment

Edit links
From Wikipedia, the free encyclopedia
IPv6 transition mechanisms
Standards Track
Experimental
Informational
Drafts
Deprecated

IPv4 Residual Deployment (4rd) is an IPv6 transition mechanism for Internet service providers for deployment of Internet Protocol version 6 (IPv6), while maintaining IPv4 service to customers. The protocol and sample applications are specified in RFC 7600.

Features[edit]

IPv4 Residual Deployment has three main features:

  • Mesh topology: between two endpoints, IPv4 packets take the same direct routes as IPv6 packets.[1]
  • Shared IPv4 addresses: to deal with the unavoidable IPv4-address shortage, several customers can be assigned a common IPv4 address, with disjoint TCP/UDP port sets assigned to each (an application of the general A+P model of RFC 6346).
  • Stateless operation: conversions of IPv4 packets into IPv6 packets at domain entry, and the reverse at domain exit, are stateless (i.e., one where no per-customer state is needed in domain edge nodes).

Compared to other IETF-specified mechanisms having the same main features, i.e., MAP-E (RFC 7597, RFC 7598, RFC 2473) and MAP-T (RFC 7599, RFC 7598, RFC 6145), its distinctive property is that it simultaneously supports:

  • Full IPv4-fragmentation transparency: with this feature, support of the path MTU Discovery of RFC 4821, recommended in RFC 6349, is preserved. Without it, wherever firewalls filter ICMP packets, end systems that support RFC 4821[2] lose their ability to take advantage of paths that support large packets .
  • Applicability of IPv6 packet inspections to IPv4: when traversing IPv6-only domains, converted IPv4 packets are ordinary IPv6 packets, with their contents unchanged and valid in IPv6.[3] Thus, IPv6 filters that are performed within the IPv6-only domain, e.g. for Access Control Lists, Web caches, Deep packet inspections, are, implicitly and automatically, effective on domain-traversing IPv4 packets.

MAP-E only supports the former, and MAP-T only supports the latter.

If an ISP wants to offer residual IPv4 service across an IPv6-only domain, and provides customer-premises equipment to all its customers of this domain, it can choose any of MAP-E, MAP-T, or 4rd, with due awareness that MAP-E and MAP-T are specified in standards-track RFCs, while 4rd is, at least so far, specified in an experimental-track RFC (see the History section below): the chosen mechanism remains purely internal to each domain.

Principles[edit]

The key that permits to combine IPv4-fragmentation transparency with IPv6 deep packet Inspection in a single design is the use of a reversible packet translation at Domain Entries and Exits.[3] This is possible because IPv6 packet headers, duly complemented with their Fragment headers whenever needed, are large enough to encode in them, in an ad hoc way detailed in RFC 7600, all useful IPv4-header information. (This was not possible in 6rd, the tunneling mechanism for IPv6 across IPv4-only domains, because IPv4 headers are too small to contain all IPv6-header information).

IP-layer options of IPv4 are not supported in 4rd, but without practical consequence because end systems are already adapted to the fact that, for security reasons, IPv4 IP-layer options are filtered by many routers.[4]

Another issue about which the 4rd specification goes beyond those of MAP-E and MAP-T concerns fragmented IPv4 datagrams. In MAP-E and MAP-T specifications, the only fully described behaviors involves datagram reassembly at domain entry before forwarding.[5][6] In order to improve user-perceived performance, to reduce domain-entry processing, and to reduce attack opportunities, the 4rd specification includes an algorithm whereby received fragments of large datagrams are forwarded one by one on the fly.[7]

History[edit]

The first "4rd" specification, unlike the current one of RFC 7600, used IPv4 encapsulation in IPv6 packets, the only known tunneling approach at that time to ensure complete IPv4 preservation across IPv6-only domains. It was the first proposal that combined stateless address mapping, mesh topology, and A+P.[8][9]

Another stateless-mesh-A+P approach was next proposed, called dIVI.[10] Instead of encapsulation, it used two successive translations (from IPv4 to IPv6 and then conversely), based on the existing SIIT one-way translations of RFC 2765. Compared to encapsulation, it had the advantage of making IPv6 packet inspections applicable to translated UDP and TCP IPv4 packets, but, due to limitations of SIIT, lacked full compatibility with IPv4 fragmentation (and consequently, as mentioned above, compatibility with path MTU Discovery recommended in RFC 6349).

In this context, approval of one of the two designs as single standard seemed out of reach, despite the general wish for standard unicity. Two different directions were then taken.

  • One proposed to rename the 4rd encapsulation solution as MAP-E, to rename the double SIIT translation as MAP-T, and to associate them into a combined specification named MAP.[11] The idea was that, to satisfy the standard unicity objective, a specification having two variants (among which a choice remains needed for each IPv6-only domain), might be considered as equivalent to a single standard. But no consensus was reached on this interpretation.[12]
  • The other was based on discovery that, as mentioned above, an upgraded IPv4-IPv6 double translation algorithm was possible that combined applicability of IPv6 packet inspections to IPv4, like MAP-T, and full compatibility with IPv4 fragmentation like MAP-E. As the "4rd" acronym was no longer used for the encapsulation solution, this solution was named 4rd. A proposal to take this approach for a unique standard was made.[13] But, despite a validation of its principle on an implementation,[14] did not raise interest from supporters of either MAP-E, or MAP-T.[12]

After a long debate, the Softwire working group [15] decided, in August 2012, that MAP-E alone would be standardized, and that work could continue on both 4rd and MAP-T, but only as experimental.[12]

Finally, in December 2014 the Softwire working group[15] changed its previous decision, and decided to put MAP-T on Standards Track in parallel with MAP-E, provided a note in the MAP-T RFC would signal its incompatibility with the path MTU Discovery of RFC 4821.[16]

This left 4rd alone in the Experimental category (yet with ISPs' possibility to deploy it, for its functional advantages, in domains where they provide customer premises equipment to all their customers).

Real-world deployment[edit]

The French ISP Free is deemed to have deployed 4rd for its experiment of FTTH in "lesser-dense areas", starting from December 2015. The implementation of the A+P model implies the attribution of four contiguous port ranges to different customers for each IPv4 address. Free was also known to be the first implementer of 6rd.[17]

References[edit]

  1. ^ Wu, J.; Cui, Y.; Metz, C.; Rosen, E. (2009). "IPv4-over-IPv6 mesh scenario". doi:10.17487/RFC5565. {{cite journal}}: Cite journal requires |journal= (help)
  2. ^ "Does Linux have an Equivalent of Windows PMTU Blackhole Router Discovery?".
  3. ^ a b Despres, R.; Penno, R.; Lee, Y.; Chen, G.; Chen, M.; Chen, M. (2015). Jiang, S. (ed.). "Reversible Packet Translations at Domain Entries and Exits". doi:10.17487/RFC7600. {{cite journal}}: Cite journal requires |journal= (help)
  4. ^ Dugal, D.; Pignataro, C.; Dunn, R. (2011). "Design Trade-Offs - in RFC 6192". doi:10.17487/RFC6192. {{cite journal}}: Cite journal requires |journal= (help)
  5. ^ Dec, W.; Li, X.; Bao, C.; Matsushima, S.; Murakami, T.; Murakami, T.; Taylor, T. (2015). Troan, O.; Taylor, T. (eds.). "Receiving IPv4 Fragments on the MAP domain borders (MAP-E case )". doi:10.17487/RFC7597. {{cite journal}}: Cite journal requires |journal= (help)
  6. ^ Li, X.; Bao, C.; Troan, O.; Matsushima, S.; Murakami, T.; Murakami, T. (2015). Dec, W. (ed.). "Receiving IPv4 Fragments on the MAP domain borders (MAP-T case)". doi:10.17487/RFC7599. {{cite journal}}: Cite journal requires |journal= (help)
  7. ^ Despres, R.; Penno, R.; Lee, Y.; Chen, G.; Chen, M.; Chen, M. (2015). Jiang, S. (ed.). "Ports of Fragments Addressed to Shared-Address CEs (4rd case)". CiteSeerX 10.1.1.697.6541. doi:10.17487/RFC7600. {{cite journal}}: Cite journal requires |journal= (help)
  8. ^ "Public IPv4 addresses and IPv4E prefixes across IPv6-only Domains 4rd". Ietf Datatracker.
  9. ^ "IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT's made optional". Ietf Datatracker.
  10. ^ "draft-xli-behave-divi-02". Ietf Datatracker.
  11. ^ "draft-ietf-softwire-map-00". Ietf Datatracker.
  12. ^ a b c "IETF-84 - Softwire WG - Meeting minutes".
  13. ^ "draft-ietf-softwire-map-00".
  14. ^ "4rd Implementation Report".
  15. ^ a b "IETF Softwires (softwire) Working Group".
  16. ^ "[Softwires] MAP-T to Standards Track".
  17. ^ Champeau, Guillaume (15 February 2016). "Free peut attribuer la même adresse IP à plusieurs abonnés". Numerama (in French). Retrieved 29 February 2016.
Retrieved from "https://en.wikipedia.org/w/index.php?title=IPv4_Residual_Deployment&oldid=1194883402"