[142775] in North American Network Operators' Group
Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)
daemon@ATHENA.MIT.EDU (Joel Jaeggli)
Wed Jul 13 01:17:35 2011
From: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <20110713014139.92A4611CB398@drugs.dv.isc.org>
Date: Tue, 12 Jul 2011 22:16:20 -0700
To: Mark Andrews <marka@isc.org>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 12, 2011, at 6:41 PM, Mark Andrews wrote:
>=20
> In message <56E0FB8F-BB53-4DB0-829B-39DFBAB483E8@bogus.com>, Joel =
Jaeggli write
> s:
>>=20
>> On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
>>=20
>>> =3D20
>>> On Jul 12, 2011, at 8:43 AM, Cameron Byrne wrote:
>>> =3D20
>>>> On Tue, Jul 12, 2011 at 8:28 AM, Ronald Bonica =
<rbonica@juniper.net> =3D
>> wrote:
>>>>> Leo,
>>>>> =3D20
>>>>> Maybe we can fix this by:
>>>>> =3D20
>>>>> 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 =3D
>> working groups
>>>>> =3D20
>>>>> To some degree, we already do this in the IETF OPS area, but =
judging =3D
>> by your comments, we don't do it nearly enough.
>>>>> =3D20
>>>>> Comments?
>>>>> =3D20
>>>> =3D20
>>>> There may be an OPS area, but it is not listened to.
>>>> =3D20
>>>> Witness the latest debacle with the attempt at trying to make 6to4 =
=3D
>> historic.
>>>> =3D20
>>>> 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...)
>>>> =3D20
>>> Those are all REALLY bad ideas. Speaking as an operator, the best =3D
>> thing you
>>> can do to alleviate the problems with 6to4 is operate more, not less =
=3D
>> 6to4
>>> relays.
>>=20
>> Unless of course the large providers get their shared transition =
space =3D
>> in which case all 6to4 behind it will break in a really ugly way, =
pretty =3D
>> much exactly like in the mobile operator in question.=3D20
>=20
> And would deploying draft-andrews-v6ops-6to4-router-option-02.txt =
and/or
> adding router reachability tests have addressed this issue?
Neither of these approaches address existing cpe, and shared transtion =
space is justified on the basis of existing cpe...
We go into this with the internet we have not the one that we would like =
to have the later takes time.
>> The goal of 6to4 to historic was not to encourage the outcome =
described, =3D
>> it was to take having 6to4 as a default method of any kind off the =
table =3D
>> going into the future. If mature adults want to use it great, but =3D
>> conformance tests shouldn't require it, CPE shouldn't it on just =
because =3D
>> what they think they have a is a public IP with not filtering and =
hosts =3D
>> shouldn't use it unless told to do so..
>=20
> 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.
And that'll take some time while particularly for the CPE to age out.
> 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.
The interpretation of attitude is a matter of taste. When that authors =
of 3056 and 3068 come down in support of or opposed to the same draft =
there clearly some debate.=20
If we focus on what really would be in the best interests of the end =
user, it is a decline to zero in the unintentional use of 6to4 in cpe =
and operating systems. it is the removal of 6to4 from requirements where =
it presently exists, and it is the continued support of relays to =
support legacy devices.=20
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/
> 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
>>> 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 =
the
>>> 6to4 host won't attempt to resolve via IPv6, so, it doesn't really =3D=
>> help
>>> 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
>> thumb
>>>> 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
>> 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
