On Jul 12, 2011 6:42 PM, "Mark Andrews" <ma...@isc.org> wrote: > > > In message <56e0fb8f-bb53-4db0-829b-39dfbab48...@bogus.com>, Joel Jaeggli write > s: > > > > On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote: > > > > >=20 > > > On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote: > > >=20 > > >> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica <rbon...@juniper.net> = > > wrote: > > >>> Leo, > > >>>=20 > > >>> Maybe we can fix this by: > > >>>=20 > > >>> a) bringing together larger groups of clueful operators in the IETF > > >>> b) deciding which issues interest them > > >>> c) showing up and being vocal as a group in protocol developing = > > working groups > > >>>=20 > > >>> To some degree, we already do this in the IETF OPS area, but judging = > > by your comments, we don't do it nearly enough. > > >>>=20 > > >>> Comments? > > >>>=20 > > >>=20 > > >> There may be an OPS area, but it is not listened to. > > >>=20 > > >> Witness the latest debacle with the attempt at trying to make 6to4 = > > historic. > > >>=20 > > >> Various "non-practicing entities" were able to derail what network > > >> operators largely supported. Since the IETF failed to make progress > > >> operators will do other things to stop 6to4 ( i have heard no AAAA > > >> over IPv4 transport, blackhole 6to4 anycast, decom relay routers...) > > >>=20 > > > Those are all REALLY bad ideas. Speaking as an operator, the best = > > thing you > > > can do to alleviate the problems with 6to4 is operate more, not less = > > 6to4 > > > relays. > > > > Unless of course the large providers get their shared transition space = > > in which case all 6to4 behind it will break in a really ugly way, pretty = > > much exactly like in the mobile operator in question.=20 > > And would deploying draft-andrews-v6ops-6to4-router-option-02.txt and/or > adding router reachability tests have addressed this issue? > > > The goal of 6to4 to historic was not to encourage the outcome described, = > > it was to take having 6to4 as a default method of any kind off the table = > > going into the future. If mature adults want to use it great, but = > > conformance tests shouldn't require it, CPE shouldn't it on just because = > > what they think they have a is a public IP with not filtering and hosts = > > shouldn't use it unless told to do so.. > > But that is *not* what the draft did. Making the protocol historic > did LOTS more than that. I think there was universal consensus > that 6to4 should be off by default. > > There was this nuke 6to4 from orbit attitude which did nothing to > help with already deployed/shipped boxes. 6to4 historic is actually > harmful for dealing with the existing problems as it tells vendors > not to include 6to4 support in future products which means operators > won't have boxes with fixes to other problems to alleviate the > problems cause but the currently deployed customer boxes. > > 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. > > Remember operators are in the position to alleviate lots of the > 6to4 issues themselves. >
But they will not. If there is not a revenue forecast, there is no project. That said, CGN is moving forward as a "keep the lights on" initiative.... as is real native v6. I don't care to rehash this yet again with no progress. Cb. > > > Blocking AAAA over IPv4 transport is just silly. It's just as likely = > > that your > > > AAAA record is destined for an end-host that has native IPv6 = > > connectivity > > > with an intermediate resolver that desn't have IPv6 as it is that = > > you're > > > sending that to a 6to4 host. Further, there's no reason to believe the > > > 6to4 host won't attempt to resolve via IPv6, so, it doesn't really = > > help > > > anyway. > > >=20 > > >> Real network operators have a relatively low BS threshold, they have > > >> customers to support and businesses to run, and they don't have = > > thumb > > >> wrestle these people who don't actually have any skin in the game. > > >>=20 > > > I agree, but, it's not hard to run 6to4 relays and running them does = > > much > > > more to alleviate the problems with 6to4 than anything you proposed > > > above. Indeed, what you proposed above will likely create more = > > customer > > > issues rather than reduce them. > > >=20 > > > Owen > > >=20 > > >> Cameron > > >>=20 > > >>=20 > > >>> Ron > > >>>=20 > > >>>=20 > > >>> -----Original Message----- > > >>> From: Leo Bicknell [mailto:bickn...@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 = > > broken?) > > >>>=20 > > >>> In a message written on Sun, Jul 10, 2011 at 06:16:09PM +0200, = > > Jeroen Massar wrote: > > >>>> Ehmmmm ANYBODY, including you, can sign up to the IETF mailing = > > lists > > >>>> and participate there, just like a couple of folks from NANOG are = > > already doing. > > >>>=20 > > >>> The way the IETF and the operator community interact is badly = > > broken. > > >>>=20 > > >>> The IETF does not want operators in many steps of the process. If = > > you try to bring up operational concerns in early protocol development = > > for example you'll often get a "we'll look at that later" response, = > > which in many cases is right. Sometimes you just have to play with = > > something before you worry about the operational details. It also does = > > not help that many operational types are not hardcore programmers, and = > > can't play in the sandbox during the major development cycles. > > >>>=20 > > >>>=20 > > >>>=20 > > >>>=20 > > >=20 > > >=20 > > >=20 > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >