Subject: [v6ops] Making RDNSS a MUST?

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Mar 2017 18:08:12 -0500

Given the discussion today on draft-gont-v6ops-host-configuration and
draft-ali-ipv6rtr-reqs , I'm wondering if we might find consensus to say
that host and router implementations MUST implement RDNSS.

The argument would be that:

   - It provides a way of configuring DNS servers that will work on every
   compliant implementation, resolving the interoperability problems noted
   in draft-gont-v6ops-host-configuration
   - Nodes MUST already support SLAAC (RFC 6434 §5.9.2), and once SLAAC is
   implemented, adding support for RDNSS is fairly simple

This could be either in a v6ops BCP or in the update of the node
requirements that is being edited by Tim.

Thoughts?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Mar 2017 18:11:05 -0500

> Thoughts?

I don't know how much value this work has in the short term, but in service of the long term I think it's a good idea to do it.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 29 Mar 2017 18:12:27 -0500

+1

I will say that updating the node requirements will make it, as the routers must also bound to those requirements, right? So we can avoid one more new document …

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Lorenzo Colitti <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 29 de marzo de 2017, 18:08
Para: "[email-masked] WG" <[email-masked]>
Asunto: [v6ops] Making RDNSS a MUST?

    Given the discussion today on draft-gont-v6ops-host-configuration and draft-ali-ipv6rtr-reqs , I'm wondering if we might find consensus to say that host and router implementations MUST implement RDNSS.
    The argument would be that:
    
    * It provides a way of configuring DNS servers that will work on every compliant implementation, resolving the interoperability problems noted in draft-gont-v6ops-host-configuration
    * Nodes MUST already support SLAAC (RFC 6434 §5.9.2), and once SLAAC is implemented, adding support for RDNSS is fairly simple
    
    This could be either in a v6ops BCP or in the update of the node requirements that is being edited by Tim.
    
    Thoughts?

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 Mar 2017 23:19:00 +0000

On 30 Mar 2017, at 00:11, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 29, 2017, at 6:08 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Thoughts?

So in the slot in 6man tomorrow for RFC6434-bis discussion we’re asking the question as to whether RFC8106 support should be a MUST in the bis document (its predecessor RFC6106 is currently a SHOULD).  We’re also suggesting the -bis document becomes a BCP, having been Informational in its last two versions, and its first version having been published 11 years ago.
(See https://www.ietf.org/proceedings/98/slides/slides-98-6man-rfc6434-bis-ipv6-node-requirements-update-00.pdf)

We could also add something within the Router Functionality section (Section 12) about router-side support, or that could fall into John’s Router Requirements document, draft-ali-ipv6rtr-reqs-02.

Personally, I fully support the idea, however we publish it. As stated in v6ops it won’t fix existing hosts, but it will have a desirable long-term effect.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 02:37:16 +1300

> that host and router implementations MUST implement RDNSS.

I know what this means for hosts. For routers, what exactly does "implement"
mean?  Assuming the router code is capable of including RDNSS in RAs, does
it mean:

1. The code knows how to find the DNS server in order to construct the RA.
or
2. Somebody or something has to configure the router with the DNS server address.
?

That said, I support the idea.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Mar 2017 13:59:34 +0000

> On 30 Mar 2017, at 14:37, Brian E Carpenter <[email-masked]> wrote:
> 

So as one method there is some work starting on adding this capability to the netconf routing submodule from RFC8022 (extending the variables defined in section 5.4).

Tim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Mar 2017 10:05:21 -0500

> 2. Somebody or something has to configure the router with the DNS server address.

This probably depends on the router.   For CE routers, the router might advertise itself as the DNS recursive resolver, and use the resolver it got from DHCP PD as _its_ recursive resolver.   For infrastructure routers, either it has to be configured automatically using DHCP, or automatically using a provisioning system, or manually.   I think that's too painful for us to specify, but we can certainly specify how CE routers behave.

---

From: Simon Hobson <[email-masked]>
Date: Thu, 30 Mar 2017 16:22:21 +0100

> This probably depends on the router.   For CE routers, the router might advertise itself as the DNS recursive resolver, and use the resolver it got from DHCP PD as _its_ recursive resolver.   For i…

It seems obvious (to me at least) that it should just be specified that it must be provided. By all means offer *suggestions* as to various ways the information may be obtained by the router, but that is not really relevant. ie specify the "what", not the "how".

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 04:23:12 +1300

> This probably depends on the router.   For CE routers, the router might advertise itself as the DNS recursive resolver, and use the resolver it got from DHCP PD as _its_ recursive resolver.   For i…

Agreed. I just want the semantics of the word 'implement' to be crystal clear. Something like

MUST have the capability to send RAs with RDNSS, and MUST have a mechanism for discovering
or configuring the appropriate DNS server address.

   Brian

---

From: "Russ White" <[email-masked]>
Date: Thu, 30 Mar 2017 10:29:49 -0500

> Given the discussion today on draft-gont-v6ops-host-configuration and draft-
> ali-ipv6rtr-reqs , I'm wondering if we might find consensus to say that host
> and router implementations MUST implement RDNSS.

I'm happy enough to include it -- it seems like a good idea to me. 

😊 /r

---

From: Jen Linkova <[email-masked]>
Date: Thu, 30 Mar 2017 17:39:54 +0200

>> that host and router implementations MUST implement RDNSS.

Yes, very good idea.

> mean?  Assuming the router code is capable of including RDNSS in RAs,

I believe it is exactly what 'support' means in this case.
>does

It depends. Routers MUST be capable of sending RDNSS info in RA if DNS
information is available for the routers somehow (via static or
dynamic configuration - it includes the case when the router is
configured as a DNS server itself).

Actually it is the same for RA. The code needs to know where to find a
list of prefixes to construct RAs (like DHCP-PD) or somebody/something
has to configure the router with the list of prefixes to be sent in
RAs...

-- 
SY, Jen Linkova aka Furry

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Mar 2017 16:56:20 +0100

> I'm happy enough to include it -- it seems like a good idea to me. 

i don't think this is appropriate or even an especially good idea.  It's
the usual reason: RAs are normally handled at kernel level, meaning that
it may not be reasonable or possible to interact with the user level
configuration of dns settings.  This seems to be a problem on some
operating systems, at least one of which has a globally substantial
install base.

I'd be happy with something the document could state that the host MUST
have a mechanism to automatically be assigned DNS settings (via e.g.
rdnss or dhcpv6).

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Mar 2017 11:02:58 -0500

On Thu, Mar 30, 2017 at 10:56 AM, Nick Hilliard <[email-masked]> wrote:

> This seems to be a problem on some operating systems, at least one of
> which has a globally substantial install base.
>

I suspect we'll find that that problem will be resolved soon.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Mar 2017 05:18:33 +1300

> operating systems, at least one of which has a globally substantial

That sounds like an o/s that would need fixing to support this new
requirement.

> have a mechanism to automatically be assigned DNS settings (via e.g.

Excuse me, but that says nothing useful. The reason for requiring both
is because we don't know in the abstract which mechanisms the host will
encounter and we want hosts to work wherever they happen to be.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 30 Mar 2017 21:24:00 +0000

Hi,

> On 30 Mar 2017, at 16:23, Brian E Carpenter <[email-masked]> wrote:
> 

It sounds like this is the spirit we want to achieve, i.e. without specifying the mechanism. And assuming it’s a router that needs to send RAs on a given interface.

We could add words like this to Section 12 of 6434-bis, and sync that with draft-ali-ipv6rtr-reqs-02, which Russ seems happy to do.

We also then add the MUST for hosts/clients.

But what about stateless DHCPv6 in support of determining the available DNS resolvers?  At present RFC6434 just says "An IPv6 node can use the subset of DHCP (described in RFC3736) to obtain other configuration information.”  Do we leave that as is? I have heard a couple of people suggest there should be stronger words there, but equally views the other way.  On that basis, leaving as is would be the default path.

Tim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Mar 2017 17:14:14 -0500

We only need to require one mechanism. DHCP can be for devices that need
more info on networks that provide it.

On Mar 30, 2017 4:24 PM, "Tim Chown" <[email-masked]> wrote:

> >> This probably depends on the router.   For CE routers, the router might
> advertise itself as the DNS recursive resolver, and use the resolver it got
> from DHCP PD as _its_ recursive resolver.   For infrastructure routers,
> either it has to be configured automatically using DHCP, or automatically
> using a provisioning system, or manually.   I think that's too painful for
> us to specify, but we can certainly specify how CE routers behave.
> >
> It sounds like this is the spirit we want to achieve, i.e. without
> specifying the mechanism. And assuming it’s a router that needs to send RAs
> on a given interface.
>
> We could add words like this to Section 12 of 6434-bis, and sync that with
> draft-ali-ipv6rtr-reqs-02, which Russ seems happy to do.
>
> But what about stateless DHCPv6 in support of determining the available
> DNS resolvers?  At present RFC6434 just says "An IPv6 node can use the
> subset of DHCP (described in RFC3736) to obtain other configuration
> information.”  Do we leave that as is? I have heard a couple of people
> suggest there should be stronger words there, but equally views the other
> way.  On that basis, leaving as is would be the default path.
>
> Tim

---

From: Doug Barton <[email-masked]>
Date: Thu, 30 Mar 2017 20:17:24 -0700

> that host and router implementations MUST implement RDNSS.

No.

People who like it can implement it, people who don't, shouldn't have to.

It really gets tiresome repeating the same arguments for over a decade. 
Let SLAAC be what it is, and let DHCP be what it is.

Further, this seems like more fuel to add to the "You must implement 
SLAAC" fire, and there are still many of us who long for a day when we 
can have a DHCP-only network and still be considered "compliant."

Discussing it as an option is great. Making it mandatory is the wrong 
way to go.

Doug

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Mar 2017 22:39:03 -0500

On Mar 30, 2017 10:17 PM, "Doug Barton" <[email-masked]> wrote:

No.

Is there an actual argument in here that I failed to find that supports
this assertion?  Or is it just your opinion that it

  is the wrong way to go.

?

---

From: Simon Hobson <[email-masked]>
Date: Fri, 31 Mar 2017 08:18:12 +0100

> People who like it can implement it, people who don't, shouldn't have to.

But that is the whole problem !
As referenced some time ago, in the real world there is a problem where there are two ways of providing the information, and two ways of getting it. If router only does A and device only does B then device doesn't get DNS info; similarly if router only does B and device only does A then device doesn't get DNS info; in either case the problem is that you've connected a device to an IPv6 network and "it doesn't work".
SPecifically, in Microsoft's case, they found that they really did have routers where "people who didn't want to, didn't" with one option; and clients where "people who didn't want to, didn't" with the other option. As a result, IIRC, they had to keep DHCP4 running just to provide essential information to allow IPv6 only clients to work !

To avoid this, we either have to mandate that routers MUST do both A and B; or we have to mandate that devices MUST do A and B; or as it being done here, mandating that routers MUST do A on the basis that all devices already do A.
What it doesn't do is mandate that a network admin MUST leave it turned on if he doesn't want it - but then the admin will have to deal with devices that only do A and so don't support B.

The alternative is to mandate that both routers and other devices MUST support B; or both routers and other devices must support both A and B. I've seen some pushback (similar to yours, but with more technical justification) against mandating support for B (DHCP6) - mainly in small footprint devices which don't have the luxury of space for the code and the memory needed to run it.

Personally I'd prefer DHCP - but then I've only ever worked on "small" networks where I'm managing (or at least have a hand in) both the network stuff (routers) and the services (DHCP and DNS). I've never quite seen the argument for network and DHCP being separated to the extent that DHCP shouldn't provide DNS info or even prefix info - I find the concept of a network where one team can fundamentally change something like the list of prefixes (or subnets in IPv4 land) without reference to the people who manage services and devices on that network.

But if things are going to move forward, there has to be a "standard" setting a minimum requirement so that devices will work when plugged in - at the moment there isn't that.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Mar 2017 12:22:43 +0200

>more info on networks that provide it.

I think that in this particular case we should either mandate implementation
of a mechanism or formally deprecate it. It seems that there are two camps
that don't want to interoperate. 

If we can live without RFC-3646 then we should kill it.

As a middle ground, we can tie it to stateful DHCP.

I.e, a system that doesn't support address assignment through stateful
DHCPv6 MAY leave out DNS configuration through stateless DHCP and instead
MUST support RDNSS. Systems that do support stateful DHCPv6 MUST
(or SHOULD) support the DHCP DNS option and also MUST support RDNSS.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 31 Mar 2017 12:09:09 +0100

Simon Hobson wrote:
> But if things are going to move forward, there has to be a "standard"
> setting a minimum requirement so that devices will work when plugged
> in - at the moment there isn't that.

it's probably fair to assume that everyone on this list understands the
underlying technical issues.

The problem is that the primary motivation for this proposal is not
technical but political: namely the point blank refusal of specific
companies - on policy grounds - to implement dhcpv6 in their host
stacks, which as a side effect has caused serious deployment problems
for end users on production v6 networks.

As the ipv6 deployment problems that this is causing for end user sites
can no longer be ignored, it needs to be fixed.  There are several ways
to handle this, including:

1. waiting for vendors and operators to support RDNSS at the router
stack level

2. take a longer term approach of fixing the current limitations in
dhcpv6 which currently make it a politically unfavourable tool to use
for host autoconfig, then supporting dhcpv6 in the host stack

3. using the IETF policy process as a stick with which to beat everyone
else into compliance with your own internal policies, disregarding the
consequences - often scorched earth - for the rest of the v6 internet.

Given the extensive practice of option #3 on v6ops, 6man and dhc in
relation to SLAAC vs DHCPv6, I'm inclined to think that this will be the
inevitable outcome of MUST for RDNSS, and that it will be used as
ammunition in future both to shout down and block future consensus on
dhcpv6 protocol development and to force vendors and operators down one
particular protocol deployment path.

I'm genuinely sad to feel it necessary to say this, but I think it needs
to be stated explicitly.

Nick

---

From: Simon Hobson <[email-masked]>
Date: Fri, 31 Mar 2017 12:25:51 +0100

> I'm genuinely sad to feel it necessary to say this, but I think it needs

Indeed. I was composing a response to Philip's last message - but this puts it better than I was.

I don't see how you can deprecate SLAAC+RDNSS - otherwise there would be just too many problems.
If you mandate RDNSS then as you say, that will be seen as an excuse to "cripple" DHCP.
So there is merit in mandating a certain minimum feature set that includes RDNSS in all routers and clients, and also DHCP in all clients (a router doesn't need to support DHCP as long as there is a server or relay on the segment). I can see this latter option being another political hot potato !

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Apr 2017 01:28:02 +1300

Doug,
> People who like it can implement it, people who don't, shouldn't have to.

The word "implement" is hopelessly ambiguous.

I agree that a network operator should be free to choose whether they
manage hosts via DHCPv6 or not. But that is not what we are talking
about when we say "implement" in this thread, IMHO. So try this:

"People who like it can deploy it, people who don't, shouldn't have to."

As far as a vendor or open source developer is concerned, the suggestion
is that they MUST include code for both methods. I'd be a bit more precise
and add that they MUST both be enabled by default in hosts, and at least one
MUST be enabled by default in routers, and they MUST be individually configurable
on or off in all nodes.
 
> can have a DHCP-only network and still be considered "compliant."

And that's why the wording needs to be very careful and probably not use
the ambiguous word "implement" at all.

   Brian
 
> .

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Mar 2017 07:39:46 -0500

Philip, forgive me for holding your feet to the fire here, but you haven't
actually stated any reason why what I said was wrong.

Stateless DHCP is useful for devices that need more information about
network services than a DNS server list. But it has serious problems, e.g.
with respect to user privacy. And regardless of the privacy issues, it
can't replace ND without really substantial updates to every device.

So saying that we should just deprecate it is just as wrong as saying we
should rely on it solely. If there is going to be an MTI protocol for
getting your device online, ND will work and DHCP won't. That does not mean
we have to throw the baby out with the bathwater.

The debate here is about whether we need an MTI protocol. I think we do. If
we do, ND rdnss is the only option.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Mar 2017 14:57:22 +0200

>actually stated any reason why what I said was wrong.

The current situation where we have two mechnisms for DNS resolver information
and devices just support one of the two is really bad.

So we should make a choice, either it is mandatory for all devices to 
support both options or we kill one of them.

So if we only mandate RDNSS and not DHCP, then we should make it very clear 
to operators that any deployment plans that rely on DHCP for DNS configuration
are likely to fail. And then we can just as well formally deprecate the DHCP
DNS option.

But just to be clear, I'm perfectly okay with mandating both RA (SLAAC and
RDNSS) as well as DHCP (IA_NA and DNS) to be supported in all nodes.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Mar 2017 07:59:55 -0500

>actually stated any reason why what I said was wrong.

The current situation where we have two mechnisms for DNS resolver
information
and devices just support one of the two is really bad.

"...is really bad" is not a reason. It is an opinion. What is the _reason_
that it is "really bad"?

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Mar 2017 15:05:26 +0200

>"...is really bad" is not a reason. It is an opinion. What is the _reason_

The most well known case is Microsoft's attempt to go IPv6-only, just to
find out that some devices only support RDNSS and no DHCP and the routers
they have support DHCP but no RDNSS.

For a 'next generation' internet protocol that is now more than 20 years old,
that is an extremely sad situation.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Mar 2017 08:09:46 -0500

I get that. So making RNDSS a MUST is a proposed solution to that. You are
saying that we have to go farther and deprecate stateless DHCP. Why?

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Mar 2017 15:16:07 +0200

>saying that we have to go farther and deprecate stateless DHCP. Why?

I'm saying that one option is to deprecate the DHCP DNS option. I didn't
say anything about deprecating all of stateless DHCP. 

And the other option is to make support for the DHCP DNS option mandatory.

I'm just saying we have to choose and not leave it open.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Mar 2017 08:26:40 -0500

Okay, now I understand. This would prevent networks from requiring stateful
DHCP. So we can't do it.

---

From: David Farmer <[email-masked]>
Date: Fri, 31 Mar 2017 08:46:24 -0500

> and devices just support one of the two is really bad.

I agree the current situation is bad.

> support both options or we kill one of them.

I wouldn't go quite that far, personally.

> RDNSS) as well as DHCP (IA_NA and DNS) to be supported in all nodes.

I'd like to see both RDNSS and DHCPv6 required too.  But I'd be willing to
compromise a little, requiring RDNSS for "all" hosts and routers, and then
maybe a more qualified requirement for DHCPv6, such as for hosts and
routers "intended for enterprise use".  This way a developer has an out to
not support DHCPv6 if they choose, but there are consequences.  Not
supporting DHCPv6 becomes tantamount to admitting that a device is not
intended or suitable for enterprise use, or in other words is only a
consumer device.

I just had an idea, what if we crated an new hybrid operating mode of
DHCPv6 IA_NA for stable addresses and SLAAC for temporary addresses, using
RA flags of A=0, M=1, therefore requiring use of IA_NA, but created a new
DHCPv6 option that says that despite the A=0 flag that SLACC may be used
for the generation of temporary addresses.  This would give enterprise
network operators a level of control for addresses that are intended to
provide services (act as servers), maybe allowing DHCPv6 as a control plane
for provisioning reverse DNS, poking appropriate holes in firewalls,
etc...  While at the same time allowing rapid generation of addresses that
access services (act as clients).

Thanks.

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

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Mar 2017 15:58:39 +0200

>Okay, now I understand. This would prevent networks from requiring stateful

So my compromise position was:
- If a host gets an address using IA_NA it MUST support the DHCP DNS option.
- All nodes have to support RDNSS.

This way there is a simple message for operators, either you use SLAAC and
RDNSS or you can use DHCP for both addressing and DNS. Don't try to mix and
match.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Mar 2017 09:05:33 -0500

I'm okay with that, but I'd be perfectly happy with just requiring rdnss. I
think the enterprise thing is really a side issue. We don't have to make
that change.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Mar 2017 16:18:19 +0200

>intended or suitable for enterprise use, or in other words is only a

I can see 3 reasons for not doing DHCPv6:

1) The device is too constrained. Obviously, if a device is too small to
   support both SLAAC/RDNSS and DHCP IA_NA/DNS then we have to compromise.

2) The implementor is lazy. I certainly fall in that category. But that's
   no excuse.

3) There is something about DHCPv6 not working well enough.

The last one is the tricky one. It not that currently DHCPv6 IA_NA, etc.
doesn't work. And it is the most complex organisations (big enterprises)
that really want to do DHCPv6.

There is some aspect that operators are stupid and supporting only SLAAC
gets around that. In the long term that may be a risky proposition.

Then there is an argument that DHCPv6 may work today, but cannot handle
future requirements. Unfortunately, there doesn't seem to be an experiment
that demonstrates that for some reasonable assumptions about the
future, DHCPv6 doesn't work.

>access services (act as clients).

As far as I know, servers are almost always configured 'manually' and are
typically on separate LANs.

Typically, DHCP is used to make sure that addresses can be traced back to 
devices. Allowing temorary addresses using SLAAC would defeat that purpose.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 31 Mar 2017 16:26:29 +0200

> I can see 3 reasons for not doing DHCPv6:

0) It requires an additional service to be operate/maintain for no
obvious reason. It's expensive.

> 3) There is something about DHCPv6 not working well enough.

[skip]

> future, DHCPv6 doesn't work.

https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-00
More specifically, section 4 of the abovementioned doc.

---

From: David Farmer <[email-masked]>
Date: Fri, 31 Mar 2017 09:27:57 -0500

On Fri, Mar 31, 2017 at 9:05 AM, Ted Lemon <[email-masked]> wrote:

> I'm okay with that, but I'd be perfectly happy with just requiring rdnss.
> I think the enterprise thing is really a side issue. We don't have to make
> that change.
>

While logically they can and probably should be separate issues.  However,
the situation has gotten so bad that there is insufficient trust to allow
an RDNSS requirement to move forward without something to ensures that such
an RDNSS requirement isn't used as a future argument against DHCPv6.

We have to get over it.  Host/Network configuration is, and will forever be
at this point, a multitheistic space.  Let's just live and let live.  It's
time for all routers and general purpose devices to support both.  I'm
willing to allow highly constrained devices some flexibility.  However,
honestly there is no good reason for most devices to not support both
religions.

Thanks.

---

From: Ola Thoresen <[email-masked]>
Date: Fri, 31 Mar 2017 16:32:39 +0200

> 3) There is something about DHCPv6 not working well enough.

4) The manager does not want to do all the extra work of setting up a 
DHCP-server.  It does not mean I am lazy. It means I don't need another 
service running, all the extra lines of config, managing pools and 
networks and so on.

If all you need is an "ad hoc" network, and you don't need to know who 
the clients are, or control the assignment of addresses and don't care 
as long as they get on "the internet" somehow.  Why bother with DHCP?

> gets around that. In the long term that may be a risky proposition.

You dont need to be "stupid".  For "IoT" (for whatever that term i 
worth) it makes no sense to have to set up DHCP just to get the devices 
online.  Even if they have enough resources to run a dhcp client, it 
should not be necessary.

/Ola (T)

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Mar 2017 16:45:07 +0200

>service running, all the extra lines of config, managing pools and 

Note that I was talking about DHCP support in devices. By making sure that
all devices (routers and hosts) support both SLAAC and DHCP it becomes
an operational choice to use SLAAC or DHCP.

It is only when some devices support only one option that an operator is forced
to use that option even if it is not the best one.

>online.  Even if they have enough resources to run a dhcp client, it 

That's perfectly fine. No one is trying to force an operator to run DHCP
(except for the long list of other config options that only exist in DHCP).

But if I want to have fine grained control over my IoT devices and do want
to set up DHCP, then I should be able to do that.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Mar 2017 09:46:56 -0500

Then you are requiring all constrained devices to spend more resources.

It is only when some devices support only one option that an operator is
forced
to use that option even if it is not the best one.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Mar 2017 17:02:46 +0200

>Then you are requiring all constrained devices to spend more resources.

I don't know about you, but if possible I want my contrained devices to
use TLS. If possible I want them to use public key crypto to verify firmware
upgrades. If they provide console access, I want that to be ssh and not
telnet.

All of those are more costly than DHCP. Note that the need to actually
do DHCP (as opposed to the code being there passively available) is signaled
in an RA. So if you don't use DHCP in your network, it should not consume
any runtime resources.

Finally, if a device is really so constrained that DHCP literally doesn't
fit, then leave it out.

But this is not the controverial part of the discussion. The problematic
devices are the ones that have more than enough resources and still don't
do DHCP.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 31 Mar 2017 16:20:24 +0100

> encounter and we want hosts to work wherever they happen to be.

This would be much better and rather good option, yes, although I fear
you would meet strong resistance to the idea.  I would definitely
support this.

Nick

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Mar 2017 17:46:55 +0200

Hi,

> "...is really bad" is not a reason. It is an opinion. What is the _reason_

People build networks that do not work, because of two vendors that need
to interoperate, one side is not implementing RDNSS and the other side
is not implementing (stateless) DHCPv6.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Mar 2017 17:50:42 +0200

Hi,

> obvious reason. It's expensive.

For state*less* DHCPv6, that's really not a very strong argument - if
implemented on the router, configured from the same set of parameters
("here's a DNS server, hand out via RDNSS and stateless DHCPv6, done"),
the extra operational/maintenance overhead is totally neglibile, and
the cost on the router to listen on an extra port is also not high.

IA_NA is something different.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 31 Mar 2017 16:52:05 +0100

> Then you are requiring all constrained devices to spend more resources. 

claims about dhcpv6 being unsuitable for resource constrained devices
are often made but rarely substantiated.  I'm not saying that this isn't
a problem, but it would be helpful if we had some level of understanding
in v6ops about the scale of the issue and whether this is a serious
enough thing that it ought to hold up standardisation of what would
otherwise be sensible and practical long term fixes to otherwise
difficult problems.

Nick

---

From: Jen Linkova <[email-masked]>
Date: Fri, 31 Mar 2017 18:00:52 +0200

> the cost on the router to listen on an extra port is also not high.

I'm not a big fun of having services on routers. Especially when I
have to duplicate the configuration.
(It is an additional feature, I have to test it and have it in my
qualification test set etc - and I might even need a license for it -
and yeah,
when it does not work as expected I have to troubleshoot it). Not
mentioning acls etc.
If it is not on a router - I need someone to operate that stateless
DHCP for me. To configure it, to monitor it, to be oncall for it.
And I can not notify hosts about any changes quickly enough.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Mar 2017 11:18:34 -0500

Technically you have to do that with your router anyway to configure rdnss.
I don't think this is a good argument against stateless DHCP on routers. A
better argument is simply that it's redundant.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Mar 2017 11:19:42 -0500

Right, that's why we're proposing making rdnss MTI.

On Mar 31, 2017 10:46, "Gert Doering" <[email-masked]> wrote:

Hi,

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Mar 2017 20:03:17 +0200

Hi,

> have to duplicate the configuration.

A reasonable router implementation would use a single source for 
distribution via both protocols.  An unreasonable implementation is
not a good reason to oppose a protocol.

> when it does not work as expected I have to troubleshoot it). 
> Not mentioning acls etc.

Right.  We really should abandon all this higher-level shit like DNS,
and solely focus on transporting packets.

Is that what you're saying?

[..]
> And I can not notify hosts about any changes quickly enough.

*That* argument is so silly and stale it really doesn't even deserve 
a pointer to Nick's excellent reply to it.

If you really *really* need to renumber your recursive name servers
so often and without any prior notice(!!) - then, by all means, do not
use stateless DHCPv6 to disseminate recursive DNS information.  But do
not use that as an argument against letting other people use DHCPv6 to
disseminate information that for them doesn't change very often, or
in an unplanned way.

Like, our recursive name servers are using the very same IPv6 addresses
since about 15 YEARS.  Even though the actual hardware and software 
incarnation has changed quite a few times since then.

Gert Doering
        -- NetMaster

---

From: Fred Baker <[email-masked]>
Date: Fri, 31 Mar 2017 11:26:55 -0700

On Mar 31, 2017, at 8:52 AM, Nick Hilliard <[email-masked]> wrote:
> claims about dhcpv6 being unsuitable

Speaking as chair, but also speaking for myself.

My perception has been and is that the argument between DHCP and the RA has been driven by political considerations more than anything else. Some operators are happy with the RA, and some strongly prefer DHCP. Telling either one "you're wrong" seems to me an unproductive exercise - we may as well try to tell them what routing protocols to run, or how to lay out their networks. They do it their way, and they don't really care what we think about it.

It turns out that there are reasons to support the RA approach and reasons to support the DHCP approach. At least part of that has to do with the fact that the sets of information elements differ, and when one creates a new information element in either model, it has to be duplicated in the other to maintain parity. It seems like a lot of work.

RFC 4339, of course, tries to analyze that in the context of DNS.

In this discussion, I, personally, would like to separate between "I like <foo>, all <bar> is evil", and "the technical differences between <foo> and <bar> are <these>, with <those> ramifications."

I believe that we are discussing the difference between "MAY", "SHOULD", and "MUST". Personally, when I use those words, I use them in this way:

"MAY" means that I am aware of someone doing or proposing to do a given thing, and I don't see a problem with it. It is brought up to say that the gentle reader might seriously consider the option.

"SHOULD" means I'd like to say "MUST", but I think there might be or perhaps know of situations in which that would be inappropriate. I try to say what those might include, perhaps in general terms.

"MUST" means, to me, that something breaks when the "MUST" is disobeyed. I try to say what breaks.

Something that would help me, in this discussion, would be a simple and incontrovertible statement of what breaks, or in which circumstances RDNSS would be inappropriate. That would help me distinguish between "SHOULD" and "MUST". Failing either, it sounds to me like "MAY". 

In this, I'm trying to avoid the rat-holes this list sometimes gets into, in which proponents of different things spend time telling each other they are wrong without reaching a consensus conclusion (and without deciding that a consensus conclusion isn't needed). I think there is a call for a single answer here; either RDNSS MUST be supported, making the DHCP service interesting if present but mostly irrelevant, the alternative being that it is OK for an operator to decide how s/he wants to run their network for themselves, and between them and their vendors. If we are deciding for technical reasons, we're on solid ground; I worry that this is simply a shouting match between proponents of different solutions.

YMMV, and probably does.

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Mar 2017 21:04:40 +0200

Hi,

On Fri, Mar 31, 2017 at 11:26:55AM -0700, Fred Baker wrote:
> If we are deciding for technical reasons, we're on solid ground; I 
> worry that this is simply a shouting match between proponents of 
> different solutions.

On technical grounds, there is no real difference between RNDSS and
stateless DHCPv6 as far as "being suitable for telling a client attached
to a network what the recommended DNS recursor address is".

Which is how we go into this mess: we left it to the politicians to
decide what they like more, instead of providing a minimum set of MUSTs
that will ensure that a host running "operating system A" will always,
at least standard-requirement-wise, be able to connect to a network 
being run with gear from "vendor B".

(Now, if an operator *decides* that he doesn't care about phones from 
vendor Z in his network, and willingly turns off the "MUST!" bit in his 
network, breaking Z's, then he gets what you describe: ignoring a MUST 
will break things).

Unfortunately, there is no such MUST today.

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Apr 2017 10:32:13 +1300

> Unfortunately, there is no such MUST today.

Exactly. And as a result, we have real-world problems where users cannot
connect out of the box. Although there is no solution to this for legacy
kit, we can tilt the balance in favour of interoperabiliy by a MUST
for future host *and* router implementations (code) and deployments (default
config). I think that is the only rational way forward.

    Brian

---

From: "Russ White" <[email-masked]>
Date: Fri, 31 Mar 2017 22:15:04 -0400

> > vendor Z in his network, and willingly turns off the "MUST!" bit in
> > his network, breaking Z's, then he gets what you describe: ignoring a
> > MUST will break things).
> >
> connect out of the box. Although there is no solution to this for legacy kit,
> we can tilt the balance in favour of interoperabiliy by a MUST for future host
> *and* router implementations (code) and deployments (default config). I
> think that is the only rational way forward.

I think the way forward, without continuing to tie ourselves in knots--😊--maybe be this -- simply say both MUST be implemented, because:

- some folks prefer one, other folks prefer the other
- I have not heard a single argument from anyone along the lines of "this is not important, neither needs to be implemented"

I can add a note someplace in the document that says something like--

"This document contains recommendations and requirements for implementations, rather than deployment. As such, it contains some overlapping requirements because there is no clear consensus in the operator community on which feature is better, or because requirements vary enough that both are technically valid choices. In these situations, the primary point is that as implementations are used across a wide array of operator networks, and the service the requirements supports is, itself, required for the proper functioning of a large scale network, overlapping features sets may be included here."

That's pretty rough, because it's late a night, and my brain is tired, but it might be a starting point?

😊 /r

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Mar 2017 21:25:35 -0500

> That's pretty rough, because it's late a night, and my brain is tired, but it might be a starting point?

The trick is that it's really easy to require RDNSS, but requiring stateless DHCP is a lot harder, because you have to say precisely what that means, and get it right.   The specifications for when to use stateless DHCP, for example, are pretty vague.

I agree that this _seems_ pretty obvious in the abstract, but the devil is in the details.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 1 Apr 2017 00:16:50 -0500

On Fri, Mar 31, 2017 at 9:15 PM, Russ White <[email-masked]> wrote:

> I think the way forward, without continuing to tie ourselves in
> knots--😊--maybe be this -- simply say both MUST be implemented, because:
>
> - I have not heard a single argument from anyone along the lines of "this
> is not important, neither needs to be implemented"
>

That was what draft-gont-v6ops-host-configuration proposed, and there was
strong pushback from major host OS developers against making both of them a
MUST. Examples:

https://www.ietf.org/mail-archive/web/v6ops/current/msg25536.html
https://www.ietf.org/mail-archive/web/v6ops/current/msg25583.html

I think that's unlikely to reach consensus.

On the other hand, there seems to be less opposition to making RDNSS a
MUST. The main objections so far appears to be of the form "if we make
RDNSS a MUST we should make DHCPv6 a MUST as well", but given the pushback
from host OS developers I don't think that's likely.