Native IPv6 Behind NAT44 CPEs (6a44)

Document Type Replaced Internet-Draft (individual)
Authors Remi Despres  , Brian Carpenter  , Dan Wing  , Sheng Jiang 
Last updated 2011-07-11 (latest revision 2011-03-07)
Replaced by RFC 6751
Stream (None)
Intended RFC status (None)
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-despres-6a44
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


In customer sites having IPv4-only CPEs, Teredo provides a last resort IPv6 connectivity [RFC4380] [RFC5991] [RFC6081]. However, because it is designed to work without involvement of Internet service providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being base on ISP cooperation, avoids these limitations. At the beginning of IPv6 addresses, it replaces the Teredo well-known prefix by network specific prefixes assigned by local ISP's (an evolution similar to that from 6to4 to 6rd). In hosts, 6a44 can be implemented either autonomously or as an extension of Teredo. Except for IANA numbers that remain to be confirmed, the specification is intended to be complete enough for running codes to be independently written and the solution to be incrementally deployed.


Remi Despres (
Brian Carpenter (
Dan Wing (
Sheng Jiang (

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