RE: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt

[Morizot Timothy S <[e-mail]>]

I’ve commented on this topic in the past, but will simply make one more observation on this specific point. The RFC is informational, so isn’t a matter of huge concern as it has no impact on product selection or the procurement process. If the manufacturer/developer of a host decides they don’t want to make a product they can sell to enterprises utilizing DHCPv6 only host networks (except perhaps in some very limited, restricted capacity), that’s fine. Plenty of other companies will. However, I do agree the recommendation should be updated to reflect reality, otherwise I suppose it could lead developers of such host products that DHCPv6 support is actually optional. In some environments it is. In others it is not. But then, I also believe the developers of such hosts understand their markets and are unlikely to be misled by an informational RFC.

It does, however, strike me as somewhat silly for the IETF to continue to “NOT RECOMMEND” (as I gather from the appendix of changes was the case way back in 4294) a use case that complies with the standards, has been deployed, is being deployed, and will continue to be used in the future. It’s not even a matter of whether or not connection security is deployed or neighbor tables (or arp for v4) and other data are collected from network devices. (At the sorts of organizations and networks with which I’m familiar, both are often true. There are even networks where nothing but manually configured devices are allowed and switch ports must be manually enabled.) Rather, the security monitoring and analysis processes (automated and manual) are in part built around dhcp for basic client networks. It’s a relatively small lift to extend those processes to DHCPv6. It would be a much larger lift to develop entirely new, parallel ones using different data, even though that alternative data are likely also collected and available. It’s particularly unwieldy while IPv4, with its existing processes, is in use on some or all of those networks.

Perhaps in the future, if there’s ever a compelling use case for widespread deployment of SLAAC on general purpose host data networks and IPv4 has mostly been retired from the network outside enclaves where it’s still required for one reason or another, those processes can and probably will be revisited, especially as deployed tools are updated or replaced. Until such time, I know for certain that at least on certain sorts of large enterprise networks DHCPv6-only has been, is, and will continue to be deployed and used, at least on most general purpose host data networks in the enterprise. Those companies that wish to develop general purpose host devices they can sell for use on such networks will support that use case whatever informational recommendations the IETF chooses to publish. Specialty networks for IOT devices (sensors, cameras, lighting, or whatever) are a different matter. Those sorts of things are already segregated into their own networks when using IPv4. If they have special network requirements and otherwise meet our capability requirements, those always have been and will continue to be accommodated.

The enterprise space varies a lot according to the sort of enterprise, but it’s never going to really look like a general hosting company or generic user ISP. Enterprises can and do restrict what connects and functions on their networks. Enterprise networks do not have to support every kind of device or every configuration option. And most large ones probably won’t. But many companies developing host devices would still like to sell them to large enterprises. And if they want to do so, they should certainly consider supporting DHCPv6. It seems to me the IETF recommendation should reflect that reality.

Scott

Lorenzo Colitti [e-mail]<mailto:[e-mail]> wrote:
The "SHOULD" that you quoted in rfc7934 refers to how an opinion about
people ought to run their networks, but does not conflict with the
SHOULD in 6434bis, which refers to what the IETF is proposing ought to
be supported on host devices.  These two things are very different indeed.

This document says that hosts SHOULD support DHCPv6 because operators might use it. But our current recommendations say that:

  1.  Such hosts SHOULD prefer SLAAC over DHCPv6
  2.  DHCPv6-only networks are NOT RECOMMENDED