dhcpcd-discuss

Hi Ron

On Saturday 04 July 2015 11:28:09 Ron Angeles wrote:
> I am currently using dhcpcd to delegate two prefixes to two interfaces
> on the other side of my router. However, the math doesn't seem to add up
> for me. The relevant config is as follows:
> 
> ----
> allowinterfaces eth0 eth1.10 eth1.11
> 
> noipv4ll
> noipv6rs
> nodhcp
> nodhcp6
> 
> interface eth1.10
> iaid 10
> 
> interface eth1.11
> iaid 11
> 
> interface eth0
> ipv6rs
> dhcp
> dhcp6
> ia_pd 1/::/63 eth1.10/0/64 eth1.11/1/64
> ----
> 
> Since I am requesting only two /64s, I figure that I naturally should
> only request a /63 from my ISP since it will be a perfect fit. However,
> delegating this to my interfaces seems to hit a snag.

Yes, it will hit a snag. Here's the exact wording of RFC3663 from section 12.1

   When a requesting router subnets a delegated prefix, it must assign
   additional bits to the prefix to generate unique, longer prefixes.
   For example, if the requesting router in Figure 1 were delegated
   3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and
   3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber
   network.  If the requesting router were delegated 3FFE:FFFF:0::/48
   and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and
   3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and
   3FFE:FFFF:5:2::/64 for assignment to the other link.


dhcpcd makes an exemption of the SLA 0 (ie no extra bits added) if it's 
assigned to exactly one interface.
This allows it to work when the PD is a /64.

The rationale is that the DHCP server doesn't know how many subnets are you 
going to create from the prefix and the RFC has an instruction to add a reject 
route for the prefix itself so that queries for unassigned subnets within your 
delegation to not go upstream. This in effect is the SLA 0.

So the bottom line is you need to request a bigger prefix.

> I must be missing something with my configuration, but it seems to me
> that I am effectively restricted from reusing the first /64 of any
> requested prefix. This in turn means that requesting a /63 prefix is the
> equivalent of requesting a /64.
> 
> As a workaround, I have since requested a /62 from my ISP since I can
> use two of the three usable /64's.

This isn't a workaround, it's actually the correct thing to do, as I described 
above.

Can you suggest how I can update my man pages to make this more clear for 
future users?

Thanks

Roy