Re: [dhcwg] Requesting feedback for DHCPv6 address notification draft

[Bernie Volz <[e-mail]>]

Oh, I forgot one case for server’s possible actions:

- when recording, the server may be unable to comply such as if it has leased that address to another device (valid lifetime not yet expired) … perhaps this should be communicated to client? Of course, this is also why server needs to flag these assignments as special so that if it was from ealier client reported, it just overwrites with new information.

- Bernie Volz

> On Aug 4, 2022, at 9:13 AM, Bernie Volz <[e-mail]> wrote:
> 
> 
> Hi:
> 
> I have a bunch of concerns with this draft.
> 
> 5.1.  DHCPv6 Address Registration Request
> 
>    The end-host sends a DHCPv6 ADDR-REG-NOTIFICATION message to the
>    address registration server to the All_DHCP_Relay_Agents_and_Servers
>    multicast address (ff02::1:2).  The host SHOULD send the packet from
>    the address being registered.
> 
> I am not sure that he "SHOULD send the packet from the address being registered" is wise? While I understand the reason for this is that it might be used by the server to validate that the client does indeed "own" that address, I am not sure if it causes issues with IPv6 communication (i.e., as the destination multicast address is link-local, is using a "global" scope address as the source a good idea and what about the Reply coming back to the client -- I would assume it would use the normal Relay-Reply path, and having a global address for the relay to send the packet to might cause some issues and opens things up for potentially having the relay send the packet anywhere?). Also, there is no recommendation that a server confirm this address is the one being registered, so not sure why using it as the source address has any value? But if no one else sees issues, I am fine if this is the recommendation.
> 
> And, what if there are multiple addresses being reported in the request? Section 4 says "the message does not contain at least one IA Address option". What is the source address if there are multiple addresses?
> 
>    After receiving this ADDR-REG-NOTIFICATION message, the address
>    registration server MUST register the binding between the provided
>    Client Identifier and IPv6 address.  If the DHCPv6 server does not
>    support the address registration function, it MUST drop the message
>    (and may log the event).
> 
> Oh really? What if the address is not in the server's configuration (i.e., no prefix configured to match the prefix for the address)? And, while the server I used to work on (Cisco Prime Network Registrar) would have the capability to register any address in the prefix, some other servers currently do not as they are configured with a "range" of addresses that does not cover the entire prefix address range.
> 
> I think what the server does with this information is also a matter of policy for the server. For example, I could easily see cases where a server would not want to record ("register the binding") this information. Perhaps it might just "log" it or perhaps it just ignores it. Note that "ignores" is more complex because if the client is expected to retransmit this a number of times, it might be better for the server to respond to the client to prevent unnecessary retransmissions?
> 
> Thus, a server has the following possible actions:
> - Ignore the packet completely
> - Ignore the packet and respond to it (either with a "success" indication or a "failure" (such as ignored)). This might be because the server doesn't have any interest (administratively configured) in doing anything with requests on that particular prefix (or link) or does not have it in the configuration (or it conflicts with its configuration - i.e., link-address from relay doesn't match what prefixes it knows about under that link).
> - Log the information (and respond to it). But not "record" the binding. Perhaps this is considered a success in the response?
> - Record (and possibly) log the information. This is considered a success.
> 
> Also, one would think that if a server does "record" the binding, that it also flags it as being from a registration request and NOT an assignment by the server. This of course also raises questions as to what a server should do if the client does send "normal" DHCPv6 assignment requests? Should the server include these addresses? My guess is that it should NOT - which is one reason why it must flag it. Note that these addresses would not be bound to an IA_NA as none was communicated so it really could not send the address in a normal DHCPv6 assignment request anyway.
> 
> The above does raise a question as to whether any new status codes are needed to communicate anything to the client. For example, if a server exists but is not interested or able to use the information, maybe suppressing future notifications by the client for the address (or addresses) may be a benefit to reduce traffic and load? Though that could have some security issues. Also, might a status code to say "Registration request ignored; too many other registrations [for that client]" be useful as the server should likely limit how many it will record for a particular client?
> 
> Also, if multiple addresses can be registered at once, perhaps the refresh operations are based on the "smallest" lifetime? This would allow all to be refreshed at once.
> 
> For section 5.3, shouldn't it specify the standard retransmission values as per RFC8415? For example:
> 
>       IRT     REG_TIMEOUT
> 
>       MRT     0
> 
>       MRC     REG_MAX_RC
> 
>       MRD     0
> 
> Where REG_TIMEOUT and REG_MAX_RC are new parameters ... REG_TIMEOUT might be 1 sec and REG_MAX_RC might be 4 (similar to the Release message values). And of course, this would imply use of the standard retransmission logic (as per Section 15 of RFC8415).
> 
> I don't believe there's been any final decision on whether RAs can configure prefixes for clients; but if that work is ever advanced I would guess that we may want clients to report those as well? But this would be a fairly simple extension to allow IA_PREFIX options to the new message.
> 
> 
> Section 4 also has "Clients MAY include other options, such as the Client FQDN Option [RFC4704]." As I thought that one reason this work did not advance in the past was because of the DNS registration issue, is this potentially reintroducing that (though there is no statement that a server must do a DNS update). I guess if the client has done this, reporting it to the server is OK. But, I think this should be clarified that the server MUST NOT perform any DNS updates on behalf of the client.
> 
> 
> Anyway, those are some of the issues I currently see that need to be addressed (likely before adoption is considered).
> 
> - Bernie Volz
> 
>> On Tue, Aug 2, 2022 at 8:50 AM Alan DeKok <[e-mail]> wrote:
>> On Aug 1, 2022, at 9:39 PM, Lorenzo Colitti <lorenzo=[e-mail]> wrote:
>> > We'd like to request feedback with a view to requesting WG adoption and an experimental message type.
>> > 
>> > As a reminder, the draft defines a message type that allows the client to tell the network what addresses it has acquired via other means (e.g., static configuration or SLAAC).
>> 
>>   This is a short review based on technical content, not purpose.
>> 
>> Section 3
>> 
>>    After receiving the
>>    address registration request, the DHCPv6 server MAY record and log
>>    the IPv6 address.
>> 
>> It would help to describe the situations where the DHCPv6 server doesn't log it.  i.e. if the DHCPv6 server does not expect to need / use that information.
>> 
>> It would be good to describe also what is meant by "log".   Perhaps even a short statement "MAY record and log the IPv6 address, as is done normally for clients which have requested an address"
>> 
>> What happens to an existing DHCPv6 receives this message, but doesn't understand it?  A reference to RFC 7283 would be good.
>> 
>> Section 5.1
>> 
>>   The end-host sends a DHCPv6 ADDR-REG-NOTIFICATION message to the
>>    address registration server to the All_DHCP_Relay_Agents_and_Servers
>>    multicast address (ff02::1:2).  The host SHOULD send the packet from
>>    the address being registered.
>> 
>> If the device has multiple networks, the address being registered may not be valid on all networks.  If so, what other address can be used?
>> 
>>    {TODO (WK): DHCPv6 uses "DHCP Unique Identifier (DUID)" to identify
>>    clients.  This doesn't really meet our design goal of "what IP does
>>    the printer have?!".  One of the DUID types is "DUID Based on Link-
>>    layer Address (DUID-LL)", but this is "any one network interface(s)"
>>    - this is probably good enough for the inventory use case, but still
>>    not ideal}
>> 
>> What if the device is on WiFi, and is doing MAC address randomization?  Ideally the identifier should taken from a stable value.
>> 
>> If the device is statically configured with a host name, perhaps that could be used.  Though there's no Client Identifier sub option which would carry that information.
>> 
>> Section 5.2
>> 
>>    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.
>> 
>> I would add "or mark it as no longer active".
>> 
>> 
>>   {TODO: Add some text around "feel free to ignore messages if it looks
>>    like a DoS attack" / your leases table is getting full.  Note that
>>    this is an existing issue for DHCP and spoofed MACs (ask me how I
>>    know :-)) }
>> 
>> Perhaps there are some requirements on relays which could be added here?  i.e. don't contribute to the problem, especially if you can detect it locally.
>> 
>> 
>>   Also, what happens to relays when they forward such a message, and don't see a reply?  Presumably relays maintain some kind of state, so that they can direct replies back to the source of the request.
>> 
>>   There should be some text saying that relays which understand this message should forward the packet, and then immediately delete all state associated with the packet, as no reply is expected.  Relays which don't understand this message will drop it, so that's OK.
>> 
>>   Alan DeKok.
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg