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

["STARK, BARBARA H" <[e-mail]>]

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

> 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'?

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

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.

> Thanks,
> 
> Dusan.
> 
> 
> 
> > -----Original Message-----
> 
> > From: STARK, BARBARA H <[e-mail]>
> 
> > Sent: Tuesday, September 04, 2018 4:35 PM
> 
> > To: Mudric, Dusan (Dusan) <[e-mail]>; Simon Hobson
> 
> > <[e-mail]>; [e-mail]
> 
> > 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