Skip to main content

Deprecating the Anycast Prefix for 6to4 Relay Routers
RFC 7526

Revision differences

Document history

Date Rev. By Action
2015-05-21
11 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2015-05-20
11 (System) RFC published
2015-04-20
11 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-04-15
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-03-17
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-03-16
11 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-03-15
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-03-11
11 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Nevil Brownlee.
2015-03-10
11 (System) IANA Action state changed to In Progress
2015-03-09
11 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-03-09
11 (System) RFC Editor state changed to EDIT
2015-03-09
11 (System) Announcement was received by RFC Editor
2015-03-09
11 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-03-09
11 Amy Vezza IESG has approved the document
2015-03-09
11 Amy Vezza Closed "Approve" ballot
2015-03-09
11 Amy Vezza Ballot writeup was changed
2015-03-09
11 Joel Jaeggli IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2015-03-09
11 Joel Jaeggli Ballot writeup was changed
2015-03-05
11 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2015-03-05
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-03-05
11 Adrian Farrel [Ballot comment]
Thank you for the progress with this document since I first balloted No Objection.
2015-03-05
11 Adrian Farrel Ballot comment text updated for Adrian Farrel
2015-03-04
11 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-03-04
11 Richard Barnes [Ballot comment]
For additional color, see: https://labs.ripe.net/Members/rbarnes/world-ipv6-day-asymmetric-6to4-measurements
2015-03-04
11 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2015-03-04
11 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-03-04
11 Brian Haberman [Ballot comment]
I appreciate the difficulty in getting consensus on this document and applaud the diligence of the authors and chairs in finding that consensus.
2015-03-04
11 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-03-03
11 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-03-02
11 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-03-01
11 Joel Jaeggli Ballot has been issued
2015-03-01
11 Joel Jaeggli [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli
2015-02-22
11 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from No Record
2015-02-19
11 Ted Lemon
[Ballot comment]
I am somewhat discouraged that this document doesn't make stronger recommendations, and question whether the consensus process was really run correctly.  I think …
[Ballot comment]
I am somewhat discouraged that this document doesn't make stronger recommendations, and question whether the consensus process was really run correctly.  I think that there was a fair amount of content-free posturing during the discussion, and that this held more sway over the eventual outcome than was really appropriate.

That said, I appreciate the efforts of the authors, working group chairs and AD to come to a resolution of the process, and I think this document is better than no document, so I am balloting No Objection.
2015-02-19
11 Ted Lemon Ballot comment text updated for Ted Lemon
2015-02-19
11 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2015-02-18
11 Joel Jaeggli Changed consensus to Yes from Unknown
2015-02-18
11 Joel Jaeggli IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2015-02-18
11 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-02-16
11 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Record from Abstain
2015-02-16
11 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2015-02-16
11 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-v6ops-6to4-to-historic-11.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-v6ops-6to4-to-historic-11.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

Upon approval of this document, IANA understands that there is a single action which must be completed.

In the IANA IPv4 Special-Purpose Address Registry located at:

https://www.iana.org/assignments/iana-ipv4-special-registry/

the entry for the 6to4 relay anycast prefix (192.88.99.0/24) will be marked as "Deprecated (6to4 Relay Anycast)", with a reference to the present document, and added a Termination Date upon
approval of this draft.

Comment: for clarity purposes, the authors should add add the following text or something
to that effect in the IC section:

The boolean values for the address block 192.88.99.0/24 will be all removed. 

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2015-02-14
11 Joel Jaeggli Placed on agenda for telechat - 2015-03-05
2015-02-10
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nevil Brownlee
2015-02-10
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nevil Brownlee
2015-02-05
11 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2015-02-05
11 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2015-02-04
11 Cindy Morgan IANA Review state changed to IANA - Review Needed
2015-02-04
11 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Deprecating Anycast Prefix for 6to4 …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Deprecating Anycast Prefix for 6to4 Relay Routers) to Best Current Practice


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Deprecating Anycast Prefix for 6to4 Relay Routers'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-02-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ballot/


No IPR declarations have been submitted directly on this I-D.


2015-02-04
11 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2015-02-04
11 Cindy Morgan Last call announcement was generated
2015-02-04
11 Joel Jaeggli Last call was requested
2015-02-04
11 Joel Jaeggli Ballot approval text was generated
2015-02-04
11 Joel Jaeggli looks good to me in this form. lets do it.
2015-02-04
11 Joel Jaeggli IESG state changed to Last Call Requested from AD Evaluation
2015-01-31
11 Joel Jaeggli IESG state changed to AD Evaluation from Publication Requested
2015-01-30
11 Cindy Morgan Intended Status changed to Best Current Practice from Informational
2015-01-30
11 Cindy Morgan Shepherding AD changed to Joel Jaeggli
2015-01-30
11 Cindy Morgan IESG state changed to Publication Requested from Dead
2015-01-30
11 Fred Baker As discussed on the list.
2015-01-30
11 Fred Baker IETF WG state changed to Submitted to IESG for Publication from Adopted by a WG
2015-01-30
11 Fred Baker
(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? …
(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.
2015-01-30
11 Fred Baker Notification list changed to draft-ietf-v6ops-6to4-to-historic.all@tools.ietf.org from v6ops-chairs@tools.ietf.org, draft-ietf-v6ops-6to4-to-historic@tools.ietf.org
2015-01-28
11 Brian Carpenter New version available: draft-ietf-v6ops-6to4-to-historic-11.txt
2015-01-04
10 Brian Carpenter New version available: draft-ietf-v6ops-6to4-to-historic-10.txt
2014-12-10
09 Brian Carpenter New version available: draft-ietf-v6ops-6to4-to-historic-09.txt
2014-12-10
08 Fred Baker IETF WG state changed to Adopted by a WG from Submitted to IESG for Publication
2014-11-13
08 Brian Carpenter New version available: draft-ietf-v6ops-6to4-to-historic-08.txt
2014-11-10
07 Brian Carpenter New version available: draft-ietf-v6ops-6to4-to-historic-07.txt
2014-10-20
06 Brian Carpenter New version available: draft-ietf-v6ops-6to4-to-historic-06.txt
2012-08-22
05 (System) post-migration administrative database adjustment to the Abstain position for Pete Resnick
2011-12-26
05 (System) Document has expired
2011-08-08
05 Ron Bonica State changed to Dead from AD is watching.
2011-07-25
05 Pete Resnick
[Ballot discuss]
1. I am convinced that there is no IETF-wide consensus for this document based on the Last Call discussion.

2. In light of …
[Ballot discuss]
1. I am convinced that there is no IETF-wide consensus for this document based on the Last Call discussion.

2. In light of draft-ietf-v6ops-6to4-advisory, I do not understand the necessity of this document. In particular, it seems that the proponents of this document think of making the 6to4 documents "Historic" will somehow punish 6to4 and stop implementations from doing the bad things they are worried about. If -advisory is not thought to be strong enough to discourage the bad behavior, I suggest instead that a normative document be written that gives instructions on what to do and not to do in order to minimize damage due to this protocol.
2011-07-05
05 Ron Bonica State changed to AD is watching from Dead.
2011-07-02
05 Ron Bonica State changed to Dead from Approved-announcement to be sent::Point Raised - writeup needed.
2011-06-24
05 (System) New version available: draft-ietf-v6ops-6to4-to-historic-05.txt
2011-06-23
05 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Tina Tsou.
2011-06-23
05 Cindy Morgan Removed from agenda for telechat
2011-06-23
05 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation.
2011-06-23
05 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to Abstain from Discuss
2011-06-23
05 Amy Vezza Ballot writeup text changed
2011-06-23
05 Dan Romascanu [Ballot comment]
I support the procedural issue raised by Pete.
2011-06-23
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-06-23
05 Amy Vezza State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-06-23
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-06-23
05 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
05 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
05 David Harrington Request for Last Call review by TSVDIR Completed. Reviewer: Dan Wing.
2011-06-22
05 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
05 Ralph Droms
[Ballot comment]
I've reviewed the IETF last call discussion for this document, and
come to my own conclusion about consensus of community support for
publication …
[Ballot comment]
I've reviewed the IETF last call discussion for this document, and
come to my own conclusion about consensus of community support for
publication of this document.  Based on my conclusion, I will vote "No
Objection."

Like Stewart, I would like the responsible AD to provide a summary of
the issues raised in the IETF last call, some indication of whether
those issues will result in any changes to the document and a
consensus call on the discussion.
2011-06-22
05 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-06-22
05 Russ Housley [Ballot comment]
The authors have agreed to incorporate the editorial comments from the
  Gen-ART Review by Ben Campbell on 17-Jun-2011.
2011-06-22
05 Adrian Farrel [Ballot comment]
I am ballotting "no Objection" but I agree with the bulk of Discuss and Comments raised
2011-06-22
05 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-06-21
05 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-06-21
05 Stephen Farrell
[Ballot comment]
(1) Why repeat stuff from draft-ietf-v6ops-6to4-advisory?  I think
just referring to that document would be better since it gives a
fuller and …
[Ballot comment]
(1) Why repeat stuff from draft-ietf-v6ops-6to4-advisory?  I think
just referring to that document would be better since it gives a
fuller and better explanation. That could lead to just removing
section 3 entirely I think.

(2) I have no strong opinion as to whether deprecating the
domain and addresses in section 5 is right or wrong. However, I do
think that since draft-ietf-v6ops-6to4-advisory does have what look
like some very useful recommendations about these, that a reference
to that document in the IANA considerations section would be
good since the current text there looks like its saying "turn all
that off please" and I don't think that's what you're trying to say.

Maybe something like:

"Note however that [I-D.ietf-v6ops-6to4-advisory] recommends that
various actors take various actions related to these addresses. The
reader is encouraged to follow those recommendations and is not
encouraged to simply turn off these addresses."

If putting that in the IANA considerations section is wrong,  then
I think correcting the impression elsewhere would be good, maybe
with something like:

"Despite what you might think from reading the IANA considerations
section of this document, we are not recommending that people turn
off the addresses deprecated there. The IANA considerations section
is simply a set of instructions to IANA. Please consult 
[I-D.ietf-v6ops-6to4-advisory] for the actual set of actions
recommended."

(I'm sure the phrase "turn off" in the suggested text above is wrong,
but that should be easily corrected and it may need to also say
something about the domain as well, I don't know.)
2011-06-21
05 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded
2011-06-20
05 David Harrington [Ballot Position Update] New position, No Objection, has been recorded
2011-06-20
05 Stewart Bryant
[Ballot comment]
Looking at the IETF LC discussion it's clear
that consensus to proceed is pretty rough.
However I think that on ballance the rough …
[Ballot comment]
Looking at the IETF LC discussion it's clear
that consensus to proceed is pretty rough.
However I think that on ballance the rough is
probably in favour of publication.

Given the above, I think that the responsible AD
needs to provide a more extensive review of
the consensus issues in  the announcement
text than is currently proposed.

Given the extended dialogue that the proto statement
indicates took place I am supprised that there is not
greater discussion of the alternatives and rational
for picking this approach provided in the text of
the draft.
2011-06-20
05 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-06-20
05 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-06-19
05 Pete Resnick
[Ballot discuss]
1. I am not convinced of consensus for this document based on the Last Call discussion.

2. In light of draft-ietf-v6ops-6to4-advisory, I …
[Ballot discuss]
1. I am not convinced of consensus for this document based on the Last Call discussion.

2. In light of draft-ietf-v6ops-6to4-advisory, I do not understand the necessity of this document.

3. Procedural: This Informational document invokes Standards Actions (i.e., moving two documents from Standards Track to Historic and making changes to IANA registries). However, the ballot procedure we are using is the one for Informational documents which requires only a single "Yes" and no "Discuss". That seems inappropriate.
2011-06-19
05 Pete Resnick
[Ballot discuss]
1. I am not convinced of consensus for this document based on the Last Call discussion.
2. In light of draft-ietf-v6ops-6to4-advisory, I …
[Ballot discuss]
1. I am not convinced of consensus for this document based on the Last Call discussion.
2. In light of draft-ietf-v6ops-6to4-advisory, I do not understand the necessity of this document.
3. Procedural: This Informational document invokes Standards Actions (i.e., moving two documents from Standards Track to Historic and making changes to IANA registries). However, the ballot procedure we are using is the one for Informational documents which requires only a single "Yes" and no "Discuss". That seems inappropriate.
2011-06-19
05 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded
2011-06-17
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tina Tsou
2011-06-17
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tina Tsou
2011-06-16
05 Wesley Eddy [Ballot comment]
Should "transitioning" be "transition" in the abstract?

Note, this is informational and uses 2119 language in section 4.
2011-06-16
05 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-06-15
05 Amanda Baber
IANA has questions about the IANA Actions in this document.

The document states: "IANA is requested to mark the 2.0.0.2.ip6.arpa
domain [RFC5158] as …
IANA has questions about the IANA Actions in this document.

The document states: "IANA is requested to mark the 2.0.0.2.ip6.arpa
domain [RFC5158] as "deprecated", pointing to this document.
Redelegation of the domain for any usage requires justification via an
IETF Standards Action [RFC5226]."

IANA QUESTION --> What does "marking" mean in the context of DNS? Do
they want a TXT record added? IANA needs this instruction to be more clear.

IANA QUESTION --> Do the authors want the delegation pulled or left as
it is for a period of time?

The document also states "IANA is requested to mark the 192.88.99.0/24
prefix [RFC3068] as "deprecated", pointing to this document.
Redelegation of the domain for any usage requires justification via..."

IANA QUESTION --> Does this mean that RFC 5735 should be updated? If so,
how?

IANA QUESTION --> Also, the reverse domain name is not spelled out in
this paragraph as it is for the 2.0.0.2ip6.arpa domain. Why? Should it
be treated differently?
2011-06-10
05 David Harrington Request for Last Call review by TSVDIR is assigned to Dan Wing
2011-06-10
05 David Harrington Request for Last Call review by TSVDIR is assigned to Dan Wing
2011-06-06
05 Amy Vezza Last call sent
2011-06-06
05 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to
  Historic status'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Experience with the "Connection of IPv6 Domains via IPv4 Clouds
  (6to4)" IPv6 transitioning mechanism has shown that the mechanism is
  unsuitable for widespread deployment and use in the Internet.  This
  document requests that RFC3056 and the companion document "An Anycast
  Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/


No IPR declarations have been submitted directly on this I-D.


2011-06-06
05 Ron Bonica Placed on agenda for telechat - 2011-06-23
2011-06-06
05 Ron Bonica Intended Status has been changed to Informational from Proposed Standard
2011-06-06
05 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2011-06-06
05 Ron Bonica Ballot has been issued
2011-06-06
05 Ron Bonica Created "Approve" ballot
2011-06-06
05 Ron Bonica Last Call was requested
2011-06-06
05 (System) Ballot writeup text was added
2011-06-06
05 (System) Last call text was added
2011-06-06
05 Ron Bonica State changed to Last Call Requested from Publication Requested.
2011-06-06
04 (System) New version available: draft-ietf-v6ops-6to4-to-historic-04.txt
2011-06-02
05 Ron Bonica Ballot writeup text changed
2011-05-31
05 Cindy Morgan Area acronym has been changed to ops from gen
2011-05-27
05 Fred Baker Sent to IESG on 24 May 2011
2011-05-27
05 Fred Baker IETF state changed to Submitted to IESG for Publication from WG Document
2011-05-25
05 Amy Vezza
> (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does …
> (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

The document shepherd is Fred Baker. Yes, I believe that it is ready for IESG consideration.

> (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

This has had ample review and discussion. To make a long story short, the recommendation to consider 6to4 "historic" derives from observations reported in the IPv6 Operations Working Group in IETF 80, and also elsewhere. Multiple content providers have stated to the chairs that the unreliability of 6to4 service in the Internet prevents them from opening IPv6 service to general customers. Multiple broadband access providers have stated that 6to4 issues force them to take operational steps they had not planned on, with at best ambivalent results. Suggestions include disabling 6to4 access through their networks, providing 6to4 servers in their networks as a service, and other proposals. The general observation of v6ops is that if people are using 6to4, they should be doing so consciously as opposed to by accident due to a default setting, and should do so in ways consistent with draft-ietf-6to4-advisory. In general, 6to4 service is a diversion from native deployment, and is measurably unreliable.

> (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML?

No.

> (1.d) Does the Document Shepherd have any specific concerns or issues 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. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

There was considerable discussion, in v6ops and on other operational lists, regarding the proposals and their ramifications. The recommendations of the draft represent a consensus at the intersection of a variety of viewpoints.

> (1.e) 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?

Silence is perhaps the one problem we have not had in this discussion :-) There are disenting opinions on the future status of 6to4. It is believed that the concerns expressed are adequantly represented in the document and that the consensus opinion is in favor of publication.

> (1.f) 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 entered into the ID Tracker.)

We have had two people, Keith Moore and Jordi Palet Martinez, express strongly that they do not want to see 6to4 service summarily shut off, which was one of the variations on this proposal discussed. James Woodyatt conditioned support for the document on the inclusion of a global shut-off date comparable to the 6NET shut-off date. The recommendation does not include a shutdown proposal, and working group consensus would likely not support one.

> (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

The chairs have verified that the document meets the idnits and RFC Editor Style requirements. There are two addresses in the document that are specific to 6to4 as a service and as such cannot be replaced by generic addresses in the relevant documentation prefixes.

> (1.h) Has the document split its references into normative and informative?

Yes.

> 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

No. The discussion is entirely operational.

> (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document?

Yes. The IANA section requests that IANA take control of two prefixes, consistent with making the protocol historic, but not re-use them in the future without a consensus in the IETF.

> (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

There aren't any.

> (1.k) 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 transitioning mechanism has shown that the mechanism is
unsuitable for widespread deployment and use in the Internet. This
document requests that RFC3056 and the companion document "An Anycast
Prefix for 6to4 Relay Routers" RFC3068 be moved to historic status.

Working Group Summary

Discussion in the working group was voluminous and intense. Many additional proposals were considered, such as asking operators to shut down 6to4 service on a stated date via filtering or null routing, not doing so, asking vendors to remove code from products, and so on. This draft represents the intersection of those views - rough consensus in the best possible meaning of the phrase.

Document Quality

The document was reviewed by numerous people in wide reaches of the community including operators, vendors, and researchers.
2011-05-25
05 Amy Vezza Draft added in state Publication Requested
2011-05-25
05 Amy Vezza [Note]: 'The document shepherd is Fred Baker (fred@cisco.com). ' added
2011-05-24
03 (System) New version available: draft-ietf-v6ops-6to4-to-historic-03.txt
2011-05-02
02 (System) New version available: draft-ietf-v6ops-6to4-to-historic-02.txt
2011-04-27
01 (System) New version available: draft-ietf-v6ops-6to4-to-historic-01.txt
2011-04-05
00 (System) New version available: draft-ietf-v6ops-6to4-to-historic-00.txt