6to4 Provider Managed Tunnels
RFC 6732
Document | Type |
RFC - Historic
(September 2012; No errata)
Obsoleted by RFC 7526
Status changed by status-change-rfc-3068-anycast-prefix-for-6to4-to-historic
Was draft-kuarsingh-v6ops-6to4-provider-managed-tunnel (individual)
|
|
---|---|---|---|
Authors | Victor Kuarsingh , Yiu Lee , Olivier Vautrin | ||
Last updated | 2015-10-14 | ||
Stream | Independent Submission | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6732 (Historic) | |
Action Holders |
(None)
|
||
Telechat date | |||
Responsible AD | Ron Bonica | ||
IESG note | ISE Submission | ||
Send notices to | rfc-ise@rfc-editor.org |
Independent Submission V. Kuarsingh, Ed. Request for Comments: 6732 Rogers Communications Category: Informational Y. Lee ISSN: 2070-1721 Comcast O. Vautrin Juniper Networks September 2012 6to4 Provider Managed Tunnels Abstract 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. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6732. Kuarsingh, et al. Informational [Page 1] RFC 6732 6to4 Provider Managed Tunnels September 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction ....................................................3 2. Motivation ......................................................3 3. 6to4 Provider Managed Tunnels ...................................5 3.1. 6to4 Provider Managed Tunnel Model .........................5 3.2. Traffic Flow ..............................................5 3.3. Prefix Translation ........................................6 3.4. Translation State .........................................7 4. Deployment Considerations and Requirements ......................7 4.1. Customer Opt-Out ...........................................7 4.2. Shared CGN Space Considerations ............................8 4.3. End-to-End Transparency ....................................8 4.4. Path MTU Discovery Considerations ..........................9 4.5. Checksum Management ........................................9 4.6. Application Layer Gateways .................................9 4.7. Routing Requirements .......................................9 4.8. Relay Deployments .........................................10 5. Security Considerations ........................................10 6. Acknowledgements ...............................................10 7. References .....................................................11 7.1. Normative References ......................................11 7.2. Informative References ....................................11 Kuarsingh, et al. Informational [Page 2] RFC 6732 6to4 Provider Managed Tunnels September 2012 1. Introduction 6to4 [RFC3056] tunneling, along with the anycast operation described in [RFC3068], is widely deployed in modern Operating Systems and off-the-shelf gateways sold throughout retail and Original Equipment Manufacturer (OEM) channels. Anycast-based 6to4 [RFC3068] allows for tunneled IPv6 connectivity through IPv4 clouds without explicit configuration of a relay address. Since the overall system utilizes anycast forwarding in both directions, flow paths are difficult toShow full document text