dhcpcd-discuss

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.

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

That's a limitation with your upstream.

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

Should accept both as well as 0xbeef

Roy