dhcpv6-ia: allow re-delegation of the on-link prefix (RFC6603)#374
dhcpv6-ia: allow re-delegation of the on-link prefix (RFC6603)#374mmmspatz wants to merge 1 commit intoopenwrt:masterfrom
Conversation
|
Note that |
|
I know about those bugs.... I've spent a few midnight hours chasing them. Thanks for this interesting PR! You know about max prefix length parameter, right? I'll take a closer look over the coming days since PX requires attention up to 128 bits, according to the spec. |
|
I know about There's no compliance issue with only supporting 32 bits of prefix id, since as the server we only have to emit a valid option, not consume it. And in this PR, I I've hard coded exclusion of a |
mmmspatz
force-pushed
the
mspatz/pd_exclude
branch
from
1498009 to
a857ec5
Compare
| uint8_t excl_subnet_id_nbytes = ((excl_subnet_id_nbits - 1) / 8) + 1; | ||
| o_pd_exl_len = sizeof(o_pd_exl) + excl_subnet_id_nbytes; | ||
|
|
||
| /* Work around a bug in odhcp6c that ignores DHCPV6_OPT_PD_EXCLUDE with valid option length of 2. */ |
There was a problem hiding this comment.
This workaround allows the current master branch of odhcp6c (with its bugs) to correctly parse the exclude option. It only works because the subnet id bits are all 0, so it doesn't matter that they get jumbled up.
A standards compliant parser shouldn't care about the extra trailing byte.
mmmspatz
force-pushed
the
mspatz/pd_exclude
branch
2 times, most recently
from
8ad322e to
d082db1
Compare
mmmspatz
force-pushed
the
mspatz/pd_exclude
branch
2 times, most recently
from
38fe5ae to
7d2c83f
Compare
|
OK - this is looking decent. What do captures reveal? The spec does not rule out an exclusion all the way up to 128, but it seems you're halting at 64 bits. The cross boundary maths there can get a bit difficult to follow. How do captures (tcpdump ish) look for this? |
|
I think you're confusing this with my other PR on odhcp6c. This PR is about sending option 67 from the server to exclude the first /64 (ie. subnet id 0) from the delegated prefix. Since it always excludes a /64 with subnet id 0, the |
mmmspatz
force-pushed
the
mspatz/pd_exclude
branch
from
7d2c83f to
82898e6
Compare
If a) a client sends the DHCPV6_OPT_ORO option with the DHCPV6_OPT_PD_EXCLUDE option code and b) option dhcpv6_pd_exclude is set in a dhcp config section, allow delegation of prefixes that contain the on-link prefix by including an RFC 6603 Prefix Exclude Option in the IA_PD response. This enables re-delegation of an interface's entire delegated prefix to a downstream router if a) option dhcpv6_pd_min_len allows it and b) no other downstream delegation has already been made. Signed-off-by: Mark H. Spatz <mark.h.spatz@gmail.com>
mmmspatz
force-pushed
the
mspatz/pd_exclude
branch
from
82898e6 to
263f621
Compare
mmmspatz
changed the title
|
re-worded the documentation, commit message, and some comments. |
2 participants
If option
dhcpv6_pd_excludeis set in adhcpconfig section (in addition todhcpv6_pd), consider delegating prefixes that include the on-link prefix, and send RFC6603DHCPV6_OPT_PD_EXCLUDEfor the on-link prefix.For example, if the interface's longest prefix is
2001:0db8::/32, we might delegate that entire/32and send aDHCPV6_OPT_PD_EXCLUDEoption for2001:0db8::/64. More commonly, we might delegate a smaller prefix that includes the on-link prefix, like2001:0db8::/56.For this behavior to be triggered, all of the following must be true:
option dhcpv6_pd_exclude ='1'must be set in the configDHCPV6_OPT_OROoption with theDHCPV6_OPT_PD_EXCLUDEoption code2001:0db8:0:10::/60has been assigned to client A, we can't assign2001:0db8::/56to client B. We'll instead end up assigning2001:0db8:0:100::/56just as before.My implementation makes the assumption that the on-link prefix is the first
/64in the interface's larger prefix. I note thatassign_pd()already made that assumption: The first subnet id it considered was0000:0001, now it may optionally consider0000:0000. I believe it is correct to say thatodhcpdrelies onnetifdassigning the first/64as the on-link prefix when it is delegating a prefix to an interface. If a user gave an interface address2001:0db8:dead:beef::/32and also created an unreachable route to that prefix,odhcpdwould misbehave.