dhcpcd-discuss

On Mon, 06 Jun 2016 23:26:41 +0100
Roy Marples <roy@xxxxxxxxxxxx> wrote:

> On Monday 06 June 2016 17:54:18 Neal P. Murphy wrote:
> > > Good question!
> > > The RFC doesn't not say that it's an option to request a specific prefix
> > > size, the guidance is it's more of a hint.
> > > As such, dhcpcd will just use whatever the server gives and split it as
> > > best it can.
> > 
> > Analogy:
> > 
> >     Me: My friends and I are a bit peckish. One jumbo pizza with everything
> > on it, please. [Time passes]
> >     Server: OK, who gets the personal-sized pizza with everything on it?
> > 
> > Not what was expected. Similar to asking for a /60 and getting a /64. From
> > the user's perspective, what to do? Quit in disgust? Keep trying every five
> > minutes forever? I dunno.
> 
> Nice analogy :)
> 
> > And you're right. The RFCs (3315, 6603, 7550) do not address the problem
> > directly. I only fairly quickly perused them. First, a main premise of IPv6
> > is that subnets (prefixes) are assigned (and delegated), not addresses.
> > Next, the prefix length is not an optional part of the OPTION_IAPREFIX. So,
> > generally speaking: - If dhcpcd solicits *this*/60 or any/60 and the ISP
> > advertises *some*/64, I think dhcpcd is supposed to ignore it because the
> > advertisement does not (reasonably) match the solicitation.
> >   - If dhcpcd solicits *any*/60 and the ISP advertises *some*/60, dhcpcd
> > should request it.
> >   - If dhcpcd solicits *this*/60 and the ISP advertises *this*/60, dhcpcd
> > should request it.
> >   - If dhcpcd solicits *this*/60 and the ISP advertises *some*/60, dhcpcd
> > can decide whether or not to request it.
> > 
> > I think we can expect another RFC or two dealing with delegated prefixes.
> > There are some ambiguities still.
> 
> So using your analogy, everyone goes hungry.
> With the current code, some people will eat if there is enough to go around 
> regardless of who ordered what.

With my analogy, everyone eats less than they hoped for. (I trust you've shared a pizza from time to time. There've been times I get one or two slices and the rest is gone by the time I reach for a third.) With dhcpcd (a /64 instead of a /60), *one* gets the whole thing and the rest starve.

It's more to do with consistency. PD is supposed to provide consistent, repeatable results. Given a consistent DUID, the requesting router is supposed to get the same prefix every time from the delegating router. If a business gets a /60 this hour, then gets a different /60 the next hour, they have to change all of their DNS (private and public), re-address all hosts, and deal with the flood of calls to their help desk. When a business asks for a /60, it is reasonable that they should expect to receive a /60 for their 12 internal LANs. Getting a /64 is little different from receiving nothing at all; 11/12 of their business is still down (think VoIP phones). People don't want the public (or private) addresses on their internal LANs changing. (Never mind that the spec says that both the old and the new addresses must both be active for some period of time; that leads to an operational nightmare, especially where a stateful firewall is involved.)

N