Re: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs-04: Enabling DHCPv6 in the enterprise networks by default, if DHCPv6 is supported on the router

You are continuing to confuse implementation and operation requirements. You are also ignoring reality...

There’s no way for a router to know whether it is deployed in an enterprise environment or not at time of manufacture. 

Further, I don’t believe for one second that ALL enterprises will require or use DHCPv6. Perhaps most, but certainly not all. 

The current situation is that implementation of DHCPv6 in the protocol stack on ANY device is optional. There is a proposal to make it mandatory on routers only. There is no proposal that I know of to make it mandatory on hosts. Any such proposal would be a major change to IPv6 architecture that I am certain would face substantial opposition. 

Therefore there is no conflict between the ID you referenced and the RFC you referenced. Your proposed change to the RFC would be nonsensical absent an across the board requirement for DHCPv6 implementation in all protocol stacks. That’s not likely to happen, nor is DHCPv6 support in Android based phones. 

Since a router can’t know at manufacture time whether it is deployed in an enterprise or not, and since it is not universally true that enterprises will want DHCPv6, it is impossible to set M and O defaults in the manner you propose.

The good news is that it’s also utterly unnecessary to do so. 

Owen

> On Sep 5, 2018, at 06:36, Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote:
> 
> Hi Barbara,
> 
>> As for the millions of IPv4 phones -- these millions of phones are not
>> connecting directly to DSL/DOCSIS/PON/3GPP access networks. They are not
>> connecting to (unmanaged) home networks and getting configuration by
>> DHCPv4. They are not connecting directly to data center networks. They're
>> definitely not connecting directly to core network routers. They *are*
>> connecting to enterprise networks. Suggesting that all routers, in every use
>> case and every scenario, must always support DHCPv6 server and provide
>> stateless configuration, just because there exist some devices in specific use
>> cases that require configuration info from DHCP, isn't reasonable.
>> 
>> If you want this specifically for enterprise routers, then perhaps you should
>> be commenting on draft-ietf-v6ops-ipv6rtr-reqs. Note that this draft does
>> require DHCPv6 support (Section 3.3, first bullet) for the routers it describes
>> (see Section 1.3 on Use and Applicability).
> 
> Good point. I am talking about the phones in enterprise environments. 
> 
> It is not clear what the current consensus is:
> https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-04#section-3.3  :
> 
> DHCPv6 is mandatory:
>   o  [I-D.ietf-dhc-rfc3315bis]: Dynamic Configuration Protocol for IPv6
>      must be supported.
> 
> or DHCPv6 is optional:  
>  o  [RFC3646]: DNS Configuration options for Dynamic Host
>      Configuration Protocol for IPv6 (DHCPv6) if DHCPv6 is supported.
> Should the last sentence be 'if DHCPv6 is enabled'?
> 
> May be 'M' and 'O' can be TRUE by default in the enterprise networks, if DHCPv6 is enabled. That way the scope of enabled 'M' and 'O' is limited to the enterprises that configure their phones using DHCPv6. Since SLAAC must be enabled and the phones can create global SLAAC addresses, the phone applications can be autoconfigured by enabling 'O' bit only (default for 'M' stays FALSE). If enterprises don't use DHCPv6 for autoconfiguration (DHCPv6 is disabled), 'O' bit should be set to FALSE.
> 
> Thanks,
> Dusan.
> 
>> -----Original Message-----
>> From: STARK, BARBARA H <bs7652@att.com>
>> Sent: Tuesday, September 04, 2018 4:35 PM
>> To: Mudric, Dusan (Dusan) <dmudric@avaya.com>; Simon Hobson
>> <linux@thehobsons.co.uk>; v6ops@ietf.org
>> Subject: RE: [v6ops] Thinking about problems in IPv6-only networks
>> 
>>>> It's arguable that a host using DHCP when the RAs say not to is in the
>>> wrong.
>>> 
>>> Agree. But if 'O' bit is not supported on hosts, hosts should have DHCPv6
>>> enabled by default. There are millions of IPv4 phones that use DHCPv4 for
>>> autoconfiguration (for phone applications), for example. When they
>> migrate
>>> to IPv6, they should get the configuration from DHCPv6 server. DHCPv6
>>> should not be disabled by default when migrating those phone to IPv6.
>> That
>>> is why I think 'O' should be TRUE by default, so the phone applications can
>> be
>>> automatically configured by DHCPv6 server. By default, phones can use
>>> SLAAC to get the addresses.
>> 
>> Hi Dusan,
>> 
>> There are millions of hosts with no DHCPv6 support. This is the case and will
>> continue to be the case. Hosts that do not support DHCPv6 client will
>> *never* have DHCPv6 enabled by default, or otherwise. Networks that are
>> primarily intended for these sorts of devices will rarely (if ever) have DHCPv6
>> enabled.
>> 
>> As for the millions of IPv4 phones -- these millions of phones are not
>> connecting directly to DSL/DOCSIS/PON/3GPP access networks. They are not
>> connecting to (unmanaged) home networks and getting configuration by
>> DHCPv4. They are not connecting directly to data center networks. They're
>> definitely not connecting directly to core network routers. They *are*
>> connecting to enterprise networks. Suggesting that all routers, in every use
>> case and every scenario, must always support DHCPv6 server and provide
>> stateless configuration, just because there exist some devices in specific use
>> cases that require configuration info from DHCP, isn't reasonable.
>> 
>> If you want this specifically for enterprise routers, then perhaps you should
>> be commenting on draft-ietf-v6ops-ipv6rtr-reqs. Note that this draft does
>> require DHCPv6 support (Section 3.3, first bullet) for the routers it describes
>> (see Section 1.3 on Use and Applicability).
>> Barbara
>> 
>> I
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops