ietf
[Top] [All Lists]

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

2011-07-27 18:33:17
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
Ietf(_at_)ietf(_dot_)org https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>