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

[Lorenzo Colitti <[e-mail]>]

But if you're a content provider, your stats would show that 6to4 traffic
is ~ 0.01% of total traffic, and therefore, you might well choose not to
optimize it (even to the extent of not having your own relays and using
third-party relays), as long as it works reasonably well.

On Tue, Nov 11, 2014 at 12:14 PM, James Woodyatt <[e-mail]> 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?
>
> Some obvious places to locate a 6to4 return relay spring immediately to
> mind, e.g. wherever there is a NAT64 gateway, e.g. in dual-stack customer
> edge routers with interfaces numbered with public IPv4 addresses.  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.
>
> 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?
>
> 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, <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
>
> --
> james woodyatt <[e-mail]>
> Nest Labs, Communications Engineering
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>