Anybody can participate in the IETF (Was: Why is IPv6 broken?)

Wed Jul 13 03:48:29 UTC 2011

On Jul 12, 2011 6:42 PM, "Mark Andrews" <marka at isc.org> wrote:
>
>
> In message <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8 at 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 <rbonica at 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:bicknell at ufp.org]
> > >>> Sent: Monday, July 11, 2011 3:35 PM
> > >>> To: nanog at 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: marka at isc.org
>