IPv4 Residual Deployment via IPv6 - Unified Solution (4rd)

Document Type Expired Internet-Draft (individual)
Last updated 2012-09-29 (latest revision 2012-03-28)
Replaces draft-despres-softwire-4rd-addmapping
Stream (None)
Intended RFC status (None)
Expired & archived
plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of RFC6145).


Remi Despres (despres.remi@laposte.net)
Reinaldo Penno (rpenno@juniper.net)
Yiu Lee (yiu_lee@cable.comcast.com)
Gang Chen (phdgang@gmail.com)
Jacni Qin (jacni@jacni.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)