dhcpcd-discuss

On Tuesday 07 June 2016 14:21:03 Neal P. Murphy wrote:
> On Tue, 07 Jun 2016 06:34:29 +0100
> 
> Roy Marples <roy@xxxxxxxxxxxx> wrote:
> > On 2016-06-07 00:28, Neal P. Murphy wrote:
> > > 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.
> > 
> > No, that's not right.
> > dhcpcd can split a 60 across many interfaces if you're wanting a 64 on
> > each delegated interface.
> 
> Sorry. I wrote that wrong and muddily. I meant to say that when dhcpcd gets
> a /64 (instead of the /60 that it was configure to ask for), only one
> interface can get a prefix while the rest get none. As long as dhcpcd
> receives the solicited /60, all is well. The trouble starts when dhcpcd
> solicits a /60, gets a /64, and then tries to assign /64s as specified in
> the .conf.

If that happens dhcpcd will refuse to delegate the lease because /64 won't fit 
into /64 with SLAs (the default). Now if there is an SLA of 0 then it will 
only be for one interface anyway so this is ok (and yes, you have to 
explicitly configure this).

> 
> If I don't specify the length, dhcpcd happily computes and distributes /72s
> when it receives a /64 PD to be distributed among four interfaces. If I
> configure dhcpcd to assign /96s, it happily splits the received /64 into
> /96s that it distributes to the various interfaces. But IPv6 explicitly
> specifies (according to everything I've read) that every LAN must receive
> no less than a /64. In short, it is a protocol violation to assign a /65 or
> larger prefix to a LAN.
> > Show me your config and what you expect please.
> > 
> > > 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.
> > 
> > Supposed to yes, but there is no guarantee this will be the case.
> > 
> > > 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.)
> > 
> > If you get a /64 and want to delegate to >1 interface as /64 AND have
> > none zero or default SLA's assigned then dhcpcd will refuse to configure
> > it because it will be too big.
> 
> This is fair enough. The problem remains that when I configure dhcpcd to
> solicit a /60 and the server instead advertises a /64, dhcpcd should ignore
> the advertisement because it does not match what it solicited.

Agreed.
It does.

> (Aside, if the server is capable of advertising 16 separate /64s, or 4 /62s,
> and dhcpcd is capable of computing a match to the /60 requirement and then
> distributing them, that might be almost OK.)

They can and dhcpcd does.

> Perhaps it comes down to one side or the other being wrong. Either the
> server is wrong for advertising a /64 instead of the solicited /60, or
> dhcpcd is wrong for accepting the advertised /64 instead of the solicited
> /60. It is sort-of akin to: Roy: I'm in the market for a Maybach. I'd like
> to test-drive one. Salesman: Great! Take this nice Yugo for a spin! I know
> you'll love it! Maybe both are wrong.
> 
> Or the spec is wrong for not stating that the advertised prefix length
> (which includes the mandatory length field) must match the solicited prefix
> length. If the server cannot provide the prefix of the solicited length, it
> is supposed to respond with 'no prefixes available'.
> > If on the other hand the prefix delegation just changes from dead to
> > beef then you have two choices - suck it up and re-number or complain to
> > your ISP to change it back.
> 
> Correct.
> 
> > In this scenario your hosts will be able to access the internet, just
> > not anyone able to access them by DNS.
> > 
> > But it's not outside the realm of possibility to renumber your hosts in
> > DNS. A well formed config file would just change the prefix which should
> > be quite straight forward.
> > 
> > This matches the long standing IPv4 practice.
> > 
> > But instead of us debating, I'm happy to add a config option to only
> > work with the given prefix and refuse others.
> > The length option should be fine as is.
> 
> The address in the prefix isn't the problem. Rather, the length is the
> problem. There isn't much you can do when the ISP silently changes your
> address. But the ISP are supposed to follow the spec. And when the spec
> says that customers must be able to request a delegated prefix large enough
> to fill their needs, the ISP's server must either advertise a suitable
> prefix or tell the customer that no such prefixes are available. They
> aren't supposed to advertise a /64 in response to a /60 solicitation. And I
> believe the spec says that the client should ignore (optionally refuse)
> advertisements that do not match its solicitations.

As far as I can see we are in agreement about the prefix length and dhcpcd does 
this already. So now I'm confused as to where any problem lies?

Roy