Skip to main content

Native IPv6 Behind NAT44 CPEs (6a44)
draft-despres-intarea-6a44-00

Document Type Replaced Internet-Draft (individual)
Expired & archived
Authors Rémi Després , Brian E. Carpenter , Dan Wing , Sheng Jiang
Last updated 2011-07-11 (Latest revision 2011-03-07)
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

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.

Authors

Rémi Després
Brian E. Carpenter
Dan Wing
Sheng Jiang

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