Subject: [v6ops] Protocol Action: 'Deprecating Anycast Prefix for 6to4 Relay Routers' to Best Current Practice (draft-ietf-v6ops-6to4-to-historic-11.txt)

From: The IESG <[email-masked]>
Date: Mon, 09 Mar 2015 09:33:30 -0700

The IESG has approved the following document:
- 'Deprecating Anycast Prefix for 6to4 Relay Routers'
  (draft-ietf-v6ops-6to4-to-historic-11.txt) as Best Current Practice

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Joel Jaeggli and Benoit Claise.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

 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. 

Personnel

Fred Baker is the document shepherd.

RFC Editor Note

minor tweaks to be processed at editing time.

As previously suggested:

OLD:

   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".

NEW:

   This document
   therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay
   Routers", and RFC 6732, "6to4 Provider Managed Tunnels", be made
   obsolete and moved to historic status.

In response to the IANA review:

OLD:

   Instead, IANA is requested to mark the 192.88.99.0/24
   prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay
   Anycast)", pointing to the present document.

NEW:

   Instead, IANA is requested to mark the 192.88.99.0/24
   prefix originally defined by [RFC3068] as "Deprecated (6to4 Relay
   Anycast)", pointing to the present document. The Boolean values
   for the address block 192.88.99.0/24 will all be removed.

---

From: David Farmer <[email-masked]>
Date: Mon, 09 Mar 2015 16:01:15 -0500

>    (draft-ietf-v6ops-6to4-to-historic-11.txt) as Best Current Practice

Good News!

...
>     for the address block 192.88.99.0/24 will all be removed.

What is the rationale for removing the Boolean values?  Wouldn't the 
current values apply until the prefix is repurposed or removed by future 
protocol action?

I'm not sure I really care, but I don't understand what is served by 
removing the current values.  I'm not sure what purpose the Boolean 
values really serve, but the current values seem the most appropriate 
until the prefix is permanently removed or repurposed.

Thanks.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Mar 2015 15:28:35 +1300

On 10/03/2015 10:01, David Farmer wrote:
> What is the rationale for removing the Boolean values?  Wouldn't the current values apply until the prefix is repurposed or
> removed by future protocol action?
> 
> I'm not sure I really care, but I don't understand what is served by removing the current values.  I'm not sure what purpose the
> Boolean values really serve, but the current values seem the most appropriate until the prefix is permanently removed or
> repurposed.

Well, IANA wanted this change. I sympathise because it means they never have
to revisit this in the future.

    Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 10 Mar 2015 00:23:58 -0500

>> On Mar 9, 2015, at 21:28, Brian E Carpenter <[email-masked]> wrote:
>> 

Why would IANA have to revisit it?  Why couldn't the Boolean values be left forever for historic reference or at least until it is reassigned or removed by future protocol action, which by definition IANA would have to revisit it anyway.

Also, the IANA review says; "and added a Termination Date upon approval of this draft."  Does than mean the termination date in the IPv4 special-purpose registry will be the publication date of this document?  Is that what we want?  That doesn't seem to jive with the general feel of the rest of the recommendations in the document. In my opinion a Termination Date, two, three, or five years later would be much more in line with the feel of the rest of the document, that is why I brought it up months ago, back around -08.  I let it go thinking there wouldn't be a termination date, I guess my mistake.

My suggestion would be, leave the Boolean values as-is forever, or until reassigned, with a termination date some years after publication of this document, personally I'd pick three years, but anything more that a year out would be just fine.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 10 Mar 2015 11:25:36 +0000

On 10/03/2015 05:23, David Farmer wrote:
> My suggestion would be, leave the Boolean values as-is forever, or until
> reassigned, with a termination date some years after publication of this
> document, personally I'd pick three years, but anything more that a year
> out would be just fine.

I'm pretty good with IANA's suggestion here and don't see any value in
delaying publication of this draft any further.

Nick

---

From: David Farmer <[email-masked]>
Date: Tue, 10 Mar 2015 13:31:13 -0500

> delaying publication of this draft any further.

I certainly don't want to hold things up, I've said my piece and will 
leave it at that.