Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[Alexandru Petrescu <[e-mail]>]

After reading your text, let me share my experience:

I struggled hard to get a class C w/o NAT.  As hard as that was it was
still easier than obtaining native IPv6.  I wont struggle to get native
ipv6 too.

We use 6to4 on a frontend machine, and we use native IPv6 out of that
6to4 on several subnets behind, hence end machines are native ipv6 if i
can say so.

This is not much for content browsing, but for proudly ping6 an ipv6
node across the globe.

In the past year_s_ we have set up and down several kinds of 6-4 tunnels
manually, brokered, agreed.  We required vendors to include this and
that kind of tunnel in their sw/hw.

We have moved physically and we will move again soon.  We are guaranteed
continuity of this class C no nat, and yet still no IPv6 tunnel up and
downs.  The only thing that was stable during this time was 6to4, and
improved support appeared more and more.

I would also add as information only, that the environment where this
happens, and where i have no control, is where an ethernet seting with
many office-type users, where dhcp is not used, if you can imagine that.
There are many reasons technical and human for that being so.  And
manual assignment (vs dhcp) is not historical - its there in every pc.

Alex

Le 26/07/2011 16:14, Tim Chown a écrit :
>
> On 25 Jul 2011, at 15:30, Ronald Bonica wrote:
>>
>> Please post your views on this course of action by August 8, 2011.
>
> Some observations.
>
> Our own users made use of 6to4 maybe 8+ years ago, and at the time
> it was handy to have.  Today though we're not aware of any of our
> users running 6to4 intentionally. We have IPv6 native on site, and
> anyone who wants home IPv6 connectivity either goes to an ISP that
> provides it, e.g. A&A in the UK, or they use a tunnel broker. Brokers
> have the additional benefit of working through NATs and with dynamic
> IPv4 endpoints.
>
> Our site sees about 1-2% of all inbound traffic being IPv6, and of
> that less than 1% is 6to4, and this is only likely to fall further
> with rfc3484-bis. What 6to4 we do see is probably reasonably robust
> in that our return path uses the JANET-provided 6to4 relay.
>
> Most operating systems either already, or before long will, support
> rfc3484-bis, which means hosts should use IPv4 in preference to 6to4
> where both are available.  To choose to use 6to4, the user would need
> to consciously change their 3484 policy table, assuming their OS
> supports that (Linux and Windows do, MacOS X Lion appears not to).
>
> Geoff Huston has presented data at IETF80 showing 6to4 brokenness
> and performance. We now have 'Happy Eyeballs Lite' implemented in
> Chrome and (I believe, not tested it yet) Firefox, which means the
> browser can adapt to broken IPv6, whether caused by 6to4 or other
> factors.
>
> The 6to4-advisory draft suggests off-by-default, which I agree with,
> and use of relays to improve user experience. The problem is we can't
> expect every site/ISP to run a relay (or multi-address with 6to4) so
> there will inevitably always be problems with the 3068 mode of 6to4.
>
> We measured rogue RAs over a two year period on our wireless
> network. About 60% of the time at least one host was emitting a
> rogue 6to4-based RA. While these were mitigated by ramond, it would
> be good to see vendors fix this; it's not just MS ICS.  Happy
> Eyeballs is a mitigation for such rogue RAs also.
>
> So in summary, in practice 3484-bis and the 6to4-advisory
> off-by-default will further reduce what little use there is of 6to4
> now, and happy eyeballs will mitigate any remaining instances of its
> use that are bad. So whether 6to4 is tagged Historic or not, it
> should be causing significantly less harm.
>
> Tim _______________________________________________ Ietf mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/ietf