dhcpcd-discuss

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 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.

(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.)

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.

Neal