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

[Jen Linkova <[e-mail]>]

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