Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by September 13, 2023

[Ole Trøan <[e-mail]>]

Thanks Tim,

I do wonder if it’s not worth doing a complete retake of this proposal.

If the operator requirement is to know which address has been in use in the network by which device at any point in time, then that cannot be guaranteed with this mechanism. Existing first-hop security mechanisms in switches and routers would be much more robust. 

O. 

On 22 Sep 2023, at 22:22, Timothy Winters <[e-mail]> wrote:



Hi Everyone,

The working group had some great discussion about this document during the WGLC.    Based on the discussion it didn't pass WGLC at this time.  It will mostly need another round of discussion and potentially a revision based on those discussions. 

Additionally, Bernie and I discussed and think it's a good idea to wait to ask IANA for a early code points until we have passed WGLC.

Regards,

Tim

On Thu, Sep 14, 2023 at 3:16 PM Bernie Volz <[e-mail]> wrote:

An interesting question may be do we need new messages at all? Using Information Request / Reply with new option is perhaps cleanest?

- existing clients can do what they do today

- existing servers (and relays or other snoopers) will not know option so ignore (hopefully silently)

- existing servers only see “more” Information-Request for clients not supporting this new work when enabling O-bit to request address registrations

- “new” clients that do SLAAC when O-bit set and did support Information-Request can do initial registration in first message (or send when address assigned) and do periodic updates (perhaps even ask for other options via ORO to refresh information) … they may actually have no more messages than today (well, except if they have multiple SLAAC addresses as need to use a separate Information-Request for each) … they could also decouple previous and new behavior at increase in traffic.

- registration only clients that did not use Information-Request previously add new traffic … which is exactly what we want

The only downside is it kind of overloads Information-Request as it is now also a client to server communication. Though the client already can send information to server in Information-Request (user class, vendor class, vendor information, …). And, we could say the client is asking whether the server supports registration (by getting new option in Reply).

Note: It may be worth thinking about making use of the new “registration address” option’s encapsulated options field if client wants to send other information (such as fqdn). This isn’t really bad as this is likely address specific and any server that wanted to do something with this data needs updating anyway. This keeps all of the registration information hidden from those devices that don’t that registration option.

Anyway, this is now a very good reason to hold off on early assignment for message types (and likely say WGLC failed).

- Bernie (from iPad)

On Sep 14, 2023, at 2:32 PM, Bernie Volz <[e-mail]> wrote:

Hi:

(Just catching up and responding to this as was asked specifically…there could have been more I haven’t yet read.)

8415bis only prohibits IA options in Information-Request

16.12.  Information-request Message

   Clients MUST discard any received Information-request messages.

   Servers MUST discard any received Information-request message that
   meets any of the following conditions:

   *  the message includes a Server Identifier option (see
      Section 21.3), and the DUID in the option does not match the
      server's DUID.

   *  the message includes an IA option.

I wonder however if having an Address Registration option specifically would be better (the Information-Request and new registration request could use this instead of IA_Addr option). This might avoid an overly aggressive server or relay that checks the Information-Request or its Reply for options from doing odd things if it sees the IAAddr. If we’re trying to make things safe, this may be best. Note also that it may help other devices in the path that may want to snoop for this data. (But it could have downside if any “options” are developed as then those specifications would need to determine if they are also allowed in this new address option).

On a separate note, one issue the current draft may need to document and is a consideration is that when O-bit (RA) and A-bit (PIO) is set, a registration only server should really support Information-Request as it will also get lots of those from clients that support DHCPv6 - it may just send back a pretty empty Reply.

By using Ted’s suggestion of using Information-Request, it would be natural for registration only to be implemented at least sufficiently to send a well formed Reply even when not address registration request.

It seems like a clever idea to use Information-Request at least for initial determination of support.

- it avoids extra packets.

- client could honor server’s INF_MAX_RT to reduce frequency of probing (likely periodic probing is not a bad idea).

- Bernie (from iPad)

On Sep 14, 2023, at 11:29 AM, Lorenzo Colitti <[e-mail]> wrote:



On Fri, Sep 15, 2023 at 12:22 AM Ted Lemon <[e-mail]> wrote:

What I think would be most expedient (if we must use DHCP to probe for support of address registration) would be to do the first address registration as an information request with the additional information in the information request, using the source address being registered. If the reply that comes back confirms the address registration, then all subsequent address registrations on this link would be sent as address registrations.

Well, but if we can come up with a reasonable way to represent an address registration using an information-request packet, then why not make all registrations be information-request packets?

+Bernie Volz any thoughts on using information-request and reply messages, instead of the new addr-reg-inform and addr-reg-reply messages currently defined in the draft?

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg