ObsoletedHISTORICINDEPENDENT stream

RFC 6732: 6to4 Provider Managed Tunnels

This RFC has been replaced. Do not implement against it for new work — it was formally obsoleted by RFC 7526.

Current document in this lineage: RFC 7526Deprecating the Anycast Prefix for 6to4 Relay Routers

In plain English — editorial summary, not part of the RFC

6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The 6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor. This document is not an Internet Standards Track specification; it is published for informational purposes.

Document record

Document ID
RFC6732
Published
September 2012
Authors
V. Kuarsingh; Y. Lee; O. Vautrin
Status
HISTORIC
Stream
INDEPENDENT
Area
Pages
12
Also known as
Obsoleted by:
RFC 7526

Topics

Standards lineage

This document is one revision in a chain of 3 RFCs, each formally replacing the one before it.

  1. RFC 3068 (2001)
  2. RFC 6732 (2012)
  3. RFC 7526 (2015)

Read the full history of Deprecating the Anycast Prefix for 6to4 Relay Routers

Referenced by

One later RFC formally updates or obsoletes part of this document.

Also filed under

About this page

The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.

Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.

Data sources · Editorial policy · Report a correction · What is an RFC?

canonical URL: /rfc/6732-6to4-provider-managed-tunnels