Re: IPv6 Deployment for the LAN

[Iljitsch van Beijnum <iljitsch () muada com>]

On 21 okt 2009, at 23:34, David W. Hankins wrote:

> There is a problem with the "Both RA and DHCPv6 Model" currently
> proposed by IETF iconoclasts.  Should RA fail, for any reason from
> router, system, software, network path, security, or user error,
> then the simplest networks imaginable (where hosts and mail/Intranet/
> work servers are all co-located on the same broadcast domain) will
> not be able to talk to one another,

Or the rest of the world.

Note however that it is very hard to get false negatives for RAs and  
even harder to get false positives. The only way I've had RAs fail in  
the real world was with multilayer switches that wouldn't let IPv6  
multicasts through because they couldn't do IGMP snooping for those.  
This affected RAs but also all other neighbor discovery, and would  
have affected DHCPv6, too. So in this situation IPv6 is completely  
dead in the water.

The good thing is that you don't get any false positives, where a host  
thinks there's a router somewhere but there's not actually a router  
there. This is because when a router stops being a router it will also  
stop sending RAs.

All of this works extremely well, I can't think of any instance where  
there is any trouble with RAs, except of course the problem of rogue  
routers advertising themselves. However, this is not really any  
different from the situation in IPv4 where rogue DHCP servers  
advertise stuff they shouldn't advertise.

> To work around this problem, some DHCPv6 software implementers have
> elected to temporarily apply a fixed /64 bit prefix to all applied
> addresses until a prefix length can be made available in-band through
> some means.

Why not simply fix the DHCPv6 protocol so it has a prefix length  
attribute?

DHCP'ers can complain about stateless autoconfig and RAs, but the  
simple truth is that DHCPv6 has problems that are unrelated to  
anything outside DHCPv6 that haven't been fixed in the half a decade  
that I've been paying attention to it.

> But it may complicate your designs if you
> are assigning /80's.

RFC 3513 says that all interface identifiers for addresses outside ::/ 
3 must be 64 bits in size. That doesn't work with a /80. So I'm not  
sure if using DHCPv6 with /80s will work on all systems.

> According to the release notes of ISC DHCP 4.1.0, ISC 'dhclient -6'
> compiles and runs on Mac OSX.  I don't actually own a Mac, so I have
> never used it myself, and our release notes even go into detail about
> the limitations of the current 'dhclient-script' for the Darwin
> platform (apparently their configuration system is somewhat opaque).

MacOS detects when interface go online and offline and does all kinds  
of stuff when that happens. For instance, you can't globally enable/ 
disable stateless autoconfig on MacOS, either.

Manually running a script when the interface status changes is a  
rather blunt way to interact with the system.

> > Does anyone know if Apple has plans to release a DHCPv6 client for  
> > Mac OS X?

> No...but I have heard plans of the exact opposite.

[...]

> When people at
> the microphone asked why Apple did not include a DHCPv6 client
> implementation, even a stateless one, I believe Bernard Aboba
> addressed the concern at the microphone saying, and I am paraphrasing
> from memory here, "We were told by the IETF that RA was all we would
> ever need, implementing DHCPv6 is optional, so RA is all we are
> doing."

I don't remember that. What I do remember is that Stuart Cheshire of  
Apple explained how he was unhappy that it was necessary to run a  
rather involved protocol (DHCPv6) for the relatively simple task of  
obtaining DNS resolver addresses.

> To summarize, RA+DHCPv6 implementers are posed with problems:

...which apparently some DHCPv6 people want to solve by ALWAYS running  
their chatty protocol that wastes a lot of bandwidth on wireless LANs  
until people give in and just run a DHCPv6 server just to get rid of  
the constant DHCP retransmissions that can't be stopped any other way  
because actually looking at the O/M bits is of course way too simple.

I hate this crap so much.