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

[Warren Kumari <[e-mail]>]

On Thu, Aug 04, 2022 at 9:39 PM, Lorenzo Colitti <[e-mail]> wrote:

> Alan,
>
> Thanks for the feedback.
>

+many lots.

We'll be working on incorporating most of it in a future version, but
> otherwise, inline:
>

Warren has had this on his ToDo list for an embarrassingly long time, and
is finally getting around to it..

"I love deadlines. I like the whooshing sound they make as they fly by."
  — Douglas Adams


> On Tue, Aug 2, 2022 at 9:50 PM Alan DeKok <[e-mail]>
> wrote:
>
>>    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"
>>
>
> Hmm. The reason this text is vague is that this is really up to the server
> and network operator. The goal of the draft is to have the client give this
> information to the network. The server can log it if it's configured to do
> so, but it can just drop it. It could also track it just like it tracks
> other leases. Some network gear might conceivably want to tie this message
> to their layer 2 security as well. I don't think the logging behaviour is
> specified in any RFC for other options today (e.g., IA_NA, IA_PD, etc.),
> so maybe we can keep this vague and say "the DHCPv6 server MAY record and
> log the IPv6 address, if it is configured to do so"?
>

I've done / am doing a fair bit of surgery on this area of the text (and am
trying to address multiple comments here). How is:

"After receiving this ADDR-REG-NOTIFICATION message, the address
registration server SHOULD register the binding between the provided Client
Identifier and IPv6 address in its database. The address registration
server SHOULD also log the address registration information (as is done
normally for clients which have requested an address).

If the DHCPv6 server does not support the address registration function, or
if the server believes that  address being registered is not "appropriate
to the link" [RFC8415], it MUST drop the message, and SHOULD log this fact."

Does this work? Much of the purpose of this proposal is to allow operators
to know who has what addresses, and so I think a "SHOULD" is the minimum
needed for the logging (and I like "as is done normally" - it reinforces
that this is similar to a normal 'the server handed out the address'". The
reasons for the server registering the binding is so that it doesn't also
try and hand out the address (which is probably statistically unlikely!),
and so that if there is tooling which allows interrogation of the database
it shows what it in use.

Bernie had as really good point (upthread): "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)?"
The second paragraph is intended to address that — I wasn't sure if text
like "address is not in the server's configuration" or if "appropriate to
the link" was better?


  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?
>>
>
> The expectation is that the device would only inform the server of
> addresses specific to that network. We should make that clear.
>

Yes! I wasn't quite sure where to put this / how to word it, and so I came
up with:
"The host MUST only send the packet on the network interface that has the
address being registered (i.e. if the host has multiple interfaces with
different addresses, it should only send the packet on the interface with
the address being registered)." I don't love it, but I *think* that it
works OK?


>
>>    {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.
>>
>
> I think part of the goal here is to find a way to communicate IP address /
> MAC address pairs to the network for logging purposes. Having the real MAC
> address is useful for that. There is already a stable identifier in the
> packet - the DUID.
>


Yup. The DUID is the "this is unique to the device" bit (and is included),
and the MAC<->IP is to support the main use case. As an operator, if I am
seeing issues related to an IP address, I'm likely to want to know the MAC
to trace it to the switchport, etc. As an example, in the IETF NOC, when a
user is having an issue, one of the first things we do is figure out which
AP they are connected to, etc.


> 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.
>>
>
> The draft does already state that the client can include the client FQDN
> option, is that enough?
>

Yup, it says: "Clients MAY include other options, such as the Client FQDN
Option {{!RFC4704}}." - I don't know if that should be upgraded to a SHOULD
- it feels a little creepy / intrusive, but I may be wrong.


>   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.
>>
>
Do you have any suggested text?
I'll happily admit that I have no idea what a relay would do with a new
message - should this be "forward and then delete state", or "don't create
any state"? Do relays create state for "new" messages, or only ones that
they already understand?


>From a pure DHCPv6 protocol perspective, does a relay even need to be
> stateful? AFAICT all the protocol information that it needs to relay, in
> both directions, is contained in the DHCP packets themselves. Of course the
> relay might be performing other tasks like DHCPv6 snooping, FIB insertion
> for prefixes, etc., which are stateful, but that's a separate issue. So
> maybe we don't need to say this?
>

Apologies again to everyone for how long I've taken to get back to this
draft; I've created some PRs for issues opened by my co-authors. For the
questions here, because they were discussed onlist[0], I'm just committing
the changes and pushed a new version to the github repo .

I'd really appreciate any feedback, and letting me know if I'm on the right
track, what stupid I've done, where I've lied, etc —
https://wkumari.github.io/draft-wkumari-dhc-addr-notification/draft-wkumari-dhc-addr-notification.html

W
[0]: And because I've left this so long, and so late :-P