dhcpcd-discuss

Hi Kannekanti

On 26/07/2019 22:49, Kannekanti, Mohan wrote:
> We are using version 7.2.2.
>
> The CDRouter test suite reported a NoBinding testcase failure for IA_PD.
> Below are the steps that are followed.
>
> /    step 1. Wait for DHCPv6 client's current prefix binding T1 timer to 
> expire
>      step 2. Verify DHCPv6 client sends DHCPv6 Renew
>      step 3. Verify Renew contains IA_PD option (26) for same address prefix
>      step 4. Send valid DHCPv6 Reply with NoBinding status code (3)
>      step 5. Verify DHCPv6 client sends Request message
>      step 6. Verify Request contains IA_PD option (26) for same address 
> prefix
>
>      Reference: IETF RFC 3633 Section 12.1 "Requesting router behavior"/
>
> The test failing at "step 6". It is expecting that dhcp client should 
> send a REQUEST (as per section 12.1 and 18.1.8 in RFC3315) but the 
> client continue to send RENEW.
> In the attached packet capture, you can find the Reply (Packet #2) from 
> the server with NoBinding status for IA_PD followed by Renew packets at 
> T1 interval.

RFC 3633
12.1.  Requesting router behavior

   The requesting router uses a Request message to populate IA_PDs with
   prefixes.  The requesting router includes one or more IA_PD options
   in the Request message.  The delegating router then returns the
   prefixes for the IA_PDs to the requesting router in IA_PD options in
   a Reply message.

RFC 3633 has been obsoleted by RFC 8415:
18.2.4.  Creation and Transmission of Renew Messages

   To extend the preferred and valid lifetimes for the leases assigned
   to the IAs and obtain new addresses or delegated prefixes for IAs,
   the client sends a Renew message to the server from which the leases
   were obtained; the Renew message includes IA options for the IAs
   whose lease lifetimes are to be extended.  The client includes IA
   Address options (see Section 21.6) within IA_NA (see Section 21.4)
   and IA_TA (see Section 21.5) options for the addresses assigned to
   the IAs.  The client includes IA Prefix options (see Section 21.22)
   within IA_PD options (see Section 21.21) for the delegated prefixes
   assigned to the IAs.


> When I checked the code, looks like dhcp6_validatelease() is expecting 
> dhcp6_findia() to return "-1" to invalidate the lease and fallback to 
> discover state.
> But, in our case dhcp6_findia() is not returning "-1" thus the client 
> continued to send RENEW.
>
> dhcp6_findia(...) {
>      ...
>      while (l > sizeof(o)) {
>          ....
>          l -= sizeof(o) + o.len;
>          ....
>          if (dhcp6_checkstatusok(ifp, NULL, p, o.len) == -1) {
>              e = 1;
>              continue;
>          }
>          ....
>          i++;
>      }
>      ...
> *    if (i == 0 && e)
>          return -1;*
>      return i;
> }
>
> When we receive a valid IA_NA and invalid IA_PD (NoBinding), 'i' value 
> is 1 and 'e' value is '1'.
>
> Are we missing anything here? is it bug in dhcpcd?

You are missing the the IA_NA which is still valid, so while e is 1 due 
the the lack of binding for the PD, i is 1 because the NA is valid, thus 
no error is returned by this function. So dhcpcd RENEWS.

You can see that it's renewing at 45 second intervals which matches the 
T1 timer of the NA.
Thanks to the text of RFC 8415 you can request new addresses for 
assignment within a RENEW.

One of the goals of RFC 8415 was to make the client simpler. If we take 
RFC 3315 and 3633 at their literals, we would need to have seperate 
state machines for IA_PD and IA_NA/TA, but this is no longer the case.

I don't believe this is a bug in dhcpcd.

Roy