[142772] 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 00:48:35 2011
From: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <AF9B0256-C69A-4CA0-B92E-74DF998CE78D@delong.com>
Date: Tue, 12 Jul 2011 21:48:19 -0700
To: Owen DeLong <owen@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 12, 2011, at 7:20 PM, Owen DeLong wrote:
>=20
> On Jul 12, 2011, at 2:21 PM, Joel Jaeggli wrote:
>=20
>>=20
>> On Jul 12, 2011, at 12:53 PM, Owen DeLong wrote:
>>=20
>>>=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@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.
>>=20
>> 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
>>=20
>=20
> Actually, if those same providers run 6to4 gateways/routers on their =
networks
> in that shared transition space with public IPv6 addresses on the =
exterior,
> it would not break at all.
arin 2011-5 specfically cites numbering cpe in space as the =
justification for deployment.
the cpe therefore have to be natted and you are implying that you'll be =
natting the 6to4, overall I'd put that in the less desirable category as =
far as violating expectations go...
> As I said, the resolution to the 6to4 problems described is to run =
MORE, not
> less 6to4 gateways.
Are you advocating draft-kuarsingh-v6ops-6to4-provider-managed-tunnel?
=
http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tun=
nel-02
>=20
>> 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..
>>=20
>=20
> I have no problem with saying 6to4 should not be enabled by default. =
However,
> that doesn't change the fact that the best way to resolve things given =
current shipping
> software and hardware is to deploy 6to4 gateways in the appropriate =
places.
and we have http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory-02
The fact of the matter is more 6to4 relays is only an anodyne as is =
rejiggering the address selection priority, the pain may go down it =
won't go away.
> Owen
>=20
>>> 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@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
>=20
>=20
