Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt

From: [email-masked]
Date: Wed, 10 Dec 2014 10:50:53 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : Deprecating Anycast Prefix for 6to4 Relay Routers
        Authors         : Ole Troan
                          Brian Carpenter
	Filename        : draft-ietf-v6ops-6to4-to-historic-09.txt
	Pages           : 8
	Date            : 2014-12-10

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Dec 2014 07:57:02 +1300

Hi,

This version has been updated after re-reading the long thread generated
by the WGLC. The major change reflects the fact that there was
obviously no consensus for the recommendation to filter the anycast
route. The other changes reflect other points that came up in the
discussion.

One extra comment. With the removal of the filtering recommendation,
there is (the editor believes) no substantive change to the guidelines
in RFC 6343, so "Updates: 6343" has been removed.

Regards
   Brian Carpenter

On 11/12/2014 07:50, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Keith Moore <[email-masked]>
Date: Thu, 11 Dec 2014 10:42:54 -0500

Mumble.  I support the deprecation of 192.88.99.1 as a means to find 
6to4 relays.   But this document still contains so many inaccurate and 
misleading statements beyond that, including perhaps some statements 
that were not present in earlier versions (though I haven't taken the 
time to check yet), that I don't believe it should be published in its 
current form. Again, this is a document quality issue, not an issue with 
the basic underlying recommendation.

Most of the problems with this document are things that I have already 
mentioned in connection with earlier versions of this document.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Dec 2014 08:23:12 +1300

Keith, please, you need to be specific about what you think is
inaccurate or misleading, line by line, in this version. There's
nothing we can do with a general criticism like that.

We have made numerous changes, some of them in response to your
comments, but of course in some cases your comments were at
variance with other peoples' comments. Of course, there were a
lot of messages, many of them completely orthogonal to the text
of the draft, so we may well have missed some of the relevant ones.

Regards
   Brian

On 12/12/2014 04:42, Keith Moore wrote:
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: David Farmer <[email-masked]>
Date: Fri, 12 Dec 2014 12:48:57 -0600

I support the changes made in this version, in particular the removal of 
the general recommendation to filter 192.88.99.0/24.  However, people do 
filter 6to4 and the route for 192.88.99.0/24, and I don't think the 
issue can and should be ignored.  I would prefer some discussion of when 
it is and is not appropriate to filter the route for 192.88.99.0/24.

Filtering of 6to4 or even 192.88.99.0/24 as part of the deprecation of 
anycast 6to4 relays within Internet in general is most definitely NOT 
appropriate.  However, the deprecation of anycast 6to4 relays combined 
with local security consideration seems like an appropriate reason to 
filter the route for 192.88.99.0/24 within an administrative domain.  If 
such filtering is implemented, it is much preferred that native IPv6 is 
provided within the administrative domain in question and the security 
policy not impact another administrative domain's access to an anycast 
6to4 relay.

Personally, I'd prefer a more detailed discussion as outlined in the 
paragraph above. However, I would find adding a general reference to RFC 
7123 or possibly a more specific reference to Section 3.4 of RFC 7123 in 
the security considerations section of the draft an acceptable alternative.

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
================================================