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

James,

On 12/11/2014 11:14, James Woodyatt wrote:
> My comment is not an objection to this draft. I am generally supportive of
> this draft.
> 
> I have only one comment, which I suppose *might* rise to the level of a
> "complaint" if it were shared by a significant fraction of other
> participants, which is simply this: we are retaining RFC 3056 on the
> Standards Track, and we are considering an RFC that advises content
> providers that supporting 6to4 users with return relays to 2002::/16, maybe
> even new ones that aren't currently there, is consistent with Best Current
> Practice, but we are not advising anyone else that maybe new deployment of
> return relays to 2002::/16 is an idea worth reviewing. Why not?

We are not rescinding RFC 6343, which is Informational, and does
suggest some cases where an operator could usefully run a return relay.
But that is a bit different from advocating new deployments in a BCP...

> Some obvious places to locate a 6to4 return relay spring immediately to
> mind, e.g. wherever there is a NAT64 gateway, 

I tried and tried and couldn't see the direct relevance of a NAT64.
But there is a use case, which is at the boundary between an IPv6-only
network and the IPv4 Internet (which is coincidentally the same place
where you put a NAT64).

> e.g. in dual-stack customer
> edge routers with interfaces numbered with public IPv4 addresses.

That is exactly the classical case described in RFC 3056, which we
are not deprecating.

> Anyplace
> where an IPv6-only host might be reachable from a host using RFC 3056 (and
> not RFC 3068) to get IPv6 packets into the IPv6-only world from some
> benighted place where it's the 21st century and still IPv4 is the only
> service available to them.

Well, yes, the requirement is that there is a route to 2002::/16
that reaches a working return relay. That's why the draft now says
  "Internet service
   providers SHOULD announce the IPv6 prefix 2002::/16 if and only if it
   leads to a correctly operating return relay as described in RFC 6343."

Is it really the job of this draft to suggest where that relay should be?

There is a weakness in RFC 6343. In Section 4.3. "Consumer ISPs, and
Enterprise Networks, That Do Support IPv6" it implicitly assumes that
these are dual-stack networks. It would be better if it also offered
guidelines for IPv6-only networks. There is indeed a case for such
networks to operate a 2002::/16 return relay. But nobody made that point
while 6343 was being developed...

> 
> If I were a content provider (oh wait! I work for one now!), then I might
> notice the fact this document singles me out for special attention and
> leaves unmolested all the other places where broken 6to4 return relay
> service might be just as noticeable to legitimate users of RFC 3056 who are
> using manually configured forward relay services. I might think to myself:
> hey, why do I need a 6to4 return relay in my network when nobody else has
> one, and IETF can't even be bothered to advise them that it's even worth
> thinking about?

Content providers presumably have a strong interest in not losing client
sessions. That's the reason they have their own section in 6343. But the
current draft only mentions them once, and the following sentence is a
rather stronger recommendation to ISPs. So I don't quite get your point.

   Brian

> 
> As I said above, this is not actually a complaint. It's just a comment, and
> if nobody pipes up with a "me too" observation, then that's fine. I don't
> have any significant objection to publishing this revision of the draft now.
> 
> 
> On Mon, Nov 10, 2014 at 7:40 PM, <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 Connection of IPv6 Domains via IPv4
>> Clouds (6to4)
>>         Authors         : Ole Troan
>>                           Brian Carpenter
>>         Filename        : draft-ietf-v6ops-6to4-to-historic-07.txt
>>         Pages           : 7
>>         Date            : 2014-11-10
>>
>> Abstract:
>>    Experience with the "Connection of IPv6 Domains via IPv4 Clouds
>>    (6to4)" IPv6 transition mechanism has shown that the mechanism is
>>    unsuitable for widespread deployment and use in the Internet,
>>    especially in its anycast mode.  This document requests that RFC
>>    3068, "An Anycast Prefix for 6to4 Relay Routers", be made obsolete
>>    and moved to historic status.  It also recommends that future
>>    products should not support 6to4 anycast and that existing
>>    deployments should be reviewed.
>>
>>
>> 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-07
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-07
>>
>>
>> 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/
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops