Message-ID: <548B3899.5080805@umn.edu>
Date: Fri, 12 Dec 2014 12:48:57 -0600
From: David Farmer <farmer@umn.edu>
Organization: University of Minnesota
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>,
    v6ops@ietf.org
References: <20141210185053.32277.17868.idtracker@ietfa.amsl.com>
 <5488977E.3010007@gmail.com>
In-Reply-To: <5488977E.3010007@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/J0dIfr9o4S6Dl_jeUx3jcIfvb3M
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
Precedence: list
Reply-To: David Farmer <farmer@umn.edu>

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.

On 12/10/14, 12:57 , Brian E Carpenter wrote:
> 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, internet-drafts@ietf.org wrote:
>> 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/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> 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
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


-- 
================================================
David Farmer               Email: farmer@umn.edu
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
================================================