Re: [dhcwg] Comments on draft-ietf-dhc-addr-notification-00

[Bernie Volz <[e-mail]>]

Hi.

Thanks.

A few further comments on -01:

In section 4.1:
   Unlike other types of messages, which are sent from the link-local
   address of the client, then ADDR-REG-INFORM message MUST be sent from
   the address being registered.  This is primarily for "fate sharing"
Then should be the.

In section 4.1.1:
   *  the message does not include the IA Address option, or the IP
      address in the IA Address option does not match the source address
      of the original ADDR-REG-INFORM message sent by the client.
If may be wise to help server implementers to understand where this “source address of original”? If not relayed, the IPv6 source address; if relayed, the innermost Relay-Forw’s message peer-address field? I just fear someone reading this may miss this subtle difference and we end up with broken implementationsm when relays are involved?

In section 4.3:
   The client MUST refresh the registration every AddrRegRefresh
   seconds, where AddrRegRefresh is min(1/3 of the Valid Lifetime filed
   in the very first PIO received to form the address; 4 hours).
Is it normal for clients to retain this initial Valid Lifetime? What happens if a client updates its software to support this work but that doesn’t involve a reboot? My guess is you want this value used as it might be less likely to be ending soon if there is a renumber event coming (where the lifetime left might be minutes)? Or, why is this very first so critical?

In section 7:

   This document defines two new DHCPv6 messages, ADDR-REG-INFORM
   message (TBA1) described in Section 4, and ADDR-REG-REPLY (TBA2)
   described in Section 5, that requires an allocation out of the
   registry of Message Types defined at http://www.iana.org/assignments/
   dhcpv6-parameters/.
The sections were renumbered and so both are in section 4 now … section 4.1 & 4.2? If you use xml2rfc, perhaps you should use section anchors and references to the anchors so renumbering automatically fixes the text?

- Bernie (from iPad)

> On Aug 2, 2023, at 2:39 AM, Jen Linkova <[e-mail]> wrote:
> 
> Hi Bernie,
> 
> Thank you for the review and comments!
> We've just submitted the -01 version which should address your comments.
> See below.
> 
>> On Fri, Jul 28, 2023 at 2:16 AM Bernie Volz <[e-mail]> wrote:
>>   It is very common operational practice, especially in enterprise
>>   networks, to use IPv4 DHCP logs for troubleshooting or security
>>   purposes.  Examples of this include a helpdesk dealing with a ticket
>> BV> Perhaps "help desk"?
> 
> Ack, fixed.
> 
>>   This operational practice relies on the DHCP server knowing the IP
>>   address assignments.  Therefore, the practice does not work if static
>>   IP addresses are manually configured on devices or self-assigned
>>   addresses (such as when self-configuring an IPv6 address using SLAAC
>>   [RFC4862]) are used.
>> 
>>   The lack of this parity with IPv4 is one of the reasons which may be
>>   hindering IPv6 deployment, especially in enterprise networks.
>> 
>>   This document provides a mechanism for a device to inform the DHCPv6
>>   server that it has a self-configured IPv6 address (or has a
>>   statically configured address), and thus provides parity with IPv4 in
>>   this aspect.
>> BV> I'm not sure how strong this argument is. In IPv4, the network does
>> BV> not learn of "static" addresses; the reason it works better in IPv4
>> BV> is that (almost) all clients implement DHCPv4 - whereas some (Google)
>> BV> have decided not to implement DHCPv6 and hence that is reason this
>> BV> is needed for IPv6.
> 
> Not having stateful DHCPv6 is a valid deployment model (not possible
> in the IPv4 world though).
> For example, the IETF network provides stateless DHCPv6 only. Such
> networks might want to collect information about SLAAC assigned
> addresses.
> Such networks might want to know about devices and their addresses.
> 
> Also, even in a presence of stateful DHCPv6 (and RAs with M flag set),
> the host might (and, AFAIK, most of implementations do) form both
> DHCPv6-provided and SLAAC addresses. More specifically, if the network
> is IPV6-only, even if in the presence of DHCPv6 servers,
> DHCPv6-enabled hosts can generate checksum-neutral 464xlat addresses
> via SLAAC.
> 
> In addition to that, there are cases when running a stateful DHCPv6
> server might be an overkill (phone hotspots etc).
> 
> Do you think we need more text in the draft about this?
> 
>> 3.  Registration Mechanism Overview
>>   After successfully assigning a self-generated IPv6 address on one of
>>   its interfaces, a client implementing this specification SHOULD
>>   multicast an ADDR-REG-INFORM message in order to inform the DHCPv6
>>   server that this self-generated address is in use.
>> BV> Perhaps say "(see Figure 1)" or "as shown in Figure 1"?
> 
> Fixed.
> 
>> 4.  DHCPv6 ADDR-REG-INFORM Message
> 
>>   The ADDR-REG-INFORM message MUST NOT contain server-identifier option
>> BV> Use "Server Identification option" as that is official name?
> 
> Fixed, thank you!
> 
>>   and MUST contain the IA Address option.  The ADDR-REG-INFORM message
>>   is dedicated for clients to initiate an address registration request
>>   toward an address registration server.  Consequently, clients MUST
>>   NOT put any Option Request Option(s) in the ADDR-REG-INFORM message.
>>   Clients MAY include other options, such as the Client FQDN Option
>>   [RFC4704].
>> 
>> BV> I think some text here would be useful as to what should be placed in
>> BV> the preferred/valid lifetime values (are both used or is preferred perhaps
>> BV> set to 0 as it really isn't applicable to registration).
> 
> Oh thank you, that's a good point. The server does need to know the
> preferred lifetime (see Section 6.3, Registration Expiry and Refresh),
> so we added the text to clarify that the client needs to put the
> actual lifetime values into those fields.
> 
>> Also, do static
>> BV> addresses have different (valid) lifetimes than RA (PIO) derived ones
>> BV> (which likely use the remaining preferred/valid lifetimes from the PIO
>> BV> times)?
> 
> Most likely, but I'm not sure it matters - the client shall populate
> the field with whatever lifetimes are currently set for the address.
> 
>>   The ADDR-REG-INFORM message MUST contain an IA Address option for the
>>   address being registered.
>> BV> This is "ADDR-REG-REPLY" message.
> 
> Fixed.
> 
>> BV> What should be put in lifetimes in IA Address option? Should these
>> BV> just be values received by server or should fields be set to 0 and
>> BV> ignored by client receiving the message?
> 
> The draft updated to explicitly specify that the server must just copy
> the option.
> 
>>   *  The IA-Address option does not match the address being registered
>> BV> Add period? Or should this be list that uses semicolons?
> 
> Fixed.
> 
>> 6.1.  DHCPv6 Address Registration Request
>> 
>>   The client sends a DHCPv6 ADDR-REG-INFORM message to the address
>>   registration server to the All_DHCP_Relay_Agents_and_Servers
>>   multicast address (ff02::1:2).  The client MUST only send the packet
>>   on the network interface that has the address being registered (i.e.
>>   if the client has multiple interfaces with different addresses, it
>>   should only send the packet on the interface with the address being
>> BV> This "should only" is a bit weird given the MUST. But I think the
>> BV> idea is similar to that in RFC8415 section 17.1? Maybe suggest
>> BV> readers refer to that section?
> 
> We've rephrased it, PTAL.
> 
>>   registered).  The client MUST send the packet from the address being
>>   registered.  This is primarily for "fate sharing" purposes - for
>> BV> I think highlighting this difference from the normal client behavior
>> BV> to use the link-local address is important to make it stand out?
>> BV> Perhaps say, "Note that the client MUST NOT send this message using its
>> BV> link-local address as for normal DHCPv6 client behavior as in RFC8415."?
> 
> Sure, the text has been added.
> 
>>   example, if the network implements some form of L2 security to
>>   prevent a client from spoofing other clients' addresses this prevents
>>   an attacker from spoofing ADDR-REG-INFORM messages.  The client MUST
>>   send separate messages for each address being registered.
>> BV> Would repeating that only one IA Address option with the address
>> BV> being registered MUST be included here be useful?
> 
> Done, the draft is now saying that the INFORM MUST contain exactly one
> AI Address option.
> 
>>   After receiving this ADDR-REG-INFORM message, the address
>>   registration server SHOULD verify that the address being registered
>>   is "appropriate to the link" as defined by [RFC8415].  If the server
>>   believes that  address being registered is not appropriate to the
>> BV> "that [the] address"?
> 
> Thanks, fixed!
> 
>>   link [RFC8415], it MUST drop the message, and SHOULD log this fact.
>>   If the address is appropriate, the server:
>> 
>>   *  SHOULD register or update a binding between the provided Client
>>      Identifier and IPv6 address in its database;
>> BV> Add something about registering or extending an existing reservation
>> BV> by the [valid] lifetime in the IA Address option? Also, maybe mention
>> BV> the 0 case? I.E., if [valid] lifetime is zero, remove any existing
>> BV> reservation?
> 
> Text added.
> 
>> BV> When creating/updating a registration, obviously it should only occur
>> BV> if there is not already a registration for a different client.
> 
> 
> Make sense, text added to log the event if the same address is
> registered by another client.
> 
>>   *  SHOULD log the address registration information (as is done
>>      normally for clients which have requested an address), unless
>>      configured not to do so;
>> 
>>   *  SHOULD mark the address as unavailable for use and not include it
>>      in future ADVERTISE messages.
>> BV> should replace . with ; as list not done?
> 
> We replaced all of those with dots.
> 
>>   *  SHOULD send back an ADDR-REG-REPLY message.
>> 
>>   If the DHCPv6 server does not support the address registration
>>   function, it MUST drop the message, and SHOULD log this fact.
>> BV> Do we really want to recommend "SHOULD log this fact"? This makes
>> BV> all existing implementations that may not log unknown messages
>> BV> violate a SHOULD? Do we even this paragraph?
> 
> You are right, the text is removed.
> 
>>   DHCPv6 relay agents and switches that relay address registration
>>   messages directly from clients SHOULD include the client's link-layer
>>   address in the relayed message using the Client Link-Layer Address
>>   option ([RFC6939])
>> BV> Needs period to end sentence.
> 
> Fixed.
> 
>> BV> I wonder if missing from this section is anything about delaying the
>> BV> initial address registration request? Once an RA with the M or O bits
>> BV> is sent on a network that might not have had either set, the server
>> BV> could receive a flood of registration requests if there is no initial
>> BV> delay. Perhaps when clients reboot, this isn't as much of a problem as
>> BV> it may take the client some (random) time to finalize the SLAAC address
>> BV> before sending out, but in other cases (such as setting M or O that
>> BV> hadn't been set before) could cause a storm? May just be better to
>> BV> always require SOL_MAX_DELAY random initial interval? Or add a new
>> BV> ADDR_REG_MAX_DELAY?
> 
> I believe this would not be necessary. The client would not register
> an address until DAD is completed.
> DAD Neighbor Solicitations are sent with random delay
> (https://datatracker.ietf.org/doc/html/rfc4862#section-5.4.2), so the
> hosts would not move their tentative addresses to 'preferred' state at
> the same time anyway.
> 
>> 6.2.  DHCPv6 Address Registration Acknowledgement
>> 
>>   The server SHOULD acknowledge receipt of an ADDR-REG-INFORM message
>>   by sending a ADDR-REG-REPLY message back, using the address being
>>   registered as the destination address for the packet.
>> BV> This is a bit simplistic. If not relayed, this would be the case.
>> BV> If relayed, the path must be via the normal relayed path and the
>> BV> relay closest to the client would use the peer-address field which
>> BV> contains the client's address. (The server would use the relayed
>> BV> packet's IPv6 source address -- basically, in all cases the IPv6
>> BV> source address of the packet received by the server is used.)
> 
> Yes, you are right. If the INFORM message is not relayed, the REPLY's
> destination address is the address being registered.
> For the relayed messages the server would craft Relay-reply. Please
> review the new text, I hope it's better now.
> 
>> 6.3.  Registration Expiry and Refresh
>> 
>>   The client MUST refresh the registration every AddrRegRefresh
>>   seconds, where AddrRegRefresh is min(1/3 of the Valid Lifetime filed
>>   in the very first PIO received to form the address; 4 hours ).
>> BV> Perhaps the above is also what should be sent in the [preferred]
>> BV> lifetime (see comment below and earlier on lifetimes and how they
>> BV> are to be interpreted) or some multiple of this value to allow
>> BV> "time" for update communication to happen? Also, this "Valid
>> BV> Lifetime" here is a bit odd given text below about preferred lifetime?
>>   If the address registration server does not receive such a refresh
>>   after the preferred lifetime has passed, it SHOULD remove the record
>>   of the Client-Identifier-to-IPv6-address binding.
>> BV> Is it preferred or valid lifetime? Whatever you chose, might require
>> BV> some adjustment to my comments earlier (use preferred vs valid)?
> 
> We are now using the valid lifetime everywhere.
> 
>> 9.  IANA Considerations
>> 
>>   This document defines a new DHCPv6 message, the ADDR-REG-INFORM
>>   message (TBA1) described in Section 4, that requires an allocation
>>   out of the registry of Message Types defined at
>>   http://www.iana.org/assignments/dhcpv6-parameters/
>> BV> What about ADDR-REG-REPLY (TBA2)? Also, add period to end of sentence?
> 
> Fixed.
> 
> --
> SY, Jen Linkova aka Furry