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

[David Farmer <[e-mail]>]

So, even with IPv4, DHCP isn't completely authoritative. Static assignments
are missing. Nevertheless, many people find DHCP tracking to be
operationally sufficient. However, we both scrap ARPs out of routers and
use DHCP logging. DHCP logging provides additional information that is not
easily available from the routers even though it is not
completely authoritative.

It's only speculation, but seems like this could also be operationally
sufficient for many. However, similar to DHCP, adding to ARP information, I
believe this would provide additional information not easily available from
ND scraping of the routers, even though it is only voluntary.

Thanks.

On Mon, Sep 25, 2023 at 8:44 AM Timothy Winters <[e-mail]> wrote:

> Hi Ole,
>
> We have had some operators' interests in this solution over
> scrapping switches and routers.   I think it would be helpful to hear from
> network operators or DHCPv6 server solutions about how viable and
> deployable this solution is.
>
> ~Tim
>
> On Sat, Sep 23, 2023 at 4:08 AM Ole Trøan <[e-mail]> wrote:
>
>> 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 <[e-mail]> 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
>>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================