Native IPv6 Across NAT44 CPEs (6a44)
draft-despres-softwire-6a44-01
Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Rémi Després , Brian E. Carpenter , Sheng Jiang | ||
Last updated | 2011-07-11 (Latest revision 2010-10-12) | ||
Replaced by | draft-despres-6a44 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Replaced by draft-despres-6a44 | |
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
Most CPEs should soon be dual stack, but a large installed base of IPv4-only CPEs is likely to remain for several years. Also, with the IPv4 address shortage, more and more ISPs will assign private IPv4 addresses to their customers. The need for IPv6 connectivity therefore concerns hosts behind IPv4-only CPEs, including such CPEs that are assigned private addresses. The 6a44 mechanism specified in this document addresses this need, without limitations and operational complexities of Tunnel Brokers and Teredo to do the same. 6a44 is based on an address mapping and on a mechanism whereby suitably upgraded hosts behind a NAT may obtain IPv6 connectivity via a stateless 6a44 server function operated by their Internet Service Provider. With it, IPv6 traffic between two 6a44 hosts in a single site remains within the site. Except for IANA numbers that remain to be assigned, the specification is intended to be complete enough for running codes to be independently written and interwork.
Authors
Rémi Després
Brian E. Carpenter
Sheng Jiang
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)