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

[Bernie Volz <[e-mail]>]

Also …

Cable deployments already confirm that a single address is not being used - a prefix is delegated. There is no need for the CM and Router address to be stable (these are assigned via DHCPV6 IA_NA) and as indicated later, the stability depends on whether they remain connected and the server’s policy. There is generally a good reason for prefix assigned to a subscriber to remain stable.

What other deployments may decide is unknown, but I doubt that it will be a single address.

And, whether a server will keep giving the same client the same address is really a matter of server policy, and whether the client stays connected or not. It may also be part of the client’s policy in how it generates a DUID and whether it persists that value and for how long.

Certainly in public wifi and similar deployments, remembering each client seen is probably not scalable as lots will be one time or very infrequent visitors. Sure, you could have a server remember it for a period of time.

DHCPv6 gives the network administrator much of the control whereas SLAAC places most of the control in clients.

Also, I’m not really sure why we are arguing these points (we have both SLAAC and DHCPv6) as the draft of question is about whether clients should have the ability to notify about the address they generated via SLAAC. As Michael points out that’s building a lot of infrastructure and what benefit is there for lots of client implementations to change to do this? Having network elements that are already involved in “recording” this data (router ND caches) reporting it would seem like a far better way to go and leaves the policy where it should be - with the network administrator if they require this data - and with the assurance that it is equally recorded or not (i.e., not dependent on the client).

I know you would prefer to depreciate IA_NA, but we already discussed that (see RFC8415 bis discussion) and why it is a bad idea given its wide deployment and the desire for some.

- Bernie

> On Aug 13, 2022, at 10:25 AM, Ted Lemon <[e-mail]> wrote:
> 
> The reason that DHCPv6 IA_NA has not gotten full implementation in clients is because it can be used to force clients to use a single stable address. I know you’ve heard this said before, Bernie.
> 
> This is why I would argue for deprecating IA_NA—it threatens the whole IPv6 addressing architecture and makes it more likely that homes will wind up having single addresses as is currently the case with IPv4.
> 
> IOW this is a compromise position: people have said they want DHCPv6 address assignment because they want to track clients, not because they want to constrain them to single addresses. If that’s so, then having clients implement this behavior would address that problem without throwing the baby out with the bathwater.
> 
> On the other hand, maybe that was never the issue in the first place, in which case this proposal will force people to advocate for what they really want, and force us to have the addressing architecture discussion.
> 
> It’s really unfortunate that DHCPv6 has found itself in the position of being the place in which this battle has been fought for lo these many years, but there’s not much we can do to change that, unfortunately.
> 
> Sent from my iPad
> 
>>> On Aug 13, 2022, at 10:21 AM, Bernie Volz <[e-mail]> wrote:
>>> 
>> 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