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

[james woodyatt <[e-mail]>]

On Jul 17, 2017, at 10:47, Nick Hilliard <[e-mail]> wrote:
> [e-mail] wrote:
>> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt
>> has been successfully submitted by Nick Hilliard and posted to the
>> IETF repository.

I have reviewed this document. Its reasoning for proposing an update to RFC 7934 is unsound. One relevant excerpt from §1 Introduction should suffice to explain. The text following the excerpt is premised entirely on the bad reasoning shown below, and it can be ignored accordingly.

>>> […] The recommendations in Section 8 of this document included the text:
>>> 
>>>       Due to the drawbacks imposed by requiring explicit requests for
>>>       address space (see Section 4), it is RECOMMENDED that the network
>>>       give the host the ability to use new addresses without requiring
>>>       explicit requests.
>>> 
>>>    This text could be interpreted as recommending that IPv6 networks
>>>    should not use not DHCPv6 [RFC3736], which provides new addresses in
>>>    response to explicit requests. […]

That would be a gross misinterpretation of the recommendation. The recommendation in RFC 7934 is clearly written and does not need updating to provide more clarity about the implications for usage of DHCPv6. The clear implication of the recommendation is *NOT* that networks SHOULD NOT provide DHCPv6 services. The clear implication of the recommendation is that networks SHOULD NOT require hosts to use DHCPv6 with IA_NA/IA_TA to obtain all their addresses.

>>> 
>>>                                 […] This interpretation is based on the
>>>    fact that a host which uses DHCPv6 IA_NA or IA_TA cannot use new
>>>    addresses without requesting them from a DHCPv6 server on the
>>>    network.

That’s not a fact. In fact. Factually speaking, a host which uses DHCPv6 IA_NA or IA_TA absolutely MAY use new addresses without requesting them from a DHCPv6 server on the networks. On a related note, see how the draft makes another leap of unsound reasoning in §3 Rationale.

>>>                              […] as it formally recommends that new
>>>    addresses should be assigned without explicit requests.  This
>>>    implicitly excludes all address assignment mechanisms, including
>>>    DHCPv6, which are not handled by the host itself.

A network MAY also provide a Prefix Information Option with A=1 for the host to use SLAAC to configure them. There are additional ways for networks to configure hosts with aggregated sets of addresses, e.g. obtaining prefixs with DHCPv6 Prefix Delegation, e.g. resolving prefixes with a Distributed Node Consensus Protocol [RFC 7787], et cetera.

> Right now, the most prudent course of action would be to roll back the
> change until a proper debate has been had.  We invite WG comments on
> this doc.

For a proper debate to commence, the draft should be rewritten so that it’s reasoning about what RFC 7934 actually implies for networks using DHCPv6 is fundamentally sound. I’m not sure what such a draft would say, however, so I can’t comment about what the authors might be hoping to discuss.


--james woodyatt <[e-mail]>