Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

[james woodyatt <[e-mail]>]

On Jul 18, 2017, at 15:59, Nick Hilliard <[e-mail]> wrote:
> 
> However, there is no basis for you to assert that there was broad
> agreement that IA_NA was a bad choice and less still to codify that
> into a statement which, in your opinion, creates an IETF recommendation
> not to use DHCPv6 IA_NA.

Once again, RFC 7934 does not entail that, and the only people in the working group who are claiming that it does— despite its otherwise clear language— are the authors of I-D.hilliard-v6ops-host-addr-update. There is no recommendation in RFC 7934— explicit or implicit— against the use of DHCPv6 IA_NA in conjunction with other methods for hosts to obtain addresses without making explicit requests to the network.

There is a bullet list in §4 "Problems with Restricting the Number of Addresses per Host” that goes into some detail about some (not all) of the problems with networks where hosts MUST acquire IPv6 interface addresses with explicit requests to the network, e.g. using DHCPv6 with IA_NA or IA_TA. Doing *that* is explicitly NOT RECOMMENDED in §8 “Recommendations” of RFC 7934, and it is a fact that most IPv6 network deployments conform to this best current practice accordingly, and there are many additional well-known problems with diverging from that practice that were not documented in RFC 7934.

It’s not at all clear to me what is the purpose of this draft, but if I understand correctly, then its objective is to propose that IETF Best Current Practice include general purpose Internet networks where general purpose hosts acquire IPv6 interface addresses only by using DHCPv6 IA_NA requests to obtain addresses from a constrained pool one at a time. I have a lot of difficulty seeing how that makes any sense given the clear reasoning provided in RFC 7934 for the recommendation against it.


--james woodyatt <[e-mail] <mailto:[e-mail]>>