[dhcwg] Re: Gunter Van de Velde's No Objection on draft-ietf-dhc-addr-notification-11: (with COMMENT)

["Gunter van de Velde (Nokia)" <[e-mail]>]

Hi Jen,

Thanks for taking a look at this, considering the feedback, and getting back to me with your thoughts.

Be well,
G/

-----Original Message-----
From: Jen Linkova <[e-mail]> 
Sent: Friday, May 10, 2024 8:17 AM
To: Gunter van de Velde (Nokia) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Gunter Van de Velde's No Objection on draft-ietf-dhc-addr-notification-11: (with COMMENT)


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi Gunter,

Thank you very much for such an extensive review!

On Mon, May 6, 2024 at 11:14 PM Gunter Van de Velde via Datatracker <[e-mail]> wrote:
> ## It is unclear what actions to take when the option-len is set to  
> value different as zero, even though the document prescribes that the 
> value MUST be 0
> (line211)

The MUST is for the sender, not for the receiver. RFC8415 doesn't prescribe how the receiver handles an unexpected option-len value for any options specified there. It's up to  implementations to decide what to do when they receive an existing option with an invalid length. Some implementations might ignore such invalid-length options, some may accept them, some may drop the packet. If we specify one of these behaviours in this document, then these existing implementations will not be able to reuse common code to ignore invalid options, but must implement the behaviour specified in this document, even if it is not consistent with what they do with other options. If we specify this, it should be specified in rfc8415bis, not in this document.
We’ll take this to the authors of the rfc8415bis and ask them what to do.

> ## In the abstract is written that statically assigned addresses can 
> be reported. However later in the document only SLAAC seems discussed. 
> For some reason CGA (RFC3972) type addresses is not mentioned. Not 
> sure that was intentional or by accident.

-12 which shall be submitted this week would have more text about static addresses.
CGAs are self-assign addresses, like privacy extensions - they are generated by using /64 prefix provided by the network and a cryptographically generated interface ID - so it's implied that they are in scope.


> #DETAILED COMMENTS
> #=================
> ##classified as [minor] and [major]
>
> 117        The lack of this parity with IPv4 is one of the reasons that may be
> 118        hindering IPv6 deployment, especially in enterprise networks.
>
> [minor] WHile potentially true, i am not convinced that this phrase 
> adds value for the document. The first paragraph already details well 
> enough the problem space without the procedure outlined in this draft.

Ack, deleted.

> 141        address registration.  It can do this by including the Address
> 142        Registration option code the Option Request option (see Section 21.7
> 143        of [RFC8415]) of the Information-Request, Solicit, Request, Renew, or
> 144        Rebind messages it sends to the server as part of the regular
>
> [minor] i am wondering if adding 'within'
> s/Registration option code the Option Request/Registration option code 
> within the Option Request/ would make sense from readability perspective?

Yes, thank you, it was a typo, fixed.

>
> 147        option in its Reply message.  If the network does not support (or is
> 148        not willing to receive) any address registration information, the
> 149        client MUST NOT register any addresses.  Otherwise, the client
> 150        registers addresses as described below.
>
> [minor] I assume that it is the DHCP server and not the network that 
> may not support (or i snot willing) to process such information.

Indeed, good point, s/the network/the DHCPv6 infrastructure/

> 152        After successfully assigning a self-generated IPv6 address on one of
> 153        its interfaces, a client implementing this specification SHOULD
>
> [minor] or statical configured

Thanks, fixed.

> 211         option-len            0
>
> [major] what to do if its not zero?

See above, it's for consistency with RFC8415.

> 215        If a client has the address registration mechanism enabled, it SHOULD
> 216        include this option in all Option Request options that it sends.
>
> [minor] Would a stronger MUST not be justified? Why would a client, 
> which supports the functionality AND has it enabled not advertise this?

It’s a SHOULD because if an implementation has a good reason not to do this, it’s probably OK to allow it - there is no negative impact to the implementation, the network, or other devices.

> 218        A server which is configured to support the address registration
> 219        mechanism MUST include this option in Reply messages.
>
> [minor] as a response when receiving such option from a client? or 
> simply always add this option?

The text updated to clarify that it MUST send it if the client message it is replying to contains this option in the Option Request option.

> 223        The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an
> 224        IPv6 address is in use.  The format of the ADDR-REG-INFORM message is
> 225        described as follows:
>
> [minor] Is it intended that the address is 'in use' or 'allocated and 
> assigned by the device on an interface'?

Just being lazy ;)
The text updated to ‘is assigned to the client's interface.’

> 284        The client MUST only send the ADDR-REG-INFORM message for valid
> 285        ([RFC4862]) addresses of global scope ([RFC4007]).  This includes ULA
> 286        addresses, which are defined in [RFC4193] to have global scope.  The
> 287        client MUST NOT send the ADDR-REG-INFORM message for addresses
> 288        configured by DHCPv6.
>
> [major] In the abstract is written "or statically configured 
> addresses" which is more then RFC4862 addresses. The text should 
> include the statically addresses.

Totally agree. The new text:
"The client MUST only send the ADDR-REG-INFORM message for valid
([RFC4862]) addresses of global scope ([RFC4007]). This includes ULA addresses, which are defined in [RFC4193] to have global scope. This also includes statically assigned addresses of global scope (such addresses are considered to be valid indefinitely)."

>What about Cryptographically Generated Addresses (CGAs) defined in  RFC 
>3972?

CGA document defines generating an interface ID, so effectively it's SLAAC ( rfc3972 explicitly mentions that the interface ID generation shall be similar to privacy extensions. While  rfc3972 doesn't discuss the lifetime explicitly, I read it as the standard SLAAC procedure applies.
So CGAs are in scope.

> 290        The client SHOULD NOT send the ADDR-REG-INFORM message if it has not
> 291        received any Router Advertisement message with either M or O flags
> 292        set to 1.
>
> [minor] This reads difficult because it is a double negative. What 
> about following rewrite: "The client SHOULD NOT send the 
> ADDR-REG-INFORM message if it has received no Router Advertisement 
> message with either the M or O flags set to 1"

Changed to "The client SHOULD NOT send the ADDR-REG-INFORM message unless it has received a Router Advertisement..."

> 298        Servers MUST discard any ADDR-REG-INFORM messages that meet any of
> 299        the following conditions:
>
> [major] What abot receiving such with length =! 0?

See above. Implementation-dependent.

> 314        If the message is not discarded, the address registration server
> 315        SHOULD verify that the address being registered is "appropriate to
> 316        the link" as defined by [RFC8415] or within a prefix delegated to the
> 317        client.  Otherwise, it MUST drop the message, and SHOULD log this
> 318        fact.  Otherwise, the server:
>
> [minor] i got thrown offguard with the the construct 'prefix delegated'.
> Is this RFC 3633 (IPv6 Prefix Options for Dynamic Host Configuration 
> Protocol (DHCP) version 6)? i asusme it is not, but in that case maybe 
> explain what 'prefix delegated' means? if it is RFC3633, maybe add reference.

It's not  RFC3633 (though, I believe, related). What we mean here is the standard DHCPv6 Prefix Delegation (defined in RFC8415).
I've added  the reference to RFC8415, section 6.3 which gives an overview of that mode of operation.

> 320        *  SHOULD register or update a binding between the provided Client
> 321           Identifier and IPv6 address in its database.  The lifetime of the
> 322           binding is equal to the Valid Lifetime of the address reported by
> 323           the client.  If there is already a binding between the registered
> 324           address and another client, the server SHOULD log the fact and
> 325           update the binding.
>
> [minor] is there any thoughts about managing misbahaving clients 
> sending 1000000000's of these by accident?

I believe this is discussed in the Security considerations section (see the first two paragraphs). Do you think anything is missing there?

> 472        We define a function AddrRegRefreshInterval(address) as min(4 hours,
> 473        80% of the address's current Valid Lifetime).  When calculating this
>
> [minor] who is 'we'? the WG, the authors? the IETF community?

;) Thanks, changed to 'A function is defined...'.

--
Cheers, Jen Linkova