Native IPv6 Behind NAT44 CPEs (6a44)

The information below is for an old version of the document
Document Type Expired Internet-Draft (individual)
Authors Remi Despres  , Dan Wing  , Sheng Jiang 
Last updated 2011-07-06
Replaces draft-despres-softwire-6a44, draft-despres-intarea-6a44
Stream (None)
Expired & archived
pdf htmlized (tools) htmlized 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)
RFC Editor RFC Editor state ISR-AUTH

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. The specification is complete enough for actual deployment, including with independently written codes.


Remi Despres (
Dan Wing (
Sheng Jiang (

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