In message <EMEW3|9c8bf9e7fa0e59322f84c8ec6df2b8b9n62HAg03tjc|ecs.soton.ac.uk|0
4B2CF82-78EC-4A2B-A681-7710E3EFCDBE(_at_)ecs(_dot_)soton(_dot_)ac(_dot_)uk>,
Tim Chown writes:
On 3 Jul 2011, at 12:10, Gert Doering wrote:
On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote:
There's clearly a lack of consensus to support it.
There's two very vocal persons opposing it and a much larger number of
people that support it, but have not the time to write a similarily
large amount of e-mails. For me, this is enough for "rough consensus".
(And I second everything Lorenzo, Randy and Cameron said - there's
theoretical possibilities, and real world. 6to4 fails the real-world
test. Get over it, instead of attacking people that run real-world
networks for the decisions they need to do to keep the networks running
in a world without enough IPv4 addresses).
I'm with Gert, Lorenzo, Randy and others here.
It seemed that both the -advisory and -historic drafts had strong support in
v6ops, which isn't just any WG, it's the WG that anyone with a vested interes
t in IPv6 deployment takes part. Thus its view on IPv6 deployment practices
should be given due regard. The opposition on the IETF list seemed to be a v
ocal minority, and of course one person seemed to post a disproportionate num
ber of replies.
The problems with 6to4 (20% minimum failure rate, and poor performance when i
t does connect) are well documented and have led to various 'counter measures
' from the IETF, including:
a) 6to4 off by default, as per 6to4-advisory
b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely implemente
d already)
c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a simp
listic version is already in Chrome)
Those measures indicate how bad a problem 6to4 creates.
No. The 20% connect failure rate shows how bad AUTOMATIC 6to4 is.
It show NOTHING about how bad 6to4 itself is. As for longer RTT
that is something people accept as part of using 6to4. I know I
accept that they are there for the trans Pacific tunnel I use.
As for high failure rates. EDNS (RFC 2671) had/has a similar or
higher failure rates with any UDP packets that are bigger that 512
bytes or UDP packets that get fragmented or packets that have a OPT
record in the additional section or have DO (RFC 3225) set in the
OPT record. Firewalls are a pain in the proverbial but we don't
stop attempting to use EDNS because they are there. Nameservers
tailor their queries to to work around firewalls (happy eyeballs)
and log that they needed to use the workarounds.
If we're going to th
e trouble of coming up with all these measures, there seems to be a good case
for 6to4 to Historic, which would be a steer to implementors to no longer in
clude 6to4 support at all. I do agree however that the most important point
is publishing the -advisory text.
As for the counter measures, some of them need to be there independently
of 6to4. Google Chome was the only brower that could reach
www.ietf.org in a timely manner from any dual stack client connecting
via Hurricane Electric for half of last week. The noc @HE responded
to the issue within 1/2 a hour of it being raised via email by
raising a trouble ticket with AT&T. It still took 2-3 days for the
problem to be fixed.
As a provider of a (not large) enterprise, I know that a fraction of 1% of co
nnections to our site suffer a 10 second+ delay to a dual-stack web site wher
e they suffer no delay to an IPv4-only one.
Which for the most part wouldn't be there if 6to4 required explicit
configuration.
There's no way to know for sure
how much of that 'IPv6 brokenness' is 6to4, but measures (a), (b), and (c) sh
ould minimise that figure. Having said that, less than 1% of users who conne
ct to our site over IPv6 use 6to4, so we wouldn't be aggrieved to see it disa
ppear in terms of loss of users, as those users could almost certainly still
reach us over IPv4. Our own users who want IPv6 connectivity when offsite us
e tunnel brokers, which provide a much better (and more predictable) service,
one that also works from behind a NAT, which in the reality of home, hotel,
and other hotspot networks is quite important.
As for operators 'fixing' 6to4, well, I'd rather see operators invest that ef
fort in deploying IPv6, rather than making 6to4 work better, for some value o
f 'better'.
The fixes for 6to4 are deploying suitable sized 6to4 relay boxes
and removing protocol 41 filters once the isp has some IPv6
connectivity. The time and effort required to do this is minimal
compared to the time and effort required to deploy IPv6 to all of
its customers.
Remember you don't need to bill for this as the billing is already
taken care of with IPv4. You don't need to do address assignments
as they are taken care of with IPv4.
Tim
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf