[136319] in North American Network Operators' Group
Re: quietly....
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Feb 2 10:08:34 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <F31FBFC6-DC80-4B4F-BB9C-FE1D9956DA8E@muada.com>
Date: Wed, 2 Feb 2011 07:00:44 -0800
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 2, 2011, at 6:17 AM, Iljitsch van Beijnum wrote:
> On 2 feb 2011, at 14:10, Owen DeLong wrote:
>=20
>>> I didn't say they were necessarily good routers.
>=20
>> No, you said the router always knows better than the DHCP server. =
This is an example of a common case where
>> it does not.
>=20
> If someone turns their box into a router they can also turn it into a =
DHCP server. This is what happens with IPv4. The solution is to filter =
these packets from fake routers in the switches. So ask your switch =
vendor for that feature in IPv6.
>=20
Turns out that this is A LOT less common and when it does happen, it's =
easier to find and eliminate.
>> It really isn't. If the DHCP server on a subnet could override the =
rogue routers RA messages by policy, then, it would actually make it =
fairly trivial to address this issue.
>=20
> And who overrides the rogue DHCPv6 messages? Or is it turtles all the =
way down?
>=20
Turns out to be quite a bit easier to isolate and remove the rogue DHCP =
server.
Also turns out that there isn't a single-checkbox way to accidentally =
create a DHCP server, unlike a rogue RA.
>>> But there's so much wrong with DHCPv6 that trying to fix it is =
pretty much useless, we need to abandon DHCP and start from scratch. =
Good thing IPv6 works just fine without DHCPv6.
>=20
>> This is a clear example of the myopia in the IETF that has operators =
so frustrated.
>=20
> I can assure you that I'm quite alone within the IETF with that view.
>=20
Then you have had impressive success at blocking useful development for =
a lone individual.
> I'm not talking about the interaction between DHCPv6 and RAs here, =
just about how bad DHCPv6 is on its own terms. For instance, there's no =
client identifier or using MAC addresses to identify clients, this is =
now done with a DUID. Unfortunately, administrators have no way of =
knowing what DUID a given client is going to use so having a DHCPv6 =
server set up with information tailored to a specific client is really =
hard. There's also stateful and stateless DHCPv6, but it's the client =
that has to choose between them, while the server knows whether it's =
going to return stateful or stateless information. There's no prefix =
length in DHCPv6, so this needs to be learned from RAs. (Although it can =
be argued that because routers need to know this info anyway, having the =
prefix length there doesn't buy you anything.)
>=20
I agree that there is much that needs to be improved in DHCPv6. The lack =
of a default router, however, is the broken part that causes the most =
difficulty in modern operations.
> The problem with DHCP in general is that there is a continuous influx =
of new options but they all need to be encoded into a binary format =
inside a small packet. This info should be in an XML file on a HTTP =
server instead, rather than be overloaded into the connectivity =
bootstrapping. The problem with RA / DHCP is that RAs were built with =
some vague notion of what DHCP would do some day and then when DHCPv6 =
was developed half a decade later the evolving ideas didn't fit with the =
shape of the hole left in RAs anymore but that problem wasn't addressed =
at this time. Fixing that now (hopefully fixing it well, not doing =
stupid things like making DHCPv6 an IPv4 DHCP clone with all the IPv4 =
DHCP problems that we all suffer every day) means that we'll end up with =
three types of systems:
>=20
We can agree to disagree about that. While it's true that there is a =
large number of options and the DHCP packet needs to remain relatively =
small, the reality is that no site uses all of them. They large number =
of options represents a superset of the differing needs of various =
sites.
XML on HTTP is too much overhead for things a system needs to know at =
boot time to download its kernel.
Operationally, DHCPv4 is just fine and is meeting the needs today. =
There's no reason we shouldn't have
at least equivalent functionality in DHCPv6.
> - no DHCPv6
> - legacy DHCPv6
> - new DHCPv6
>=20
> Good luck trying to come up with a combination of RA and DHCP settings =
that make all three work well. Even without new DHCPv6, there's already =
12 ways to set up RAs and DHCP and only a few combinations produce =
useful results.
Yes... It really would be better if both SLAAC and DHCPv6 provided =
complete solutions and the operator could pick the single solution that =
worked best for them.
Unfortunately, instead of looking at how things are used in the real =
world, IETF pursued some sort of theoretical purity exercise and we have =
two half-protocols that can't possibly provide a complete solution in =
either one.
SLAAC fails because you can't get information about DNS, NTP, or =
anything other than a list of prefixes and a router that MIGHT actually =
be able to default-route your packets.
DHCP fails because you can't get a default router out of it.
Owen
