[141968] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Jun 15 01:38:45 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <60B7F9A9-17FC-473F-9FD8-E118F52514FE@muada.com>
Date: Tue, 14 Jun 2011 22:33:09 -0700
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 14, 2011, at 3:44 PM, Iljitsch van Beijnum wrote:
> On 15 jun 2011, at 0:05, Owen DeLong wrote:
>=20
>> Yes, the right solution would be to at least separate the VLANs and =
clean up this
>> mess. However, due to software packages that need to talk to each =
other over
>> common local broadcast across that boundary, this isn't possible in =
this particular
>> organization (don't get me started on the bad software, but, that's =
what there is.)
>=20
> Strange that you don't apply the logic of "the existing software is =
what there is" to the code deep inside hundreds of millions of hosts, =
but rather to obscure stuff that presumably hardly anyone uses.
>=20
> If changing this software is so hard, what these people need is some =
filtering switches so the application multicasts get forwarded but the =
IP provisioning multicasts don't. No standards action required.
>=20
> BTW, does this broken software run over IPv6, anyway?
No, but, it require the v4 stack on the hosts to be on the same link, =
which means that the v6 stack will also be on the same link.
There are less broken scenarios, too.
Bottom line, I expect it's easier to get cooperation from OS vendors and =
BIOS vendors to make changes
because experience has shown that they are more willing to do so than =
vertical software vendors.
As such, yes, I'd like to see some harmless extensions added to DHCPv6 =
that solve some real world
problems.
Owen
