6to4 Provider Managed Tunnels
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: "Nevil Brownlee" <firstname.lastname@example.org> Cc: The IESG <email@example.com>, <firstname.lastname@example.org>, <email@example.com> Subject: Results of IETF-conflict review for <draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt> The IESG has completed a review of <draft-kuarsingh-v6ops-6to4-provider-managed-tunnel> consistent with RFC5742. This review is applied to all non-IETF streams. The IESG has no problem with the publication of '6to4 Provider Managed Tunnels' <draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt> as an Informational RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Technical Summary 6to4 Provider Managed Tunnels (6to4-PMT) provide a framework which can help manage 6to4 [RFC3056] tunnels operating in an anycast [RFC3068] configuration. The 6to4-PMT framework is intended to serve as an option to 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 provides 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 [RFC3068] based 6to4 operation. The 6to4-PMT model has successfully been used in a production network and has been implemented as open source code and by a major routing vendor. Working Group Summary This document is not the product of any IETF WG. Document Quality This draft was considered by the V6OPS WG and considered to be out of scope. However, no significant defects in the document were identified. Personnel Ron Bonica is the document shepherd IESG Note The IESG has concluded that this work is related to IETF work done in the V6OPS WG, but this relationship does not prevent publishing.