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

[Ole Trøan <[e-mail]>]

On 12 Sep 2023, at 02:57, Lorenzo Colitti <lorenzo=[e-mail]> wrote:



On Tue, Sep 12, 2023 at 2:09 AM Ole Trøan <otroan=[e-mail]> wrote:

IPv6 host configuration behavior is already complicated. This proposal adds yet another dimension. With any new mechanism, there’s the issue of how to deal with legacy hosts. The document appears silent on this. 

There is nothing we can do about legacy hosts obviously. The security considerations section says this message is optional and that networks cannot rely on it because the device might not send it or the message might be lost. But it will work well in an environment where the operator controls the devices. How about tweaking the existing text in section 6 to clarify?

====

On its own, it is not intended to be a strong security access mechanism and networks cannot rely on its use unless they control the devices that connect to the network.

====

 

The proposal seems to suggest that hosts should always try to register their addresses. With hand wavy text suggesting it should be possible to disable. Are we now going to see yet another flag in RA’s asking hosts to be quiet? Should it really be enabled by default?

There is already a control mechanism: hosts will not send these packets if the M and O bits are set to 0. So if there is no DHCPv6 server on link, the hosts will be quiet.

I must be missing something here regarding expected host behavior. If the M-flag is set the host will do normal dhcp surely?

What if there is no A-flag in PIO or no PIO, then the client should certainly not run the new address notification protocol. 

It’s unclear from the document what expected client behavior is and how it interacts with the normal dhcp. 

If the server supports the new packet type, then the additional traffic caused by hosts implementing this proposal is similar to the additional traffic that hosts would cause if they implemented stateful DHCPv6. If hosts only register one address this proposal causes less traffic, because refreshes are recommended at 80% lifetime instead of the 50% lifetime recommended by RFC 8415. (If the DHCPv6 server doesn't support rapid commit, then this proposal is much cheaper because stateful DHCPv6 is a four-packet exchange but this is just two.) If the client registers two addresses (one stable and one privacy), and the server does support rapid commit, it's a bit more.

There will be more traffic if there are clients that implement this proposal but servers have not been updated to send the required reply message. Once this specification is published, we expect servers to implement this message because it is extremely simple for a server to do so (basically, just look at the packet, and log the contents). It's possible to 

 

The draft seems to be silent about the elephant in the room. The problem the draft seems to solve is already perfectly solved by normal DHCPv6 address assignment. Which is already widely implemented and deployed. 

It's true that DHCPv6 is widely implemented, but on the other hand, this proposal is more suited to many networks than stateful DHCPv6. Many networks (pretty much all networks serving clients, actually) don't really need stateful address allocation, they just need the ability to do forensics and know which devices were using which addresses. This proposal is much simpler than stateful DHCPv6 - RFC 8415 is 154 pages long and this is just a handful. Also, DHCPv6 is very hard to use correctly in networks that can be renumbered such as home networks or mobile hotspots, because updates require the client to ask again and reconfigure is very difficult to deploy.

Finally- we need a way to provide forensic abilities for SLAAC addresses. The IETF does not recommend running DHCPv6-only networks for general purpose devices (RFC 7934 section 8.2), so SLAAC will be in use even on networks that support stateful DHCPv6 (e.g., because implementations will use privacy addresses in preference to DHCPv6 addresses). Network operators that want to track usage of SLAAC addresses don't have a tool to do so, and that is a gap in the IPv6 deployment story that we are trying to fill.

What the IETF does or doesn’t recommend I would be a little careful in asserting. Especially referencing a document you have yourself authored. :-)

Regarding dhcpv6. I implemented a functional dhcpv6 server last week in a couple of hundred lines of code. It’s a stateless server, using algorithmic mapping to assign addresses. Meaning that in this example your proposal would require much more state than normal dhcp. 

Both SLAAC and DHCPv6 can work well with controlled renumbering. Neither one of them handle flash renumbering well. 

If a network needs address tracking:

1) use DHCPv6 address assignment 

2) if not use savi/fhs with tracking from the network 

It’s not obvious to me that providing yet another way to do the same thing is good for IPv6. 

O.