(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:
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.
There are many networks that do not deploy anycast 6to4. It is far from a mandatory service.
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.
(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.
(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.
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
(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.)
(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?
(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?
(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.
(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.