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

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 5 Sep 2018 13:36:04 +0000

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 <[email-masked]>
> Sent: Tuesday, September 04, 2018 4:35 PM
> To: Mudric, Dusan (Dusan) <[email-masked]>; Simon Hobson
> <[email-masked]>; [email-masked]
> 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

---

From: Owen DeLong <[email-masked]>
Date: Wed, 5 Sep 2018 07:07:49 -0700

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) <[email-masked]> wrote:
> 
> Hi Barbara,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Timothy Winters <[email-masked]>
Date: Wed, 5 Sep 2018 10:14:00 -0400

I would also mention that IPv6 nodes requirements (
https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-09) updates have
DHCPv6 is a SHOULD in all IPv6 nodes.

~Tim

On Wed, Sep 5, 2018 at 10:09 AM Owen DeLong <[email-masked]> wrote:

> 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.
>
> > 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.
> >

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 5 Sep 2018 14:53:11 +0000

Hi Dusan,
Thanks for changing the subject line so draft-ietf-v6ops-ipv6rtr-reqs-04 authors are alerted to comments on their draft.
More comments in-line.
Barbara

> https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-04#section-3.3  
> DHCPv6 is mandatory:

The first requirement clearly makes DHCPv6 support mandatory. So I agree the "if" clause in the DNS requirement is confusing. My recommendation to the draft authors would be to delete "if DHCPv6 is supported" from the DNS Configuration requirement. This language disparity may have come about because earlier drafts made DHCPv6 support optional. I do not believe the last sentence should be "if DHCPv6 is enabled", and don't think that was the intent.
 
> 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.

Since enabling DHCPv6 and providing DHCPv6 DNS options (and SIP configuration options) requires active configuration in many enterprise environments (especially of the strings to include in those options), I think it would be highly inappropriate to recommend routers set either M or O to 1 by default. Enterprise network administrators need to be expected to do their jobs and properly administer (and configure) their networks. We need to make sure the equipment they get provides them with the tools (i.e., includes the needed functionality). 

If you wanted to suggest that "a router with RA enabled MAY automatically set O=1 when DHCPv6 is enabled (on the same router) with at least one non-address-assignment option", that might work. But where the router doing RA has no knowledge of the existence of any enabled DHCPv6 server, it would be highly inappropriate for M or O to be defaulted to any value other than zero. The enterprise network administrator needs to be expected to have some understanding of RA M and O bits if they are deploying IPv6 in their network. It would also be good if they knew whether their "IPv4 phones" also supported IPv6 before expecting these phones to get any configuration information, whatsoever, from RA or DHCPv6.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Sep 2018 21:01:10 +0900

> or use DHCPv6. Perhaps most, but certainly not all.

+1. Ours doesn't.

---

From: Tim Chown <[email-masked]>
Date: Thu, 6 Sep 2018 14:24:36 +0000

> On 6 Sep 2018, at 14:01, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 

And the requirement/use of configuration method, especially at a university campus, may vary between managed desktops and WiFi/eduroam where BYOD is the norm. 

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Sep 2018 08:33:53 +1200

> And the requirement/use of configuration method, especially at a university campus, may vary between managed desktops and WiFi/eduroam where BYOD is the norm. 

If you base admission to the wired network on registered MAC addresses, which
is quite common, there seems to be no particular reason to waste resources
on DHCPv6 even for managed devices.

   Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 6 Sep 2018 17:25:29 -0500

On Thu, Sep 6, 2018 at 3:33 PM, Brian E Carpenter <
[email-masked]> wrote:

> >> Further, I don’t believe for one second that ALL enterprises will
> require or use DHCPv6. Perhaps most, but certainly not all.
> >>
> >> +1. Ours doesn't.
> >
> > And the requirement/use of configuration method, especially at a
> university campus, may vary between managed desktops and WiFi/eduroam where
> BYOD is the norm.
>

Well not entirely true. It is common to base admission on registered MAC
addresses. However, if you also want a strong binding between MAC address
and IP address to be enforced with SAVI then DHCPv4 or v6 is still useful.
If you use SLAAC you really only have a First-Come-First-Serve(FCFS)
binding methodology SAVI. FCFS will work in a lot of cases but it is not as
strong of a binding as DHCP.

We have a broad set of tools for a broad set of environments. Some tools
are appropriate in some environments and other tools are not. IPv6 needs to
work in every situation, from wide-open wifi, as in free love wifi, to a
nuclear control room and most networks are someplace in between those two.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================