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

[Jen Linkova <[e-mail]>]

Hi Bernie,

On Fri, May 10, 2024 at 8:47 PM Bernie Volz <[e-mail]> wrote:
> 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).

Ah, good to know our draft is not the only one conflicting with the
current text ;)

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

Do we need to say 'usally associated with an IA_NA'? Maybe smth like
"The IA Address option is used to specify an address. It can be
associated with other options (e.g. an IA_NA by encapsulated in the
IA_NA-options field) or use without encapsulation."
?

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

I think it would be reasonable to return  IAAddr without IA_NA,  with
OPTION_ADDR_REG_ENABLE inside IAaddr-options.
That would clearly indicate that it's not a lease.

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

Thank you! Just wanted to make sure that our draft is consistent with 8415.

> On May 10, 2024, at 2:52 AM, Jen Linkova <[e-mail]> 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



-- 
Cheers, Jen Linkova