dhcpcd-discuss

On Mon, 6 Jun 2016 10:50:26 +0100
Roy Marples <roy@xxxxxxxxxxxx> wrote:

> On 02/06/2016 21:29, Neal P. Murphy wrote:
> > On Wed, 1 Jun 2016 19:18:46 -0400 "Neal P. Murphy"
> > <neal.p.murphy@xxxxxxxxxxxx> wrote:
> > 
> >> ... I'm beginning to suspect Comcrash's servers because dhcpcd
> >> seems to work flawlessly for a while, and then stops.
> > 
> > I'm dunno what to suspect now. It still wouldn't work right this
> > afternoon. Should dhcpcd detect that the offered des. pref. is not
> > the same size as requested and reject it?
> 
> 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.

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 next I generated new IAIDs and started from no 'old' /128 and
> > ::/60 PD request. And it came right up with a new /128 but the old
> > /60 it'd been giving me before.
> 
> /128 will be from IA_NA or IA_TA, not IA_PD.
> Don't muddy the water here :)

Unless I screwed something up over and over, I found IA_PD doesn't work unless I also request IA_NA. (Haven't tried IA_TA.) They both arrive in the same message (BOUND6 in the callback), though I suppose they *can* arrive separately.

> 
> > This time I will leave IPv6 running to see if (how long, really) it
> > remains stable; see if renewal works. And add ::1 of the /60 to the
> > internet IF; for some reason I get the idea that the /128 Comcrash
> > gives me is needed only to route packets to any of those /60
> > destinations. Oh, and polish the firewall some.
> 
> Yes no maybe.
> I'm not an ISP, but the only reason to hand out a /128 IA_NA is if you
> don't have IA_PD support. Saying that, technically you don't have to
> assign an address to the router for the PD - it's just easier to do so
> as it enabled rtadvd(8) on the BSD's (Linux has another equivalent) to
> pickup the address an advertise that on the downstream interfaces.

I figured the internal LL address *should* work internally on that LAN, since Comcrash use their LL address as the default gateway on their side, but I haven't figured out how to use ip() to assign the firewall's LL address as the default gateway for that internal zone. Using LL addresses for gateways makes some sense since the default gateway and all routes pertain to the LAN only. In my case, it may be easier to 'mirror' IPv4 in some respects rather than developing a completely new code base to handle IPv6.

I clearly have much to learn about IPv6.

Another use question about dhcpcd where the man page isn't clear. When setting the IAID, is either a decimal integer less than 2^32 or four hex bytes separated by colons (:) valid syntax for dhcpcd?

N