Re: The stupidity of trying to "fix" DHCPv6

[Owen DeLong <owen () delong com>]

Sent from my iPad

On Jun 10, 2011, at 10:13, Iljitsch van Beijnum <iljitsch () muada com> wrote:

> On 10 jun 2011, at 16:47, Leo Bicknell wrote:
>
> > > So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes.
>
> > in DHCPv6 it was decided to not implment a field for the
> > default gateway or subnet mask, under the logic that the former was
> > learned via RA's, and the latter was always a /64.  While it's not
> > quite as trivial as adding those two fields, it's not that much
> > more complex.  The right behavior for a host that comes up and sees
> > no RA's needs to be documented.
>
> Don't you realize that this doesn't solve anything?

Actually, it does. It doesn't solve the problem you choose to argue about below. That problem is addressed by RA Guard. 
However, it does solve a different problem.

Some administrators want DHCP to be a complete solution and do not want to use RA at all, whether from a legitimate 
router or otherwise.

There are situations, for example, where the administrator does not want all hosts in a broadcast domain to receive the 
same set of prefixes and/or the same set of routers. This can be achieved by using different parameters based on the 
system identifier in the DHCP configuration. It cannot be achieved using RA.

> The whole point of stateless autoconfig and DHCP is to allow a host that arrives without any prior knowledge about 
> the network to be configured without human intervention so it can communicate over the network.

Sure, but...

> So we must assume a host with no prior configuration. All currently existing IPv6 hosts that I'm aware of have 
> stateless autoconfig enabled by default (save for some *X distros that assume the system will be some kind of server).
>
> So if you put such a host with an updated DHCPv6 implementation in a network with rogue RAs, they will autoconfigure 
> addresses in the advertised prefixes exactly the same as today. Like I said before: removing the correct information 
> from RAs does nothing to get rid of the incorrect information in RAs.

Eliminating rogue RAs is not the problem being described. That problem is solved through RA-Guard. The problem being 
described is the desire to be able to configure a host from zero to functionally on the internet using DHCP without 
RAs. I think everyone understands that you don't want to do so. That's fine. However, adding the functionality to 
DHCPv6 doesn't require you to use it. Making it available for operators that want to use it is not a bad thing.

> Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from 
> RAs. At least that solves the problem. However, that solution still has two issues:
>
> 1. No longer the fait sharing that comes from RA-learned gateway addresses
> 2. Old and new hosts may use different gateways on the same network

In some situations, this fate (it's fate, not fait, btw) sharing is not desired. In some situations,
the use of VRRP is a more useful alternative.

> So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that 
> contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority.
That would be a fine partial solution. However, it is desirable (IMHO) to provide for a more generic DHCPv6 option that 
allows one to convey routing information so that DHCPv6 could be used to convey a predetermined static routing table of 
arbitrary complexity.

(yes, this would usually be a single default route, but, there are circumstances where it is
desirable for a host to have additional static routes).

> This way, if there are no rogue RAs the behavior is the same for unupdated and updated hosts. If there are rogue RAs, 
> the updated hosts ignore them. If system administrators screw up and the DHCPv6 info doesn't match the actual 
> routers, everything still works except that there is no rogue RA protection.
>
> This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not 
> only a bad idea, but an exercise in futility because of the large number of "legacy IPv6" hosts that need RAs to 
> function and won't go away anytime soon.

I think it's a fine solution as far as it goes and a good part of a complete solution. However,
documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. As it currently 
stands, some hosts which are DHCPv6 capable will not attempt to query DHCP until they receive an RA with the M bit set.

Yes, there will be an issue with legacy IPv6 hosts needing to catch up with the protocol change for some time. However, 
this has been the case with many changes over time in IPv4 as well. Look at the transition from BootP to DHCP. 
Administrators are actually capable of adapting to or in some cases influencing the level of required hardware/software 
performance of things that connect to their network if given the tools to do so.

Owen