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

Michael Richardson <[email protected]> Fri, 10 May 2024 14:07:49 -0400
Newsgroups	gmane.ietf.dhc
Message-ID	<1955919.1715364469@dyas>
Bernie Volz <[email protected]> wrote:
    > Maybe we replace:

...

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

Works for me.

    > 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

Seems prudent.

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

I guess. I don't know much about leasequery.

    > —

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

+1

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


--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 487 B)