In message <EMEW3|9c8bf9e7fa0e59322f84c8ec6df2b8b9n62HAg03tjc|ecs.soton.ac.uk|0 4B2CF82-78EC-4A2B-A681-7710E3EFCDBE@xxxxxxxxxxxxxxx>, 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@xxxxxxxx > 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@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf