dhcpcd-discuss

On Tue, 07 Jun 2016 19:58:17 +0100
Roy Marples <roy@xxxxxxxxxxxx> wrote:

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

The problem lies in the fact that dhcpcd solicited a /60, Comcrash advertised a /64, and dhcpcd requested that /64 and tried to use it. This happened a number of times. It may not be dhcpcd's fault, but it shouldn't accept a /64 when it solicited a /60. It sure seems that this is what happened over and over.

Unless I had a God-awful mess of a configuration where my callback script saved xxx/64 as the DP, my .conf writer picked up that /64 and put it in the IA_PD line with the three SLAs. And then Comcrash became confused and would not advertise a /60 in response to a /60 solicit for many hours.

Mayhap dhcpcd should perform a quick sanity check on the IA_PD params to ensure that the request is large enough for the configured delegations before proceeding. E.g., if it sees three /64s requested and it sees that a /64 is requested (explicitly or by default), it should grouse about the misconfiguration and refuse to proceed.

If dhcpcd already performs these checks, then I am at a complete loss to explain what I saw, time and again, other than that something, somewhere, is fragile and my noob blundering about triggered the fragility.

Neal