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

[Tim Chown <[e-mail]>]

Hi,

In-line...

> On 17 Jul 2017, at 02:52, STARK, BARBARA H <[e-mail]> wrote:
> 
> On Sun, Jul 16, 2017 at 6:25 AM, Lorenzo Colitti <[e-mail]> wrote:
> On Sun, Jul 16, 2017 at 1:20 PM, Nick Hilliard <[e-mail]> wrote:
> The self-selection addressing model does not suit the deployment
> requirements for many types of ipv6 networks, including enterprise,
> provider hosting, terrestrial access networks (e.g. docsis / gpon /
> ipoe) and others.  If the recommendation for dhcpv6 is dropped, then
> there is no recommended ietf model for operator-assigned addressing, and
> this would leave a glaring hole in the ipv6 host specification.
>  
> That's a fair opinion to hold, but the fact of the matter is that a SHOULD for DHCPv6 conflicts with RFC 7934 and RFC 7844.
>  
> We shouldn't publish a host requirements document that contradicts the host address assignment BCP and that cites RFC7844 while contradicting that document's recommendation to use stateless in preference to stateful.
>  
> Lets start with RFC 7934 it is a set of RECOMMENDATIONS for how networks should supply addresses to general purpose hosts.  First, not everything fits into that scope and even within that scope as a RECOMMENDATION that means "there may exist valid reasons in particular circumstances to ignore a particular item" [RFC2119].  So, it by no means precludes the possibility that hosts could find them on a network that is only providing addresses via DHCPv6. Therefore, a SHOULD for DHCPv6 in the host requirements still seems appropriate to me.
>  
> As for RFC 7844, it is scoped to mobile hosts that want privacy from the DHCP server, and it says "The anonymity profiles have the effect of hiding the client identity from the DHCP server.  This is not always desirable. ..."  A document that itself recognizes it's primary purpose "is not always desirable" even within it's defined scope, isn't a strong argument for changing the RECOMMENDED behavior of all host.  
>  
> <bhs> +1. RFC 6434 Node Requirements are general-purpose for all nodes on all networks. And should remain so. They should not be tailored to 3GPP networks or mass market end user networks or any other special network. RFC 7934 and 7844 are not for all nodes. BTW, many wireline access networks do not support SLAAC for address assignment to the CE Router. Which is why RFC 7084 exists -- to provide specific guidance for that specific use case. RFC 7084 does not conflict with RFC 6434. Because its use case is distinct from that of RFCs 7934 and 7844, it doesn’t conflict with them either.
>  
> Further, a "recommendation to use stateless in preference to stateful" isn't a prohibition on stateful, Until, stateful is prohibited or all networks are required to provided stateless, a SHOULD for DHCPv6 in the host requirements still seems appropriate to me.
>  
> <bhs> +1

To support Barbara’s comments above, it's worth noting that RFC7844 includes exceptions, specifically in Section 5, stating that anonymity profiles are not always desirable:

5.  Operational Considerations

   The anonymity profiles have the effect of hiding the client identity
   from the DHCP server.  This is not always desirable.  Some DHCP
   servers provide facilities like publishing names and addresses in the
   DNS, or ensuring that returning clients get reassigned the same
   address.

   Clients using an anonymity profile may be consuming more resources.
   For example, when a client changes its link-layer address and
   requests a new IP address, the old IP address is still marked as
   leased by the server.

   Some DHCP servers will only give addresses to pre-registered MAC
   addresses, forcing clients to choose between remaining anonymous and
   obtaining connectivity.

   Implementers SHOULD provide a way for clients to control when the
   anonymity profiles are used and when standard behavior is preferred.

   Implementers MAY implement this control by tying the use of the
   anonymity profiles to that of link-layer address randomization.


Tim