IPv4 Residual Deployment via IPv6 - Unified Solution (4rd)
draft-despres-softwire-4rd-u-06
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Rémi Després , Reinaldo Penno , Yiu Lee , Gang Chen , Jacni Qin | ||
Last updated | 2012-09-29 (Latest revision 2012-03-28) | ||
Replaces | draft-despres-softwire-4rd-addmapping | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
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).
Authors
Rémi Després
Reinaldo Penno
Yiu Lee
Gang Chen
Jacni Qin
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)