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

["[e-mail]" <[e-mail]>]

All,

My $.02. I am coming to this as someone who deals with DHCP and IPAM products daily. I am tasked with regularly solving this problem for Network Operators as my job.

It sounds like what is being asked for is more of an IP Tracking / IPAM solution. I agree with David Farmer. David’s reply is what I hear a lot from Large Network Operators: tracking DHCP lease information can be a piece of the solution and is hardly sufficient for any real IPAM / IP Tracking solution. In any comprehensive solution, some form of network discovery (usually something that talks to the L2/L3 infrastructure) is needed to have a remotely complete picture (ARP scraping in Davids’s example). In short, DHCP is a helpful part, but only a part. 

Maybe we do a better job of saying what it can and can’t do and that it can be used as part of the overall solution of tracking IPv6 assignments, but it is not the whole solution. The products that currently do IP tracking are complex and typically a mix of DHCP and Network Discovery. Simply adding this mechanism to DHCPV6 isn’t going to solve the issues these multi-function IPAM solutions do. As stated earlier, and I think was a critical point (sorry, I forget who said it) is that we (DHCP services) are not in the path. Because of that, we are not positioned to be responsible for better tracking IPv6 address usage, but we could chip in helpful information. Today, that is lease information on the V4 side, and if we could get parity in adding in v6 address information based on the v6 modalities, that would be great. 


My final issue and what leaves me on the fence is complexity. If we aren’t solving the bigger problem and are just helping with providing some info, then is what we are discussing reasonably simple enough to implement so that it will be used? When we start to overload flags and expect clients to do anything new, I tend to think we have gone too far for what it provides. If it is harder to implement than it is to write a simple router scraper, then to me, we haven’t provided value to the Network Operator.

As for the draft itself, I am stuck on whether it has merit. I am not solidly in either camp, so I have stayed quiet. I guess I feel like it could be a helpful part of a solution, but we shouldn’t represent that it does anything more than provide some additional data points. We must keep it simple enough that it has a likelihood of actually being implemented, as there are both products out there and so many homespun scripts that already do a better job of this than we can with DHCP.

</$.02>


Rob

Robert Nagy
- - - - - - - - - -
Senior Dive Master | Deep Dive Networking Inc
p: 408.480.5133 | aim/icq: 95091173 | e:[e-mail]
www.deepdivenetworking.com

> On Sep 25, 2023, at 7:13 AM, David Farmer <farmer=[e-mail]> wrote:
> 
> 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Sep 15, 2023 at 12:22 AM Ted Lemon <[e-mail] <mailto:[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 <mailto:[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] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>>> _______________________________________________
>>>> dhcwg mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 
> -- 
> ===============================================
> David Farmer               Email:[e-mail] <mailto:[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
> ===============================================
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg