[dhcwg] Re: draft-ietf-dhc-rfc8415bis: normative language , IA Address and option-len

Hi:

It does seem we need to fix the dhcpv6 standard (bis) as if you look at the DHCPv6 Leasequery RFC (5007), it makes use of the IAADDR option outside of IA_NA (we can ignore IA_TA as it has been deprecated).

Maybe we replace:

21.6.  IA Address Option

   The IA Address option is used to specify an address associated with
   an IA_NA.  The IA Address option must be encapsulated in the
   IA_NA-options field of an IA_NA option (see Section 21.4).  The
   IAaddr-options field encapsulates those options that are specific to
   this address.

With:

21.6.  IA Address Option

   The IA Address option is used to specify an address, usually
   associated with an IA_NA and encapsulated in the
   IA_NA-options field of an IA_NA option (see Section 21.4).  The
   IAaddr-options field encapsulates those options that are specific to
   this address.

I don’t believe we have any uses for IAPREFIX options outside of IA_PD, but we could consider similar change there (21.22)? Odd that that section doesn’t mention IAprefix-options field. (Leasequery doesn’t allow a query by prefix as query by address is sufficient - the query returns either IA_NA with IAAddr or IA_PD with IAPrefix.)

—

That does bring up an interesting point … what should leasequery do if queried for a registered address? Just return the IAAddr without IA_NA or manufacture a “fake” IA_NA (perhaps with IAID 0 and adding the OPTION_ADDR_REG_ENABLE option in the IAAddr-options field to notify querier that this is a self registered address). We should address this — same concept can be used for failover (RFC8156).

—

Regarding your point of validation of option lengths we generally chose not to require that except of course that an option must at least be the “minimum” length (many options are variable length and unknown options are just that). So if your zero-length option is not that, it really does little harm (except wasting bytes). Yes, it might mean that the option is not really correct and some implementation may have hijacked that option number for a different purpose which could result in unexpected behavoir.

Note that we do have text in section 16 about message validity - and that includes that the messages are encoded correctly - no extra bytes at end (i.e., incomplete option-code + length) or missing bytes at end of message (last option is too short for specified option length).

- Bernie (from iPad)

> On May 10, 2024, at 2:52 AM, Jen Linkova <[email protected]> wrote:
> 
> Hello,
> 
> While addressing various comments for draft-ietf-dhc-addr-notification
> (which is on the Telechat agenda for the next week), we've noticed a
> few interesting things in RFC8415/draft-ietf-dhc-rfc8415bis, which I'd
> like to bring to the WG attention.
> 
> 1. Both RFC8415 and draft-ietf-dhc-rfc8415bis are using [RFC2119]
> [RFC8174] normative language. However there are 23 cases where 'must'
> (lower case) is used (vs 200+ cases of MUST).
> 
> The case which concerns me mostly is Section 21.6 (IA Address option). It says:
> 
> "The IA Address option must be encapsulated in
>   the IA_NA-options field of an IA_NA option (see Section 21.4) or the
>   IA_TA-options field of an IA_TA option (see Section 21.5)."
> 
> It is not MUST, so, strictly speaking, it's not a normative language.
> Now I'm wondering; is it really not mandatory), is it just an
> oversight or  was it left untouched in -bis just in case there are
> implementations which do not treat 'must' and 'MUST' so changing
> 'must' to MUST would break them or make them violating 8415bis?
> 
> (Sorry if it has been discussed already..)
> 
> 2. If 'must' in Section 21.6 is actually 'MUST', then
> draft-ietf-dhc-addr-notification clearly violates it: that draft is
> using IA Address option in ADDR-REG-INFORM and ADDR-REG-REPLY w/o any
> encapsulation.
> 
> Shall we rephrase section 21.6 to smth like:
> 
> "The IA Address option is used to specify an address associated with
> an IA_NA or an IA_TA.  In that case the IA Address option must be
> encapsulated in
>   the IA_NA-options field of an IA_NA option (see Section 21.4) or the
>   IA_TA-options field of an IA_TA option (see Section 21.5).  The
>   IAaddr-options field encapsulates those options that are specific to
>   this address.
> IA Address option MAY be used with or without encapsulation in other
> options and messages, when an address needs to be specified."
> 
> Another possible action plan would be to wait 6 days and if
> draft-ietf-dhc-addr-notification is approved for the publication, add
> a reference to 8415bis (AFAIR it was proposed before but at that time
> there was a risk of delaying 8415bis by doing so).
> 
> 3. Last but not least...Another point raised during
> draft-ietf-dhc-addr-notification review is that we do specify how the
> sender shall set the option-len (MUST be zero) but we do not specify
> the behaviour on the receiving side, if that MUST is violated. The
> current text is consistent with 8415 - I could not find any text there
> specifying the behavior for unexpected option-len value.  I assume
> it's intentional, as per the robustness principle - but I'd like to
> confirm.
> 
> Thanks!
> 
> --
> Cheers, Jen Linkova

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]