Re: [dhcwg] draft-wkumari-dhc-addr-notification and the secops problem

[Bernie Volz <[e-mail]>]

I understand this “control” difference. But why should a client care whether it gets address A or B? If there is a requirement to provide a client a specific address, DHCPv6 servers support reservations (typically based on client id, DUID, but there are other possibilities). And clients can suggest addresses, and a server generally could allow that address to be used unless there is a specific conflict?

- Bernie

> On Aug 13, 2022, at 10:14 AM, Ted Lemon <[e-mail]> wrote:
> 
> If a client wants to do DNS registration, the DNSSD service registration protocol might be a good option: https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/
> 
> As to why not use DHCPv6 IA_NA, the answer is that this allows the DHCP server to control the client’s address, whereas registering the address doesn’t give the DHCP server that sort of control. This is a significant difference, and is why a client implementation might choose to include registration, but not IA_NA allocation.
> 
> Sent from my iPad
> 
>>> On Aug 13, 2022, at 7:43 AM, Bernie Volz <[e-mail]> wrote:
>>> 
>> 
>> These are great points Michael.
>> 
>> For the earlier (circa 2014) draft that was similar, draft-ietf-dhc-addr-registration, the reason a client would have implemented it was to get its information in DNS (as there would presumably be a reason it needed this, such as to allow other devices to communicate with it). With this new draft, there is really zero benefit to the client. I’m not promoting a shift to this DNS registration as that had its own issues.
>> 
>> If you want “notification”, why not just require DHCPv6 for address assignments? If you don’t care or are using other tools, use SLAAC. Do we really need something in between?
>> 
>> - Bernie Volz
>> 
>>>> On Aug 12, 2022, at 9:03 PM, Michael Richardson <[e-mail]> wrote:
>>>> 
>>> 
>>> This document seems to require many changes to many systems.
>>> Do I hear that Google is willing to do this for Android?
>>> I am very enthusiastic about having better information.
>>> 
>>> It works only if all the devices implement it, it's not that useful until all
>>> the devices do it.  Until that happens, then it's completely useless to the
>>> helpdesk.
>>> It requires updates to DHCPv6 server, assuming that there is one, which if
>>> you are using SLAAC... you probably don't even have one.
>>> It does not require updates to the core routers, which is the only
>>> interesting part.  {But, in homes and small offices, and remotely supported
>>> small offices with a b2b ISP..., that's all the same openwrt box.}
>>> 
>>> It seems that if one already had an SNMP or YANG/NETCONF feed from the
>>> routers for the Neighbor Entry Cache, that feeding that into the "database"
>>> would be good.
>>> 
>>> Warren eventually says that he thinks this would be *more* complicated, and I
>>> read his slide 10.... and come-on.   You hacked up something that needs to be
>>> clearly coded correctly in the router.  Yes, it's chatty, but it doesn't need
>>> to tell about every state transition.
>>> BUT, even if it did, who cares if you can't read it scrolling on your screen.
>>> That's what the networking monitoring system is for.  Actually, I think you
>>> just proved how easily this could be done even without code changes to the routers.
>>> 
>>> So, I don't think that I agree at all.  The best part about linking it to the NCE
>>> is that if the NCE is bad, overwhelmed or has been forged, then the client
>>> machine probably doesn't get connectivity anyway.  There is some fate sharing here.
>>> 
>>> Another way would be to send the proposed DHCPv6 message along the DHCPv6-relay
>>> path.  This is very much akin to the Accounting records that radius sends.
>>> Doing it this way links the v6 address more directly to the MAC address,
>>> while not requiring the host to actually know what it is doing.
>>> 
>>> As Lorenzo says in the chat, it needs to be tied in "whatever" L2 security
>>> mechanisms they already have, but I'm not really sure how this should involve
>>> the client system.
>>> 
>>> And...if I was going to upload all the source code, the first thing I'd do is send
>>> one of these messages saying that I'm either the CEO, or the new hire, and then do it.
>>> 
>>> --
>>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>>           Sandelman Software Works Inc, Ottawa and Worldwide
>>> _______________________________________________
>>> dhcwg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg