(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?
Per the title page and the working group discussion, this document requests
consideration as a Best Current Practice. Per RFC 2026, "The BCP subseries of
the RFC series is designed to be a way to standardize practices and the results
of community deliberations." This document specifically notes that anycast
operation of 6to4 as described by RFCs 3068 and 6732 has not generally worked
well, and that if an operator is prepared to spend time and effort engineering
6to4 anycast deployment, the time and effort are better spent on native IPv6
deployment. As such the document is intended to give air cover to an operator
of an anycast 6to4 service, or the vendor of a product that might be used in
the anycast mode, to no longer do that.
(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary
Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6
transition mechanism defined in RFC 3056 has shown that when used in its
anycast mode, the mechanism is unsuitable for widespread deployment and use in
the Internet. This document therefore requests that RFC 3068, "An Anycast
Prefix for 6to4 Relay Routers", be made obsolete and moved to historic status.
It also obsoletes RFC 6732 "6to4 Provider Managed Tunnels". It recommends that
future products should not support 6to4 anycast and that existing deployments
should be reviewed. This complements the guidelines in RFC 6343.
Working Group Summary
The working group process, and interaction with the IESG, has been tortured.
The observation and notion were first discussed in 2011 in
draft-troan-v6ops-6to4-to-historic and draft-ietf-v6ops-6to4-to-historic. This
draft wanted to make 6to4 historic in any use case. It was discussed in IETF 80
(http://www.ietf.org/proceedings/80/v6ops.html), with statistical observations
from Geoff Huston regarding 6to4 and Teredo as seen in the APNIC Dark Net.
Working group viewpoints were not uniformly in favor, but those opposed were
listened to, and their arguments did not ultimately convince the remainder.
draft-ietf-v6ops-6to4-to-historic-05.txt was sent to the IESG, there was
apposing commentary during the IETF Last Call, and Pete Resnick filed a
"discuss" on the basis that smooth consensus had not been achieved.
The draft was revived in October 2014. During IPv6 deployment since 2011, the
use of Teredo and 6to4 as a percentage of IPv6 traffic had plummeted, and
operators were looking for air cover to turn 6to4 off. Those who had been
opposed in 2011 continued to be opposed, essentially because their use case
seemed to be working to their satisfaction, and they could not depend on
ubiquitous IPv6 deployment. draft-ietf-v6ops-6to4-to-historic-09.txt backed
away from "turn 6to4 off" to "turn anycast deployment of 6to4 off", and two
more versions addressed details. This change is explicitly supported by the
draft's most vocal critics.
At this point, those who have spoken in the conversation state that they
support or can live with this draft.
Document Quality
There are many networks that do not deploy anycast 6to4. It is far from a
mandatory service.
Personnel
The document shepherd is Fred Baker. The Area Director is Joel Jaeggli.
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.
The shepherd has been following discussions and reviewing versions of this
document since 2011. I read this version and agree that it states what I
understand the working group consensus to be.
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?
Not in the least. The working group, composed of operators, vendors, and users
of 6to4 equipment and services, has been over the document in excruciating
detail.
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.
No.
(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should be
aware of? For example, perhaps he or she is uncomfortable with certain parts of
the document, or has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.
No.
(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why.
Yes.
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.
No.
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?
At this point, not only those who have historically been in favor are in favor,
but those who have historically opposed it. The working group has gone far
beyond the usual standard of "rough consensus" to address any and all concerns.
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)
No.
(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.
the anycast address assigned for 6to4 is mentioned in the document and flagged
by idnits, and that the tool and the draft seem to not understand each other
regarding RFC 3068. In fact, the document header states that it obsoletes 3068,
and the abstract "requests that RFC 3068...be made obsolete and moved to
historic status."
(13) Have all references within this document been identified as either
normative or informative?
Yes
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?
No
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.
No
(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.
It obsoletes two documents, both of which are listed in the header and
mentioned in the abstract.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly
created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see
RFC 5226).
The IANA considerations have to do with the status of the IPv4 anycast address
used for 6to4. They are, to my knowledge, correct.