IPv4 Residual Deployment


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

Features

IPv4 Residual Deployment has three main features:
Compared to other IETF-specified mechanisms having the same main features, i.e., MAP-E and MAP-T, its distinctive property is that it simultaneously supports:
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 : the chosen mechanism remains purely internal to each domain.

Principles

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

History

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.
Another stateless-mesh-A+P approach was next proposed, called dIVI. Instead of encapsulation, it used two successive translations, 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.
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.
After a long debate, the Softwire working group 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.
Finally, in December 2014 the Softwire working group 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.
This left 4rd alone in the Experimental category.

Real-world deployment

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.