On Jul 12, 2011, at 10:59 PM, Mark Andrews wrote:
I didn't claim it would work with existing CPE equipment. Declaring 6to4 historic won't work with existing CPE equipment either.
If the hosts behind it stop using 2002::/16 addresses as a product of a software update which seems rather more likely (also there some evidence for that), it will. that said yes one assumption is that you have to continue to support it. <snip>
It is really hard to justify the expansion and deployment of new relays = when in fact tunneled traffic can be observed to be on the decline = (possibly because devices particularly hosts that do receive regular = updates receive tweaks to their address selection algorithm). = http://asert.arbornetworks.com/2011/04/six-months-six-providers-and-ipv6/
Which may or may not be a short term dip.
correlation is not causation but... http://arstechnica.com/apple/news/2010/11/apple-fixes-broken-ipv6-by-breakin...
We are yet to see much in the way of IPv6 only content. When that appears, which it will, the tunneled traffic will go up unless ISPs have deployed native IPv6 to all customers. Are you willing to bet on which will happen first?
I'm willing to bet that subpar experience due to auto-tunneling is considered a liability for content providers.
This whole area is in a state of flux.
Blocking AAAA over IPv4 transport is just silly. It's just as likely = =3D that your AAAA record is destined for an end-host that has native IPv6 =3D connectivity with an intermediate resolver that desn't have IPv6 as it is that =3D you're sending that to a 6to4 host. Further, there's no reason to believe =
What would have been much better would have been to encourage CPE vendors to release images which address some of the known issues. Just adding a check box saying "enable 6to4" and for ISP to send out email to say "check your router vendor web site for fixed images". The better fix would be to get them to also add support for draft-andrews-v6ops-6to4-router-option-02.txt which greys out the checkbox when 0.0.0.0 is sent as a response to the option. =20 Remember operators are in the position to alleviate lots of the 6to4 issues themselves. =20 the
6to4 host won't attempt to resolve via IPv6, so, it doesn't really =3D=
anyway. =3D20
Real network operators have a relatively low BS threshold, they = have customers to support and businesses to run, and they don't have =3D
wrestle these people who don't actually have any skin in the game. =3D20 I agree, but, it's not hard to run 6to4 relays and running them does = =3D much more to alleviate the problems with 6to4 than anything you proposed above. Indeed, what you proposed above will likely create more =3D customer issues rather than reduce them. =3D20 Owen =3D20 Cameron =3D20 =3D20 > Ron > =3D20 > =3D20 > -----Original Message----- > From: Leo Bicknell [mailto:bicknell@ufp.org] > Sent: Monday, July 11, 2011 3:35 PM > To: nanog@nanog.org > Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 = =3D broken?) > =3D20 > In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, =3D Jeroen Massar wrote: >> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing =3D
help thumb lists
>> and participate there, just like a couple of folks from NANOG are = =3D already doing. > =3D20 > The way the IETF and the operator community interact is badly =3D broken. > =3D20 > The IETF does not want operators in many steps of the process. If = =3D you try to bring up operational concerns in early protocol = development =3D for example you'll often get a "we'll look at that later" response, =3D=
which in many cases is right. Sometimes you just have to play with =3D=
something before you worry about the operational details. It also = does =3D not help that many operational types are not hardcore programmers, = and =3D can't play in the sandbox during the major development cycles.
> =3D20 > =3D20 > =3D20 > =3D20 =3D20 =3D20 =3D20 =20 =20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org =20
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org