Subject: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting" means

From: Fernando Gont <[email-masked]>
Date: Fri, 7 Apr 2017 12:28:13 +0100

Folks,

I've followed the discussion in the thread "Making RDNSS a MUST?", and
it would seem to me there's a misunderstanding in what
"implementing"/"supporting" means.

Lorenzo has elaborated on the downsides of employing stateless DHCPv6 to
convey DNS information when doing tethering.

However, supporting DHCPv6 does not mean Android should convey that
information with DHCPv6 (whether in addition or in replacement of
RDNSS). It simply means:

* For routers, that the functionality needs to be available, such that
if an operator decides to employ it, he/she is able to do so.

* For clients, it means that the client device should implement
stateless DHCPv6, such that if the network makes config information
available over stateless DHCPv6, the client should be able to learn it.

An Android device operating as a router (doing tethering) can refrain
from employing stateless DHCPv6 to convey network configuration
information, while still complying with the requirement of
"implementing"/"supporting" stateless DHCPv6.

Use of stateless DHCPv6 in addition to or in replacement of RDNSS ends
up being an operator's decision. In the case of the Android device doing
tethering, it could easily be some configuration flag that defaults to
"off", or, stretching things a bit, one might even argue that since the
configuration is buried in the app doing tethering, such configuration
could be "stateless dhcpv6 is off, and there's no way to turn it on".

Obviously, stateless DHCPv6 *client* support should be on and enabled by
default for all client devices.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Sander Steffann <[email-masked]>
Date: Fri, 7 Apr 2017 15:32:04 +0200

Hi Fernando,

Thank you for writing sense.

> up being an operator's decision.

*This*

As a network operator I am sick and tired of being forced by vendors to build my network according to their one true vision. I perfectly well know the characteristics of the network I'm deploying and I'd like to be the one deciding on how to provision it, thank you very much. When running an IPv6-only network Android is forcing my hand to make me send RDNSS, Windows requires DHCPv6, and as an operator I have no choice but to provide both. Even if I know that this network is very stable and DHCPv6 would be fine, or when I know that it's very likely to change over time and I really need the speed of RA+RDNSS.

> In the case of the Android device doing

Perfectly fine. And I'm happy to let Android be the network operator of the tethering network and make the right choices of provisioning mechanism. Same for home and small-office CPEs. An option to change the default would be nice for those of us who know what they are doing, but we're not the typical user group so I can understand when that's not implemented everywhere :)

> default for all client devices.

Well yes, if devices need to work in different networks (and I'd really like to use my phone on my native 3G/4G network, while roaming, on my home wifi and on the office wifi without having to change any settings) then they need to support both provisioning mechanisms.

So clients need to support both, and managed routers need to let the operator choose. For unmanaged routers some configuration options would be nice to have for advanced users.

Cheers,
Sander

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 23:22:19 +0900

On Fri, Apr 7, 2017 at 10:32 PM, Sander Steffann <[email-masked]> wrote:

> As a network operator I am sick and tired of being forced by vendors to
> build my network according to their one true vision. I perfectly well know
> the characteristics of the network I'm deploying and I'd like to be the one
> deciding on how to provision it, thank you very much.

I don't think that's a useful argument. You could just as well replace
"network operator" with "software developer" and "network" with "product"
and end up with a similar sentence - and neither of the two would be likely
to convince the other side of the debate.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 7 Apr 2017 16:42:14 +0200

Hi Lorenzo,

>> As a network operator I am sick and tired of being forced by vendors to build my network according to their one true vision. I perfectly well know the characteristics of the network I'm deploying and I'd like to be the one deciding on how to provision it, thank you very much.
> 
> I don't think that's a useful argument. You could just as well replace "network operator" with "software developer" and "network" with "product" and end up with a similar sentence - and neither of the two would be likely to convince the other side of the debate.

A product is used in many places with vastly different characteristics. A network is one instance with certain characteristics. Your comparison doesn't work...

Cheers,
Sander

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 7 Apr 2017 15:08:07 +0000

> I don't think that's a useful argument. You could just as well replace "network 
> operator" with "software developer" and "network" with "product" and end 
> up with a similar sentence - and neither of the two would be likely to convince 
> the other side of the debate.

Lorenzo is right. What I'm reading is that some enterprise operators want to use IETF to try to force Google to implement DHCPv6 client in Android. 
It is both inappropriate and ineffective to try to use IETF to bully a single company into doing what you want, just because it's what you want.
It's ineffective because IETF RFCs that an implementer disagrees with and doesn't want to implement are incredibly easy to ignore. Trust me -- I know.
It's inappropriate because that's not what IETF should be used for, and it makes IETF look bad.
Some other enterprises have indicated they are willing to accept Android as is (just because some enterprises don't want to, doesn't mean that all don't want to). But what they need are enterprise routers (that they procure, control, and administer) to support RDNSS in sent RAs. They want IETF to help get the message out to enterprise router manufacturers that this is highly desired (e.g., MUST in an Informational enterprise router RFC). Enterprise router manufacturers don't seem to be fighting this. Enterprise operators who don't want to do RDNSS can disable (or not enable) it. So for enterprise operators, let's focus on providing them with requirements for enterprise routers they can take to their enterprise router vendors.

If some enterprises want to continue pressuring Google, they should use methods external to IETF. They can publicly refuse to supply their employees with Android devices, going forward (old Android devices will be long gone before IPv4 disappears). They can write blogs encouraging consumers to stay away from Android devices until DHCPv6 is implemented. They can "assist" popular tech sites with articles. They can participate in enterprise company trade associations to try to send a unified message against enterprise use of current Android. Etc. Not IETF.
Barbara

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 8 Apr 2017 00:27:23 +0900

On Fri, Apr 7, 2017 at 11:42 PM, Sander Steffann <[email-masked]> wrote:

> A product is used in many places with vastly different characteristics. A
> network is one instance with certain characteristics. Your comparison
> doesn't work...
>

Actually it does. Those networks don't need to use a different provisioning
protocol. The proof is the fact that in IPv4 they all use pretty much the
same one: DHCPv4.

I think it's likely we'll eventually end up with only one provisioning
protocol in IPv6, too. The point I think many are missing here is that if
we want end-to-end connectivity. we'd better hope that that protocol is not
DHCPv6.

The reason this is important is simple: DHCPv6 is fundamentally not good at
to updating information, because it's a pull model. But end-to-end
connectivity requires that the endpoints know what's going on. So If you
want end-to-end, you have exactly two options:

   1. The network doesn't change.
   2. When the network changes, you can tell the endpoints what changed.

If the network changes, and you can't tell the endpoints what changed, then
your only option is to break end-to-end.

We've probably all forgotten how end-to-end works because for the last
years/decades, the dominant networking technology was IPv4, and in most
networks, IPv4 stopped providing end to end years or decades ago. DHCPv4 is
absolutely fine if all you want to do is return 192.168.1.1 and 192.168.1.1
never changes, or if you return an IPv4 address in PI space, and that never
changes.

But if we want to bring end-to-end back with IPv6, we need to re-learn how
to build end-to-end networks. You can't do that with DHCPv6.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 7 Apr 2017 16:56:05 +0100

On 04/07/2017 04:08 PM, STARK, BARBARA H wrote:
> 
> If some enterprises want to continue pressuring Google, they should
> use methods external to IETF. They can publicly refuse to supply
> their employees with Android devices, going forward (old Android
> devices will be long gone before IPv4 disappears). They can write
> blogs encouraging consumers to stay away from Android devices until
> DHCPv6 is implemented. They can "assist" popular tech sites with
> articles. They can participate in enterprise company trade
> associations to try to send a unified message against enterprise use
> of current Android. Etc. Not IETF. Barbara

I don't think this discussion is about pressuring anyone. It's about a
situation in which operators and users are paying the price for a battle
between vendors.

I want to be able to deploy an IPv6 network that supports at least the
major OSes, and don't find it encouraging to have to add duplicate
functionality because different router and client OS implement
mismatching subsets of the possible mechanisms to get the network running.

That's an operational problem on which this wg should have a say.

Thanks,

---

From: Chuck Anderson <[email-masked]>
Date: Fri, 7 Apr 2017 12:03:36 -0400

> protocol. The proof is the fact that in IPv4 they all use pretty much the

That's because DHCPv4 is flexible enough to support multiple different
types of deployments.

> never changes, or if you return an IPv4 address in PI space, and that never

I run a /16 that is not NATed.  With DHCPv4.  Without the theoretical
problems you pose.

> to build end-to-end networks. You can't do that with DHCPv6.

That is only one consideration out of many.  RA doesn't support
per-host configuration, centralized management/tracking, and
separation of duties.  DHCPv6 does support RECONFIGURE.  DUIDs are not
any more of a privacy concern than MAC addresses are.

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Apr 2017 09:31:04 -0700

> On Apr 7, 2017, at 8:08 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> What I'm reading is that some enterprise operators want to use IETF to try to force Google to implement DHCPv6 client in Android. 

For the record, I think there is also a subtext of bullying Microsoft into implementing RDNSS, and I think Sander's complaint about vendors trying to force their vision of the world has merit. Yes, there is an attempted forcing function here. It goes both ways.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 7 Apr 2017 16:35:14 +0000

> I want to be able to deploy an IPv6 network that supports at least the major
> OSes, and don't find it encouraging to have to add duplicate functionality
> because different router and client OS implement mismatching subsets of
> the possible mechanisms to get the network running.
> 

That's an operational problem that ISPs faced years ago when writing CE router requirements. We (ISP operators) decided the correct approach was for CE routers to deliver DNS info via RDNSS and DHCPv6. ISPs haven't experienced issues with the CE routers doing this. The CE router vendors did not object or push back (i.e., they did not find it too difficult to do). Vast numbers of consumers now have IPv6 without even knowing it (the sign of a successful deployment). The decision has produced no operational headaches. The duplicate functionality has caused no problems. While having duplicate functionality implemented and enabled in the router may not be "encouraging", it is not operationally difficult to do, and the router vendors did not struggle with implementing it.
Barbara

---

From: Sander Steffann <[email-masked]>
Date: Fri, 7 Apr 2017 18:57:24 +0200

Hi Fred,

> For the record, I think there is also a subtext of bullying Microsoft into implementing RDNSS, and I think Sander's complaint about vendors trying to force their vision of the world has merit. Yes,…

Thank you, that is indeed what I meant. I want the operator to be in control of how to run the network, without being forced by vendors. There's indeed some pushing, but it's merely pushing back after having been pushed for too long...

Cheers,
Sander

---

From: Lee Howard <[email-masked]>
Date: Fri, 07 Apr 2017 12:58:06 -0400

From:  v6ops <[email-masked]> on behalf of Lorenzo Colitti
<[email-masked]>
Date:  Friday, April 7, 2017 at 10:22 AM
To:  Sander Steffann <[email-masked]>
Cc:  Fernando Gont <[email-masked]>, IPv6 Operations <[email-masked]>
Subject:  Re: [v6ops] DHCPv6 and RDNSS: What "implementing"/"supporting"
means

>> As a network operator I am sick and tired of being forced by vendors to build
>> my network according to their one true vision. I perfectly well know the
>> characteristics of the network I'm deploying and I'd like to be the one
> "network operator" with "software developer" and "network" with "product" and
> end up with a similar sentence - and neither of the two would be likely to
> convince the other side of the debate.

Is there an architectural principle you would appeal to, to resolve the
conflict?

Lee

---

From: james woodyatt <[email-masked]>
Date: Fri, 7 Apr 2017 14:35:48 -0700

On Apr 7, 2017, at 09:58, Lee Howard <[email-masked]> wrote:
> 
> Is there an architectural principle you would appeal to, to resolve the conflict?

I can’t answer for Lorenzo or Sander, but where I would start with the three architectural principles of Vitruvius: firmitas, utilitas, venustas, i.e. a good architecture is 1) durable, stands up robustly to deteriorating environmental conditions, and still remains in good condition; 2) suitable for the purposes for which people are using it; and 3) aesthetically pleasing.

A good network needs first to be durable, second to be suitable, and third to be aesthetically pleasing. A good network has to last at least as long as the most durable host in the network, and often longer. It must be suitable for all the disparate uses that the population of hosts are making of it. And it needs to be aesthetically pleasing: which in the context of communication networks, it must be seamless and invisible to the people using it. Wherever the communication network itself becomes visible to the people using it, there is where the network is brutalizing its users. An aesthetically pleasing network is invisible.

A good host implementation, on the contrary, reverses the order of these. Indeed, a good host implementation need not be durable. It could be totally disposable, designed to run until its battery is discharged, then recycled for scrap. It need only be durable while in use, and its lifetime can be short by design. It should be suitable for the purposes that people have for it, but these could be special purposes, and in some cases a suitable purpose is simply to be a thing of beauty. First and foremost, a host implementation should always be aesthetically pleasing. It must delight the people who use it. The experience of using it must be intuitively easy, bringing delight to the people encountering it, and invisibility is rarely the desired quality of a host implementation, as opposed to a network. Everything in host implementations is secondary to aesthetics.

Following the principles above, it seems easy for me to say that a good router provides the necessary infrastructure to be robust and lasting, suitable for seamless and invisible use by a large and diverse population, with the widest variety of hosts, i.e. those that use RDNSS only, those that only use DHCPv6 (stateless, stateful or both), those that have differing methods of combining the two, etc.

Likewise, following the same principles, a good host implementation is designed first and foremost to delight the individual owner of the system. It should use either RDNSS or DHCPv6 or both, as the case may be, in whatever combination is necessary, to provide the best possible user experience in the typical usage scenarios people have for it. As an architectural matter, IETF should take great care to insist that the choice for equipment makers is truly OPTIONAL in both cases. One or the other of them, possibly both, will very likely be necessary to provide an aesthetically pleasing user experience, but which choice the host implementation designer makes is a matter between the equipment maker and the equipment user.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 8 Apr 2017 10:21:20 +0900

> > absolutely fine if all you want to do is return 192.168.1.1 and

Sure, if you have $650,000 worth of IPv4 addresses and slots in the global
routing table you can do that. I said "most" networks.

> DHCPv6 does support RECONFIGURE.

Not in the real world - and even if it did, what are you going to do ?
Renumber a link somewhere in your network by telling your centralized
DHCPv6 server sitting in a datacenter somewhere to issue a reconfigure to a
client that's sitting in another building? What protocol are you going to
use to do that, and how is it going to scale? And what failure properties
will it have if the network partitions?

DUIDs are not any more of a privacy concern than MAC addresses are.

But the industry is moving towards random MAC addresses because static MAC
addresses facilitate tracking, and users are beginning to understand that.

---

From: t.petch <[email-masked]>
Date: Thu, 13 Apr 2017 12:57:04 +0100

Fred

A week ago you asked for feedback and set the :Reply-To to V6ops chairs.
I just got a bounce from my ESP saying that it had tried and failed 52
times to deliver the message, so your feedback may be incomplete.

"Delivery has failed to these recipients or groups:
V6ops Chairs
([email-masked])<mailto:[email-masked]>
Your message couldn't be delivered. Despite repeated attempts to contact
the recipient's email system it didn't respond."

I can send the rest of the bounce if needed.

Tom Petch

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "STARK, BARBARA H" <[email-masked]>
Cc: "Fernando Gont" <[email-masked]>; "IPv6 Operations"
<[email-masked]>
Sent: Friday, April 07, 2017 5:31 PM

> > What I'm reading is that some enterprise operators want to use IETF
to try to force Google to implement DHCPv6 client in Android.
> > It is both inappropriate and ineffective to try to use IETF to bully
a single company into doing what you want, just because it's what you
want.
>
> For the record, I think there is also a subtext of bullying Microsoft
into implementing RDNSS, and I think Sander's complaint about vendors
trying to force their vision of the world has merit. Yes, there is an
attempted forcing function here. It goes both ways.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Thu, 13 Apr 2017 10:17:25 -0700

Weird. The alias works when I use it... I'll send it to AMS.

> On Apr 13, 2017, at 4:57 AM, t.petch <[email-masked]> wrote:
> 
> Fred
>