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

[Ted Lemon <[e-mail]>]

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