Subject: Re: [v6ops] Making RDNSS a MUST?

From: "Russ White" <[email-masked]>
Date: Sat, 1 Apr 2017 07:13:50 -0400

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

For hosts, yes. I don't see how the same objections could apply to routers, which should--at least from an operator's perspective--be able to support any host that attaches to them. 

😊 /r

---

From: Simon Hobson <[email-masked]>
Date: Sat, 1 Apr 2017 14:03:53 +0100

Lorenzo Colitti <[email-masked]> wrote:

> 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 noted that neither of those actually gave any reason other than "I don't like it" !

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

The problem being that we've had feedback here from operators who want to be able to use DHCP, who are justly worried that if RDNSS is mandated, then those OS vendors against DHCP will simply not make a feature they wish to use available at all.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 1 Apr 2017 08:06:47 -0500

You should read Fernando's draft. It's short. Ask yourself what "must
support" means in practice. How is it configured?  If the router has a list
of DNS servers, must it send both rdnss and DHCP versions of that info?
What if there is centralized DHCP service on the network?  Your don't have
to ask these questions for rdnss.

On Apr 1, 2017 6:14 AM, "Russ White" <[email-masked]> wrote:

> For hosts, yes. I don't see how the same objections could apply to
> routers, which should--at least from an operator's perspective--be able to
> support any host that attaches to them.
>
> 😊 /r
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 2 Apr 2017 02:04:05 +1200

On 01/04/2017 18:16, Lorenzo Colitti wrote:
> 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:
>>
>> - 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"
>>
> 
> strong pushback from major host OS developers against making both of them a
> MUST. Examples:
> 
> I think that's unlikely to reach consensus.

However, it could reach rough consensus, which is sufficient.

> to ask these questions for rdnss.

No, but you have to answer the question of what tools are available for
configuring the appropriate DNS server address into the router, which
also varies according to the scenario. Maybe there's already a YANG
module that covers this? But in both cases extra guidance is needed.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 1 Apr 2017 09:18:00 -0500

Sorry, that wasn't my point. The concern I was trying to raise is that the
behavior of the in-router stateless DHCP server matters. There is more than
one possible behavior. So someone has to write a doc that specifies that.
Fernando's doesn't. If we make rdnss MTI, that's relatively safe. If we
make DHCP MTI, we have more work to do.

On Apr 1, 2017 9:04 AM, "Brian E Carpenter" <[email-masked]>
wrote:

> them a

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 2 Apr 2017 02:29:58 +1200

> make DHCP MTI, we have more work to do.

That sounds like work that needs to be done anyway.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 1 Apr 2017 09:44:45 -0500

> However, it could reach rough consensus, which is sufficient.

It's always possible that a document that mandates hosts to implement
something is going to reach rough consensus even though a) the developers
of major host OS implementations have said they can't live with it, and b)
the current state of affairs has persisted for many years. But I don't
think that's likely enough to be a good use of the working group's time.

Making RDNSS a MUST is an equally valid solution to the problem posed
by draft-gont-v6ops-host-configuration ("there is no single protocol that
works everywhere"), and seems much more likely to reach rough consensus.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 2 Apr 2017 04:02:44 +1200

> works everywhere"), and seems much more likely to reach rough consensus.

I was actually arguing that making them both a MUST implement is "more"
valid because it increases that chance that an arbitrary host will work
on an arbitrary network. We all know that product managers and open
source developers are not overly impressed by MUSTs and SHOULDs anyway.
So personally I'd be part of the consensus for pretty much any set
of MUSTs and SHOULDs. Fill in the matrix as you prefer:

----------------------------
|      | host    | router  |
----------------------------
|RDNSS | MUST    | MUST    |
----------------------------
|DHCPv6| MUST    | MUST    |
----------------------------

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 01 Apr 2017 20:27:40 +0100

dhcpv6 service support on the router itself is troublesome due to the
configuration complexity and lease management requirements of dhcpv6
(think: flash storage with limited number of writes, arcane /
non-flexible CLI interfaces, etc).  I would also argue it's unnecessary
because most people use servers to handle dhcpv6 service, with relays
for non link-local requests.  Anyway, DHCP cannot feasibly be
provisioned on non-trivial sized networks without relay support.

Therefore, I'd suggest:

> |DHCPv6| MUST    | MAY     |
> |Relay | n/a     | MUST    |

Nick

---

From: Gert Doering <[email-masked]>
Date: Sat, 1 Apr 2017 22:12:55 +0200

Hi,

> configuration complexity and lease management requirements of dhcpv6

Maybe we should strongly differenciate between stateless DHCPv6 and
IA_NA here...?

> provisioned on non-trivial sized networks without relay support.

I disagree for state*less*.  Which is perfectly fine for DNS info.

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: Ted Lemon <[email-masked]>
Date: Sat, 1 Apr 2017 16:29:56 -0500

> That sounds like work that needs to be done anyway.

Right now it's not mandatory, so there's no need to specify what is mandatory.   We give you the tools, you use them if you want, you decide how to use them.   If we make it mandatory, we have to say what the mandatory behavior is.   Just "support stateless DHCPv6" is not sufficient.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 09:22:30 -0700

Perhaps we should break this into pieces with different mandates…

Host:
	Must support SLAAC Client implementation including…
		Address auto configuration when M=0.
		RDNSS based configuration of resolvers
		Installation of default route(s) based on received RAs
		Support for multiple default routers based on received RAs
		Support for additional routing information contained in RAs
		<insert other minimum required features here>

	Should support DHCP6 Client implementation including…
		<insert minimum required features here>

	A host which fails to support DHCP6 Client implementation should behave in the following
	manner when confronted with M=1:
		<what do we want such host to do?>

Router:
	Must support Router Advertisements including…
		Ability to configure/support SLAAC
		Ability to configure/support “O-bit = 1” stateless addressing with DHCP for other information
		Ability to configure/support “M-bit = 1” stateful addressing using DHCP
		<insert other minimum required features here>

	Must support DHCP6 Relay including…
		<insert minimum required features here>

	Should support DHCP6 Server including all requirements from DHCP6 Server below.

DHCP6 Server:
	Must support DHCP6 services including…
		<insert minimum required features here>

In this way,  perhaps the pushback from host OS developers can be limited to the Host: portion of the document and we can at least get some consistent agreement on the router and DHCP6 server portions moving forward.

I think if we can stabilize and standardize the latter 2, then the Host area might be a more solvable problem in the longer term.

Owen

> On Apr 1, 2017, at 6:03 AM, Simon Hobson <[email-masked]> wrote:
>

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 10:43:13 -0700

> On Mar 31, 2017, at 8:52 AM, Nick Hilliard <[email-masked]> wrote:
> 
> Ted Lemon wrote:
>> 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.

Think about a 6 LOWPAN device with, maybe 512K of code (Flash) space
and on the order of 32K of RAM that is the size of a quarter and you’re in
the ball park.

Do these constitute the majority of IT spend anywhere? No. Will they likely
comprise a significant number of hosts in the future… You bet!!

IOT is not a myth and some day developers will pull their heads out of their
asses and start implementing it with real address space.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 10:54:17 -0700

> On Mar 31, 2017, at 8:02 AM, Philip Homburg <[email-masked]> wrote:
> 
> 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.

Most constrained devices _DONT_ provide console access. Most don’t run
an operating system. Some have rudimentary serial ports (usually TTL and
no hardware flow control) that the application developer _MAY_ enable to
do stuff. Few have any sort of TELNET or SSH support and the ones that
do are arguably a lot less constrained than what I think of when I hear the
term “constrained device”

Let’s, for the sake of argument say that a constrained device is one with less
than 1MB of Flash and less than 64K of RAM.

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

True, but ANY of those being squeezed in with a 6 LOWPAN
(or worse, a full IPv6) stack in the resources above leave very little room
left for the actual application.

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

Well, here’s the rub. It’s not a question of does or doesn’t fit at the end of the
day… It’s more a question of “I’ve got 60 things to put in, my particular
need requires these 30, the IETF says I have to include these other 15, my
engineering team wants a different subset of 20 and my device can hold
roughly 38 of them.”

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

So perhaps we should write a requirement in those terms…

Define the term “Resource Constrained Device”, provide an exception to the
requirement for DHCP6 Client implementation in such devices, and then require
it on other hosts.

I would propose that rather than the arbitrary numeric definition above, if we
are to codify such a definition in an RFC, however, that we should give it
genuine thought and define it in terms that can scale with time and demands.

Perhaps people will want to make changes to the following straw man as a
starting point:

A “Resource Constrained Device” is a host which has resource limitations which
make it impossible to include all of the normally required features specified in the
current RFC set without compromising the ability to meet other demands from
the application, environment, or function for which the host is intended.

Then we could, perhaps even in a separate RFC, list which IPv6 requirements
are considered optional in the case of a “Resource Constrained Device”
implementation.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Apr 2017 10:55:26 -0700

> and on the order of 32K of RAM that is the size of a quarter and you’re in

Right, and more importantly, a battery that fits in a device the size of a quarter will not support a doubling of the packet count required to join the network.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 11:01:02 -0700

> On Mar 31, 2017, at 7:32 AM, Ola Thoresen <[email-masked]> wrote:
> 
> On 31. mars 2017 16:18, Philip Homburg wrote:
> 
>>> 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 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.
>> 
> 
> 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.

I think we should distinguish between “Operational Requirements” and “Implementation Requirements” here.

I don’t think anyone is requiring operators to deploy DHCP on every device or every network in this proposal (at least I hope not and we shouldn’t be IMHO).

I think, instead, what is being discussed is a requirement that all devices support both options for obtaining configuration information so that the operator can choose the option best suited to their environment without having to worry about the fact that some fraction of their devices won’t support A while some other fraction won’t support B.

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

I couldn’t agree more, but that only works if RDNSS client support is an implementation requirement.

OTOH, if you don’t want to run RDNSS for whatever reason and you prefer DHCP, that only works if DHCP client support is an implementation requirement.

Currently, both are implementation “options” and it’s created a huge mess where virtually every client platform out there supports one or the other and only a few support both, leaving operators having to support both on their network or face some subset of clients that simply won’t work on their network.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 11:15:36 -0700

> On Mar 31, 2017, at 6:58 AM, Philip Homburg <[email-masked]> wrote:
> 
>> 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.
>> 
>> 
>> Okay, now I understand. This would prevent networks from requiring stateful
>> DHCP. So we can't do it.
> 
> 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.

But that doesn’t make sense. It’s perfectly valid and many operational networks today use
the M=0, O=1 for SLAAC + other information from DHCP.

As long as the client is capable of DHCP, this shouldn’t be a problem and there’s no reason
not to allow this (previously intentionally enabled) perfectly valid configuration mechanism.

I agree that any host which supports IA_NA must support DHCP DNS option.I also agree
that all hosts must support RDNSS  I don’t agree that a host which supports IA_NA and
DHCP DNS option should be allowed to refuse DHCP DNS information if it gets an
address via SLAAC with the O bit set (which while not part of your “position” is what
is implied from your “simple message for operators”.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 11:23:09 -0700

> On Mar 31, 2017, at 6:46 AM, David Farmer <[email-masked]> wrote:
> 
> 
> 
> On Fri, Mar 31, 2017 at 7:57 AM, Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:
> >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.
> 
> The current situation where we have two mechnisms for DNS resolver information
> and devices just support one of the two is really bad.
> 
> I agree the current situation is bad.
>  
> So we should make a choice, either it is mandatory for all devices to
> support both options or we kill one of them.
> 
> I wouldn't go quite that far, personally.
>  
> 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.
> 
> 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 think this is an artificial and unjustified mechanism for qualification. While it’s convenient to divide the world into “enterprise” and “consumer” use, first, those are not well defined terms to begin with. Second, there’s a category of devices that are unlikely to support DHCP6 which are intended for enterprise use (e.g. resource constrained sensor packages). While an enterprise may need to require DHCPv6 for clients in certain trusted parts of the network, the reality is that it is perfectly valid to create sensor networks with entirely different security parameters where other mechanisms may be more practical (e.g. MAC-based authentication, router/firewall ACLs preventing access to corporate resources, etc.). There’s no reason to absolve consumer devices of the need to support DHCP6. Instead, I believe that we should make exceptions for resource constrained devices and no others.

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

Why does a host with a stable address from DHCP need a temporary address? I’m not expressing opposition (yet), but I’m trying to understand the application where this would be perceived as useful vs. yet more confusion piled on to the existing mess that is the interaction between RA/SLAAC and DHCP6.

Owen

---

From: Ola Thoresen <[email-masked]>
Date: Sun, 2 Apr 2017 21:46:38 +0200

> I think, instead, what is being discussed is a requirement that all devices support both options for obtaining configuration information so that the operator can choose the option best suited to th…

Obviously.  And I am sorry if my point was not very clear.  The 
discussion I was referring to used managers as an example.

What I was trying to argue for, was that making _one_ of the options a 
requirement, should not necessarily make us want to abolish the other.  
I can see situations where both running SLAAC only, and running DHCP 
only cloud be a viable solution.  And as you say, it should be up to the 
operator to make that choice.

But also - IF we just want to make ONE of the options compulsory in all 
implementations, it should be RDNSS.
The reason being that RDNSS is the simplest one and makes the least 
impact on managers.  Since RAs are already there, I believe it is a 
smaller problem for an admin that want to run DHCP only for address 
assignment, to include dns-servers in the already present RAs than it is 
to require that people wanting to run a SLAAC only network to set up a 
DHCP-server only to give out dns-servers.

I am not sure it is right to make _both_ DHCP and RDNSS a "MUST" for all 
implementations.  And if I have to chose, I chose RDNSS as "MUST" and 
DHCP as "SHOULD".

- If that makes it clearer?

Rgds.

Ola Thoresen

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 12:59:08 -0700

> asses and start implementing it with real address space.

I'm with you on needing to spec things that meet actual market demands. 
But, a few questions related to that theoretical device.

1. Why is it doing DNS lookups?
2. What is it using to make the DNS lookups?
3. How does the size/complexity of the code necessary for stateless 
DHCPv6 to get address and/or DNS configuration compare to the 
size/complexity of the equivalent code for SLAAC?

Until we have those answers, I agree with Fred that this is a purely 
political discussion.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 13:02:04 -0700

On 04/01/2017 09:02 AM, Brian E Carpenter wrote:
> on an arbitrary network.

No, it wouldn't, because "MUST support" is not the same as "MUST 
provide." And people are going to continue configuring their network the 
way they want to in any case.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 13:05:39 -0700

On 03/31/2017 12:18 AM, Simon Hobson wrote:
> Doug Barton <[email-masked]> wrote:
>
>> 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".

Yes. That was the completely predictable result of the introduction of 
new options to SLAAC beyond RA, and the core objection made by those of 
us who have been opposing additional such options for over a decade.

I've snipped the rest of your message because we all know how we got 
here. We have created this mess by allowing the anti-DHCP crowd to run 
the asylum. We need to stop letting that happen.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 13:08:52 -0700

On 03/31/2017 04:09 AM, Nick Hilliard wrote:
> 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:

Here, here.

> 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

Operators and vendors will not do this. They have already voted with 
their feet, and have made it quite clear that DHCP is the preferred 
method of host configuration.

> 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

Yes, please. :)

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

You said it far more elegantly than I did, but this is the gist of what 
I was trying to get across the other day.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 13:14:49 -0700

> support both options or we kill one of them.

Some may find it surprising to learn that I'm actually Ok with letting 
RDNSS live. I was (and am) thoroughly opposed to it being introduced in 
the first place, but now that it's here I think those that like it and 
find it sufficient should be allowed to continue to use it.

Making it mandatory to implement, however, would only serve to show how 
out of touch the IETF is with over a decade of expressed operator 
preference, and as Nick pointed out serve the political purpose of 
acting as more ammunition for killing off DHCPv6.

I would argue that making DHCPv6 (stateless, or stateful, I don't care) 
mandatory to implement would be a much better solution, as it matches 
what the operators have said they want, would help break the stalemate, 
and would get us closer to a complete DHCPv6 solution. But this is not 
the right place/time to tilt at that particular windmill. :)

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 13:19:04 -0700

On 03/31/2017 07:27 AM, David Farmer wrote:

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

Yes, there is. Completely aside from the overwhelming lack of market 
demand for RDNSS, implementing (which includes extensive development and 
testing) two solutions to do the same job costs real money to vendors, 
and real time to open source software developers.

What you're essentially saying is that because the IETF can't get its 
act together, those 3rd parties have to bear the cost. That's so far out 
of touch with the real world that it's hard for me to even know where to 
begin to explain how wrong it is.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 13:23:49 -0700

On 03/31/2017 07:32 AM, Ola Thoresen wrote:

> 4) The manager does not want to do all the extra work of setting up a
> DHCP-server.

The operator community has spoken clearly, for over a decade, that they 
are going to do DHCP regardless.

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

Can you give examples of where such networks might exist? At home, 
potentially (but even home routers come with DHCPv6 nowadays). Certainly 
nowhere in any modern enterprise.

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

I'll ask you the same question I asked Owen. What are these theoretical 
constrained devices that cannot run DHCP, yet have the memory and 
processing power to do DNS lookups, and then do something useful with 
the results?

Doug

---

From: Gert Doering <[email-masked]>
Date: Sun, 2 Apr 2017 22:41:58 +0200

Hi,

> are going to do DHCP regardless.

No.  Some people, mostly from the Enterprise camp, have, but that is
not "the operator community speaking with one voice".

I'm an operator, and mostly happy with SLAAC+RDNSS.

That doesn't mean I'm *opposed* to having stateless DHCPv6 MTI,
and having IA_NA around as a useful tool for more strictly managed
environments.  To the contrary.  

I just do not want words to be put into my mouth.

Gert Doering
        -- NetMaster

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 13:52:45 -0700

On 03/31/2017 05:28 AM, Brian E Carpenter wrote:
> Doug,
> On 31/03/2017 16:17, Doug Barton wrote:
>> On 3/29/2017 4:08 PM, Lorenzo Colitti wrote:
>>> 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.
>>
>> No.
>>
>> People who like it can implement it, people who don't, shouldn't have to.
>
> The word "implement" is hopelessly ambiguous.

No, it's a term of art, that I chose with great care. Completely aside 
from my long experience in the IETF, my term as GM of the IANA (which 
partially overlapped your term as IETF chair), and my 17+ years as a 
FreeBSD developer; frankly I'm a little bit insulted that you didn't 
assume that I was using it both correctly, and intentionally. OTOH I 
can't expect everyone to keep everyone's resumes in mind all the time, 
so I forgive you. :)

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

This is a terrible idea, for all of the reasons that I have expressed 
already today. Most importantly for the reason that the IETF should not 
be pushing the cost of its own inability to get its act together onto 
vendors.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 13:58:01 -0700

> not "the operator community speaking with one voice".

Fair enough, but at the same time it's worth pointing out that without 
major enterprise support the vendors aren't going to move, and that 
enterprises account for the overwhelming majority of hosts under 
management where these issues matter in the first place.

> environments.  To the contrary.

... just as I am not opposed (at this stage) to the mere existence of 
RDNSS. I simply don't want it to be mandatory.  :)

> I just do not want words to be put into my mouth.

Again, fair enough, and my apologies for speaking too broadly.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 14:41:04 -0700

> On Apr 2, 2017, at 1:52 PM, Doug Barton <[email-masked]> wrote:
> 

This is the current state of things and it’s frankly, rather awful from a network operator/administrator/end-user perspective.

[snip] — No need for squabbling over the ambiguity or use of the term implement

> This is a terrible idea, for all of the reasons that I have expressed already today. Most importantly for the reason that the IETF should not be pushing the cost of its own inability to get its act together onto vendors.

I disagree. Not with your statement, but, with the idea that the statement above applies in this case.

The existence of SLAAC and DHCP6 both rather than a single one-size-fits-all solution in IPv6 from the IETF is not so much the IETF failing to get its act together as a representation of the diversity of stakeholders and the fact that no single host auto configuration mechanism fits the needs of all stakeholders today. As such, the operators themselves and not the IETF or vendors should be making the decision about which one(s) to implement in any particular operational network.

The only way to make that possible is to make SLACC+RDNSS and DHCP6 support mandatory in host and router capability requirements. There are already relatively well defined mechanisms for expressing which subset of the two protocols is desired on any given network through the use of the A, M, and O bits of the RA.

I don’t think that the client node should necessarily be able to configure them on or off as that would create an override bypassing the operator’s intended configuration expressed in the A, M, and O bits of the RA. Of course, even if we prohibit same, some client implementations will likely include it, but I would argue that from an IETF perspective, the expression desired is either “MUST NOT” or at the very least “SHOULD NOT” in terms of direct client configuration of same. The exception would be a client which is configured statically, which by definition bypasses RA and ignores the A, M, and O bits as well as all other information in the RA.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 15:06:55 -0700

> On Apr 2, 2017, at 1:23 PM, Doug Barton <[email-masked]> wrote:
> 
> The operator community has spoken clearly, for over a decade, that they are going to do DHCP regardless.
> 
> Can you give examples of where such networks might exist? At home, potentially (but even home routers come with DHCPv6 nowadays). Certainly nowhere in any modern enterprise.

I know of a number of large service provider installations that do not use DHCP6 for host addressing.

There are, in fact, many such networks. Perhaps not in “enterprise IT", but in a number of research, education, trade show, service provider, and other installations, this is, in fact, the case.

> I'll ask you the same question I asked Owen. What are these theoretical constrained devices that cannot run DHCP, yet have the memory and processing power to do DNS lookups, and then do something useful with the results?

Doing a lookup for an AAAA record and doing something useful with the result does not take nearly as much memory as doing that _AND_ running enough of a DHCP stack to process IA_NA and all the other relevant DHCP options required.

Remember, even if you require DHCP and abandon RDNSS entirely (bad idea IMHO), you’re still in a situation where you need the full stack to do the DNS lookup, do something useful with it, _AND_ the full DHCP client _AND_ most of the RA stack exclusive of the tiny part that parses and processes the RDNSS option.

OTOH, if you support RDNSS, then you only need the full stack to do the DNS lookup, do something useful with it, _AND the RA stack.

So.. To sum up, in both cases, you need full IPv6 stack (or at least 6LOWPAN stack), the ability to process RAs, the ability to do a DNS lookup, and the ability todo something useful with it.

In the RDNSS case, you need a tiny additional amount of code that processes the RDNSS options of the RA.

In the DHCP case, you need a full DHCP client implementation which is quite a bit larger than the codebase required to process an RDNSS option.

As to examples, if they ever get their IPv6 act together, an example would be the devices sold by particle.io. Other examples would include the various devices from espressif (ESP10 and now ESP32, for example).

When vendors start making IPv6-capable chips that perform the same functions as chips like the W5500, those will likely be examples as well.

Frankly, vendors are telling me that part of the reasons these things don’t exist yet is because they can’t depend on RDNSS support in their client environments due to the lack of consistent IETF guidance to router vendors such as what you are advocating here (the continued unfortunate status quo that we have today).

So no, this isn’t mythology even if I can’t point to real hardware running IPv6 today because I can point to real hardware not running IPv6 today partially because of this very issue.

Owen

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 15:19:24 -0700

On 04/02/2017 02:41 PM, Owen DeLong wrote:
>>> Doug, On 31/03/2017 16:17, Doug Barton wrote:
>>>>> draft-ali-ipv6rtr-reqs , I'm wondering if we might find
>>>>> consensus to say that host and router implementations MUST
>>>>> implement RDNSS.
>>>>
>>>> No.
>>>>
> This is the current state of things and it’s frankly, rather awful
> from a network operator/administrator/end-user perspective.

Yes, as I pointed out elsewhere the current situation was not only 
entirely predictable when RDNSS was first suggested, it was, in fact, 
predicted. :)

>>> 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.
>>
>> This is a terrible idea, for all of the reasons that I have
>> expressed already today. Most importantly for the reason that the
>> IETF should not be pushing the cost of its own inability to get its
>> act together onto vendors.
>
> The existence of SLAAC and DHCP6 both rather than a single
> one-size-fits-all solution in IPv6 from the IETF is not so much the
> IETF failing to get its act together as a representation of the
> diversity of stakeholders and the fact that no single host auto
> configuration mechanism fits the needs of all stakeholders today. As
> such, the operators themselves and not the IETF or vendors should be
> making the decision about which one(s) to implement in any particular
> operational network.

That is a matter of perspective, on which we disagree.

> The only way to make that possible is to make SLACC+RDNSS and DHCP6
> support mandatory in host and router capability requirements.

Sorry, again we disagree here. As you pointed out, different networks 
and environments have different needs.

Let's give a theoretical counter-example to the IOT case. If I am a 
vendor creating a product that needs more configuration options than are 
available through SLAAC, I know that I have to implement a DHCP client. 
Since I'm doing DHCP anyway, all of the time that I spend on RDNSS 
implementation (which I would need to do in order to check the "Complies 
with RFCNNNN" check box that my customers will be looking for) 
completely wasted. Further, if customers find out that the RDNSS support 
exists, some of them will try to use it. Many of them will get it wrong, 
thus increasing my support costs. All of this for exactly zero benefit.

Going back to the IOT crowd, they raise Cain every time DHCP is even 
hinted at, it's not reasonable to expect that they will agree to making 
it mandatory to implement, never mind actually go out and implement it.

We're all in agreement that the status quo sucks. But saying that both 
protocols should be mandatory is a political decision, it's not good 
engineering.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 15:22:49 -0700

> On Apr 2, 2017, at 1:08 PM, Doug Barton <[email-masked]> wrote:
> 
> Operators and vendors will not do this. They have already voted with their feet, and have made it quite clear that DHCP is the preferred method of host configuration.

Which vendors? Juniper supports RDNSS, Cisco supports RDNSS, RADVD supports RDNSS…

Which major router platforms are you thinking of that don’t support RDNSS?

In terms of hosts, Apple supports RDNSS, Linux supports RDNSS, Android supports RDNSS, Windows can do RDNSS client using an open-source add-on since Windows Vista.

OTOH, DHCP6 is not supported by Android.

So looking at the support matrix, it seems to me that from the host implementation perspective, more hosts support RDNSS than don’t and in terms of installed base, more phone handsets are ready for RDNSS than are ready for DHCP6.

When you say “The operator Community”, what you really seem to mean is “The enterprise IT community” which is a large subset of the operator community, to be sure, but not the entire operator community. The reality is that there is an equally important fraction of the operator community in the form of service providers, cloud platforms, research and education networks and others, many of whom actually do find SLAAC and RDNSS useful, have implemented it, are running networks with it, etc. There is a significant installed base of RDNSS/SLAAC networks out there and pretending that they don’t exist does not advance this discussion in a useful way.

>> for host autoconfig, then supporting dhcpv6 in the host stack

Such as? One of the biggest disadvantages it has in many of the networks I deal with is the addition of an entire unnecessary service and protocol stack to perform a function which is easily handled by an additional optional datum in the RA packet (namely the RDNSS option(s)).

Why do I want to have to spin up a DHCP server and manage it vs. a two-line configuration of additional options in an RA I already have to configure in order to give the host an address and default router to begin with?

> You said it far more elegantly than I did, but this is the gist of what I was trying to get across the other day.

I’m not in favor of shutting down or shouting down DHCPv6 development, but I’m flat out fed up with the status quo as it has come from the IETF so far.

The current situation is untenable to operators and end users because there’s no consistent set of guidelines or requirements that create a guaranteed interoperability between any two platforms.

As such, I’m in favor of making both DHCPv6 and RDNSS support a must for all routers/servers and a must for all clients which are not otherwise resource constrained to the point that this is infeasible. For constrained clients, I support RDNSS as a should and dhcpv6 as a desirable.

Instead of trying to ram any policy agenda or beat anyone up using the IETF process, I’m trying to beat the IETF into producing a usable standard that allows the operator to decide what is best in his particular network.

Does this come at a cost to vendors? Sure… You bet it does. SO WHAT!! Vendors are in the business of supplying what operators need. If they want to serve an operator community that has grown sufficiently diverse that no one autoconfiguration solution fits all needs, then they will have to do just that… Support more than one solution to meet the needs of that diverse community. That’s what we pay them to do.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 15:23:52 -0700

> On Apr 2, 2017, at 10:55 AM, Ted Lemon <[email-masked]> wrote:
> 
> On Apr 2, 2017, at 10:43 AM, Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:

IIRC, there are at least 4 packets required to get an address and full set of options from DHCP, so it’s actually 3x the packets (RS+RA+DHCPx4 vs. RS+RA).

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 15:31:17 -0700

> That is a matter of perspective, on which we disagree.

IMHO, this is because your perspective is rather limited and apparently rather enterprise-IT specific to the exclusion of all others.

> Sorry, again we disagree here. As you pointed out, different networks and environments have different needs.

Right…

> Let's give a theoretical counter-example to the IOT case. If I am a vendor creating a product that needs more configuration options than are available through SLAAC, I know that I have to implement a DHCP client. Since I'm doing DHCP anyway, all of the time that I spend on RDNSS implementation (which I would need to do in order to check the "Complies with RFCNNNN" check box that my customers will be looking for) completely wasted. Further, if customers find out that the RDNSS support exists, some of them will try to use it. Many of them will get it wrong, thus increasing my support costs. All of this for exactly zero benefit.

If you’re implementing a host that is so tightly tied to its application that you can predict this in advance, then perhaps what is appropriate is to create a further exemption for “Purpose Built Hosts” and reduce the requirement scope to “hosts suitable for multiple purposes or likely to be subject to diverse network requirements”.

> Going back to the IOT crowd, they raise Cain every time DHCP is even hinted at, it's not reasonable to expect that they will agree to making it mandatory to implement, never mind actually go out and implement it.

Actually, I think you are wrong about that. I think that if you look at the cain they raise, it’s almost all specifically about resource constrained hosts. If you grant an exemption for those hosts, I think you’d see a lot more willingness.

> We're all in agreement that the status quo sucks. But saying that both protocols should be mandatory is a political decision, it's not good engineering.

Both protocols exist. Not requiring a compatible subset across all implementations is bad engineering.

Requiring DHCP across everything is a non-starter because resource constrained hosts really do exist and will continue to be a reality.

Requiring RDNSS across everything is a non-starter because you exist and there’s a vocal contingency of DHCP zealots to back you up.

So… The only pragmatic solution is to require both across the broadest possible set of hosts, exempt DHCP where absolutely necessary, perhaps exempt RDNSS where its omission is unlikely to cause harm, and move on.

If you have a better solution, I’m all ears.

Owen

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 15:35:32 -0700

> I know of a number of large service provider installations that do not use DHCP6 for host addressing.

Bully for them, but that's not relevant to my argument. I am curious 
though, how are they doing PD, and if they are not, how do they handle 
addressing their customers?

> There are, in fact, many such networks. Perhaps not in “enterprise IT", but in a number of research, education, trade show, service provider, and other installations, this is, in fact, the case.

I never said, "Everyone wants to do, or is doing, DHCP." My argument is 
that in ENTERPRISE networks, where the vast majority of dollars are 
spent, and where the largest numbers of hosts are under management, the 
operators have spoken overwhelmingly in favor of DHCP.

It's also worth pointing out that in many of your examples, particularly 
things like trade shows where the expectation is that attendee's hosts 
will "just work" the reason that they can get away with not running 
DHCPv6 is that they are already running it for v4, and the relevant 
configuration is being provided that way. In those cases they wouldn't 
be running RDNSS, either.

> Doing a lookup for an AAAA record and doing something useful with the result does not take nearly as much memory as doing that _AND_ running enough of a DHCP stack to process IA_NA and all the othe…

I don't understand this answer. Who said anything about IA_NA?

What I'm looking for is an actual comparison between SLAAC (defined here 
as RA + RDNSS) and stateless DHCP, including the same DNS configuration 
info. In other words, apples to apples.

Until we get some actual numbers we are simply arguing political merits, 
not engineering merits.

If the proponents of "make RDNSS mandatory to implement" do not want to 
do that work, that's Ok, but their proposal should then be rejected for 
lack of evidence of merit.

> Remember, even if you require DHCP and abandon RDNSS entirely (bad idea IMHO),

... and as I've stated several times now, is not at all what I'm proposing.

> you’re still in a situation where you need the full stack to do the DNS lookup, do something useful with it, _AND_ the full DHCP client _AND_ most of the RA stack exclusive of the tiny part that parses and processes the RDNSS option.

... which is why we should have a full featured DHCP option in v6, so 
that those that don't want SLAAC shouldn't have to implement it.

And your argument is moot if the host in question needs additional 
configuration options beyond RDNSS.

> OTOH, if you support RDNSS, then you only need the full stack to do the DNS lookup, do something useful with it, _AND the RA stack.

So, those that are designing products that meet this criteria *already 
have* the solution that they need. Making RDNSS mandatory doesn't change 
their situation in any way.

> Frankly, vendors are telling me that part of the reasons these things don’t exist yet is because they can’t depend on RDNSS support in their client environments due to the lack of consistent IETF g…

Thank you for validating my point that RDNSS has failed to gain market 
share. Your experience echoes my own in this area.

However it's mystifying to me that while recognizing that we have one 
failed "solution looking for a problem" and one successful solution that 
matches what operators want, and already have deployed; your proposed 
fix is to bulk up the failed solution.

I am sorry to repeat myself yet again, but that is a bad engineering 
decision. The correct engineering decision is for us to make DHCP 
robust, and allow implementors that do not want SLAAC to do away with it 
entirely.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 15:34:43 -0700

> On Apr 2, 2017, at 1:05 PM, Doug Barton <[email-masked]> wrote:
> 
> Yes. That was the completely predictable result of the introduction of new options to SLAAC beyond RA, and the core objection made by those of us who have been opposing additional such options for over a decade.

You’re kidding, right?

RDNSS was the completely predictable and all too needed result of the introduction of SLAAC without RDNSS and the idiotic assumption that you could run a network without name servers unless you were willing to deal with the overhead of running both RA and DHCP together.

> I've snipped the rest of your message because we all know how we got here. We have created this mess by allowing the anti-DHCP crowd to run the asylum. We need to stop letting that happen.

One could argue that we created this mess by allowing the pro-DHCP crowd to mess up the asylum in the first place, but I understand why you don’t share my perspective there.

What we really need to stop is we need to stop letting the religious war between the anti-SLAAC crowd and the anti-DHCP crowd get in the way of useful progress for the rest of the world.

I am pro-SLAAC and pro-RDNSS.

I am not anti-DHCP, though if I were going to do away with one or the other, it wouldn’t be SLAAC/RDNSS that would get my vote.

IMHO, the rational solution is to let the operator choose what is best in their environment. The only way to do that is to require vendors to implement both wherever feasible.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 15:38:33 -0700

> On Apr 2, 2017, at 12:59 PM, Doug Barton <[email-masked]> wrote:
> 
> 
> 
> I'm with you on needing to spec things that meet actual market demands. But, a few questions related to that theoretical device.
> 

Because a lot of these sensor packs deliver their data by making an HTTP POST request.

> 2. What is it using to make the DNS lookups?

Usually a library call to gethostinfo()

> 3. How does the size/complexity of the code necessary for stateless DHCPv6 to get address and/or DNS configuration compare to the size/complexity of the equivalent code for SLAAC?

99% of the code for SLAAC is needed just to get to where you can see the M bit and act on it to go ask DHCP6 the question.

The added code to process the RDNSS option in the RA packet is pretty small. Maybe 1 or 2k octets on most platforms.

Most DHCP6 implementations are on the order of 32K or more in my experience.

> Until we have those answers, I agree with Fred that this is a purely political discussion.

Political or not, the reality is that the current status quo sucks for network operators and end users and unless someone has a better solution to that situation, whether it’s considered political or technical, we should do this.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Apr 2017 10:52:20 +1200

Doug,

A few points, on three of your messages:

> way they want to in any case.

Your understanding of statistics and probability seems to be a bit different
from mine. What we have out there is, in practice, a random mixture of hosts
of all ages connected to a random mixture of better or worse managed networks
using routers of all ages. All I'm saying is that the more implementers are
chivvied in the direction of implementing both solutions, the more
interoperability we will get, statistically, over the next decades. That is
true precisely *because* operators will configure their networks the way
they want to, not the way some RFC says.

> the asylum. We need to stop letting that happen.

That is grossly unfair. My recollection is that RDNSS was added not as
an anti-DHCP provocation, but because we have always had a target "market"
for IPv6 that we referred to in the early days as the "dentist's office
scenario" where people with zero skill could plug stuff together and
it would work. Given SLAAC, the only missing link for that sceanrio was
DNS server configuration, and that is why RDNSS was specified. And it
works.
> can't expect everyone to keep everyone's resumes in mind all the time, 

My observation is that the word "implement" is ambiguous. I have often
heard or seen it used such that it was impossible to know whether
it meant "write the code" or "switch it on."

> be pushing the cost of its own inability to get its act together onto 

We've specified doing the same thing in two different ways. What we haven't
done, evidently, is describe the scenarios in which the two solutions are
more, or less, appropriate. That's a gap.

    Brian

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 15:54:24 -0700

> In terms of hosts, Apple supports RDNSS, Linux supports RDNSS, Android supports RDNSS, Windows can do RDNSS client using an open-source add-on since Windows Vista.

Owen, you said yourself in another message that vendors don't make 
products that rely on RDNSS because they know they can't rely on it 
being present in a network.

And yes, many vendors have solutions for RDNSS, but they are not all up 
to the same level of compliance with the latest RFCs, and this feature 
is not a reason anyone is going to be buying new hardware/software. The 
mere fact that a solution exists, in some form, does not mean that it is 
reliable, or widely deployed. Again, as you yourself have pointed out.

> OTOH, DHCP6 is not supported by Android.

Yes, that's a result of Lorenzo's religious decision not to support it. 
That isn't evidence that RDNSS is good, or that DHCP is bad.

> So looking at the support matrix, it seems to me that from the host implementation perspective, more hosts support RDNSS than don’t

How do you leap to that conclusion?

> and in terms of installed base, more phone handsets are ready for RDNSS than are ready for DHCP6.

How many of those handsets also support DHCPv4, and how many of them are 
operating on v6-only networks? (And yes, I realize that the latter 
number is larger than most people realize.)

> When you say “The operator Community”, what you really seem to mean is “The enterprise IT community” which is a large subset of the operator community, to be sure, but not the entire operator commu…

I have very intentionally avoid using the term "important" in my 
discussion, because I agree that the other use cases you describe are 
also "important," whatever that means. See my previous response for why 
your arguments about some of those environments not doing DHCPv6 don't 
hold up.

Meanwhile, my argument is that yes, it's largely enterprise network 
operators who are clamoring for robust DHCPv6, but that is "important" 
(again, for whatever value you want to place on it) because that's where 
the bulk of the money is going to be spent, and where the bulk of the 
hosts under management exist.

I think all the low-power, IOT, restricted devices, etc. etc. are 
awesome (to the extent that they have decent security, can't be used as 
DDOS vectors, etc.) and I am not saying that RDNSS should be taken away 
from them. But (again, repeating myself) making it mandatory doesn't 
help those people. If they need it, they are already running it.

> Why do I want to have to spin up a DHCP server and manage it vs. a two-line configuration of additional options in an RA I already have to configure in order to give the host an address and default…

If you don't want to run DHCPv6, don't. I don't care. :)  My point is 
that people are going to run DHCP should not have to ALSO run SLAAC. To 
them, SLAAC is all the things you just said you don't like about DHCP.

Seriously, please try to understand what I just wrote.

> The current situation is untenable to operators and end users because there’s no consistent set of guidelines or requirements that create a guaranteed interoperability between any two platforms.

That would not be the case if we made DHCPv6 robust, given that the 
market has already expressed its preference for it. If operators could 
do DHCP-only that is what they would implement, and you could rely on it 
being present for any network where there are hosts more complex than 
toasters.

The status quo is the result of the anti-DHCP crowd refusing to give up 
on making SLAAC/RA mandatory.

Making it "more mandatory" is, therefore, not the answer.

Further, the anti-DHCP people know this, which is why they keep trying 
to make SLAAC more robust, and more mandatory.

> Does this come at a cost to vendors? Sure… You bet it does. SO WHAT!! Vendors are in the business of supplying what operators need. If they want to serve an operator community that has grown suffic…

This is laughably out of touch with reality. (You need only to look at 
the status quo to demonstrate that I'm right.)

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 16:11:02 -0700

> IMHO, this is because your perspective is rather limited and apparently rather enterprise-IT specific to the exclusion of all others.

I've addressed this several times already. I will simply repeat my point 
that your perspective is obviously wrong because the market has not 
aligned itself to it.

> If you’re implementing a host that is so tightly tied to its application that you can predict this in advance, then perhaps what is appropriate is to create a further exemption for “Purpose Built H…

No, more arguments about how to define "constrained host," "purpose 
built host," etc. are not only not going to help, they are going to make 
the problem worse (and make it that much more difficult to reach 
consensus).

Let RA+RDNSS continue to exist for those whose needs it meets. For those 
folks, they know that's all they need, so that's all they run. I am 
totally fine with that. (POWER TO THE PEOPLE!)

> Actually, I think you are wrong about that. I think that if you look at the cain they raise, it’s almost all specifically about resource constrained hosts. If you grant an exemption for those hosts…

But if you don't over-engineer the spec in the first place, you don't 
have to "grant exceptions." And if you do need to grant exceptions, your 
idea of "mandatory" is seriously flawed.

> Both protocols exist. Not requiring a compatible subset across all implementations is bad engineering.

Sorry, you're just flat-out wrong here. The fact that there is not "One 
True Solution" is offensive to certain mindsets, but it doesn't match 
the operational reality.

> Requiring RDNSS across everything is a non-starter because you exist and there’s a vocal contingency of DHCP zealots to back you up.

Thank you for giving me so much credit. :)  But the fact that there are 
so many "DHCP zealots" probably should give you the idea that we're on 
to something. As I've pointed out several times now, if we are going to 
run DHCP anyway, then there is no reason for us to support RDNSS. Every 
dollar and person-hour spent on supporting that option is wasted. The 
IETF mandating it to satisfy a certain mindset that needs "One True 
Solution" is ludicrous on its face.

Further, as you so ably point out, "Mandate both" is never going to 
happen, there are always going to be exceptions, and that can only lead 
to more confusion, and more "angels on the heads of pins" debates about 
what is and isn't an exception. So not only do you not get what you're 
asking for, you make the problems (and arguments) worse instead of better.

> If you have a better solution, I’m all ears.

I've already pointed out that your thinking on possible solutions is 
severely constrained by assuming that SLAAC must always exist.

I have offered a better solution here, and have have been offering it 
for over a decade:

Let SLAAC/RA (and I guess we'll thrown in RDNSS too) exist for those who 
want it, and for whom it meets their needs.

Let DHCP hand out network and gateway information so that those who are 
going to run DHCP anyway can do so without SLAAC.

That is the simplest, lowest common denominator, best ENGINEERING 
solution. It eliminates the costs and complexities involved for those on 
the host side who only need one solution, and it will allow the market 
to gravitate in the direction that the money already wants to go.

The only reason NOT to follow that plan is to continue to cater to those 
who want to avoid DHCPv6 at all costs. But that's what got us into this 
mess in the first place.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 16:23:00 -0700

>> Yes. That was the completely predictable result of the introduction of new options to SLAAC beyond RA, and the core objection made by those of us who have been opposing additional such options for…

No, not at all.

> RDNSS was the completely predictable and all too needed result of the introduction of SLAAC without RDNSS and the idiotic assumption that you could run a network without name servers unless you wer…

Yes, many of us pointed out at the time that RA alone would never be 
sufficient. Nice to see that there are many things that we agree on. :)

At the time IPng was happening, DHCP in the v4 world did not have the 
dominant position that it does now. The idea of having a lightweight 
mechanism to provide addressing information to get a host on the network 
had a lot of merit at the time, and there are still substantial use 
cases for it. Far from being seen as a nuisance, "Plan A" was to get the 
hosts on line with RA, then reach out to DHCP, or some other 
configuration mechanism, to get the rest of the data a host needed.

But over time the world has changed.

DHCP is now firmly entrenched, and is overwhelmingly the dominant method 
of host configuration (where "host" includes customer premises routers 
for v6 PD). I could make an argument that this was true as far back as 
2003, and indeed I (and others) said so at the time, and have been 
saying so ever since.

The situation we have ourselves in now is a result of the pro-SLAAC (or 
anti-DHCP) crowd refusing to budge on requiring RA for addressing 
configuration. If we could have gone DHCP-only 10 years ago, we would 
have. That's still true today.

> IMHO, the rational solution is to let the operator choose what is best in their environment.

... except that they can't. All of your arguments are predicated on the 
idea that SLAAC/RA MUST continue to exist on the wire. That's the wrong 
way to look at the problem.

And as I've said several times now, I'm not anti-SLAAC. I think it's a 
great solution to a specific problem. But what we've known for over a 
decade is that it's not a *general* solution for host configuration. 
That solution is DHCP, and DHCPv6 should be given the ability to handle 
all of the host configuration, in the absence of SLAAC, specifically so 
that operators CAN choose the configuration that works for them.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 16:32:26 -0700

This'll be my last one for a bit, as I'm repeating myself (apologies to 
the group), and we're going around in circles. But I think there is one 
more important point in this post, so please bear with me just a little 
bit longer.

> Usually a library call to gethostinfo()

Thank you for answering this, I think it's useful info. Out of 
curiosity, what are the sizes of the HTTP stack, and the gethostinfo() 
stack?

The reason I ask is that I'm trying to get an understanding of what is 
the marginal cost of DHCPv6 in the case of a host that already has 
enough code complexity to warrant needing name server data in the first 
place.

> 99% of the code for SLAAC is needed just to get to where you can see the M bit and act on it to go ask DHCP6 the question.

What is the size of this part of the stack?

> Most DHCP6 implementations are on the order of 32K or more in my experience.

Your argument is that RDNSS is a tiny marginal cost to the size of the 
SLAAC stack in the first place. (Which matches my expectation, for 
whatever that's worth.)

What I'm trying to get at is an apples-to-apples comparison of the 
ENTIRE size of the SLAAC stack (including RDNSS) vs. the size of the 
DHCPv6 stack needed to do ~the same tasks.

The reason for asking this question is that (as I've pointed out 
already) your arguments are all predicated on "SLAAC must continue to 
exist in its current form." If we take away that premise, other 
solutions present themselves.  :)

Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Apr 2017 11:54:45 +1200

On 03/04/2017 11:23, Doug Barton wrote:

...
> that operators CAN choose the configuration that works for them.

If you're arguing that there should be a DHCPv6 option to communicate
the default router, I couldn't agree more, for exactly the same reason
that we added RDNSS to RAs: so that both solutions can support a least
common denominator for communication: address, router, DNS server.

   Brian

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 17:06:00 -0700

On 04/02/2017 03:52 PM, Brian E Carpenter wrote:
> from mine.

For what it's worth, mine is based on decades of experience configuring, 
and working with large enterprises to configure, DNS and DHCP solutions 
that meet real world needs.

> What we have out there is, in practice, a random mixture of hosts
> using routers of all ages.

Total agreement here.

> All I'm saying is that the more implementers are

On this point I don't follow you at all. The market has "voted" 
overwhelmingly in favor of deploying DHCP, and not deploying RDNSS. My 
point was that requiring vendors to implement RDNSS does nothing to 
encourage operators to deploy it.

Where did I go wrong there? (That's a sincere question, if I missed 
something I want to know.)

> DNS server configuration, and that is why RDNSS was specified. And it

I am sure that is your recollection of the situation, and I don't fault 
you for it. I was around when RDNSS was first suggested, and I remember 
the same conversations you do (including the dentist's office scenario).

However, I also remember that the very first proposed version of what 
became RDNSS had only the name server list. Those of us who were deeply 
involved on an operational level doing actual host configuration pointed 
out that the name server list is only one of several features that hosts 
on modern networks need to do name lookups, and that at minimum you 
would also need to include the search string feature, and that really if 
you have a host with sufficient complexity that it needs to do DNS 
lookups in order to get its job done the right answer is to use DHCP, 
which will be able to provide all of the appropriate configuration.

The response to that conversation was not, "Oh, I see ... thanks!" It 
was instead, "Ok, we'll add the search string!" on the one hand, 
followed by over a decade of denial that DHCP is the right answer here, 
along with further attempts to glue necessary configuration elements 
into SLAAC.

So from your perspective adding RDNSS was a perfectly reasonable 
response to the realization that RA alone was not sufficient. From mine 
it was the result of the complete failure to recognize that RA alone 
only ever applied to a very limited set of hosts, and never should have 
been made mandatory to implement in the first place.

On the one hand there continues to be lack of enthusiasm for RA in the 
marketplace, along with ongoing clamor for robust DHCP. On the other 
hand, the response from the IETF has been continued insistence that RA 
remain mandatory.

You may take offense at my characterization of this situation being 
allowed to exist for the better part of 14 years, followed by the 
current recommendations to make RDNSS, or both RDNSS and DHCP mandatory 
to implement (the latter being something that even its proponents 
recognize isn't realistic) as "the inmates are running the asylum," but 
I frankly can't see any other way to describe it.

> We've specified doing the same thing in two different ways.

Only in the sense of RDNSS.

> What we haven't

I don't think there is any confusion on that point in the operator 
community. The extraordinarily limited situations where RA+RDNSS are 
sufficient on their own are well understood by the people that are 
operating those types of hosts.

Everyone else wants DHCP.

It's not the operators who are confused. :)

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 2 Apr 2017 17:10:10 -0700

> common denominator for communication: address, router, DNS server.

Hooray!  I am genuinely happy to see common ground on this topic. :)

Is it finally time to get it done?

Doug

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 20:08:29 -0700

> On Apr 2, 2017, at 3:35 PM, Doug Barton <[email-masked]> wrote:
> 
> Bully for them, but that's not relevant to my argument. I am curious though, how are they doing PD, and if they are not, how do they handle addressing their customers?

You asked for an example where such networks might exist. How can that possibly not be relevant to your argument? I just provided you several examples.

Not all large service providers are ISPs and even among ISPs, not all do dynamic prefix delegation. This kind of builds on my point about your perspective being apparently rather limited vs. the larger world out there.

> I never said, "Everyone wants to do, or is doing, DHCP." My argument is that in ENTERPRISE networks, where the vast majority of dollars are spent, and where the largest numbers of hosts are under management, the operators have spoken overwhelmingly in favor of DHCP.

First, given the modern trend of cloud computing, I’m not completely convinced that ENTERPRISE necessarily actually represents either the majority of dollars or the majority of hosts.

Regardless of whether that’s true or not, the bottom line is that in the wider world, there are real needs for SLAAC and RDNSS on real networks even if they aren’t networks that matter to you and arguing that vendors shouldn’t be required to accommodate those needs and that only DHCP should be mandatory is counter-productive.

> It's also worth pointing out that in many of your examples, particularly things like trade shows where the expectation is that attendee's hosts will "just work" the reason that they can get away with not running DHCPv6 is that they are already running it for v4, and the relevant configuration is being provided that way. In those cases they wouldn't be running RDNSS, either.

Simply not true. As an example, at the last Southern California Linux Expo (SCALE 15x), while we did run DHCP4, we did provide IPv6 name server information via RDNSS and we had a significant amount of IPv6 DNS traffic and lots of IPv6 traffic in general. The vast majority of hosts on the network did just work with SLAAC and RDNSS. Admittedly, there were almost no Windows hosts in this case, but, frankly Windows is increasingly becoming a minority at many of the trade shows and conferences I attend. (Windows being the only remaining major operating system without RDNSS support).

> What I'm looking for is an actual comparison between SLAAC (defined here as RA + RDNSS) and stateless DHCP, including the same DNS configuration info. In other words, apples to apples.

Fine…

IPv6 — Approximately 64k of code or 6LOWPAN approximately 32k of code
RA — Approximately 18-30k of code
RDNSS — Approximately 2k of code
DNS Resolver — Approximately 12k of code
TCP stack — Approximately 24k of code
UDP stack — Approximately 14k of code
DHCP stack — Approximately 32k of code
HTTP client — Approximately 12k of code

So, for minimal RA+RDNSS+HTTP we need IPv6 (64k) + RA (30k) + RDNSS (2k) + DNS (12k) + TCP (24k) + UDP (14k) + HTTP (12k)
Total: 158k (+ ~16k RAM for state/configuration information)

For RA+Stateless DHCP+HTTP we need IPv6 (64k) + RA (30k) + DHCP (32k) + DNS (12k) + TCP (24k) + UDP (14k) + HTTP (12k)
Total: 188k (+ ~30k RAM for state/configuration information)

Difference: 30k FLASH and ~14k RAM

Doesn’t sound like a lot, but on a host with ≤512k of FLASH memory total, you’re talking almost 10% of the total RAM just to support DHCP with no advantage whatsoever to the application vs. RDNSS.

Worse, many of these hosts have 64k or less of actual RAM, so a difference of 14k is meaningful.

> Until we get some actual numbers we are simply arguing political merits, not engineering merits.

Hopefully that helps. Those numbers are from a while ago and more efficient stacks may be available, but they should provide reasonable guidance.

> If the proponents of "make RDNSS mandatory to implement" do not want to do that work, that's Ok, but their proposal should then be rejected for lack of evidence of merit.

That work has been done by several. Of course, part of it is that the numbers are quite variable depending on processor architecture, codebase, etc. so the numbers I provided above might not reflect anyone else’s particular installation.

> ... and as I've stated several times now, is not at all what I'm proposing.

Sure it is… Just not in so many words. You want to make DHCP mandatory and insist that Google has to saddle the Android platform with it, but you don’t want to require router vendors to support RDNSS.

> ... which is why we should have a full featured DHCP option in v6, so that those that don't want SLAAC shouldn't have to implement it.

Even if you somehow leave out SLAAC, you still need to parse the rest of the RA. Let’s assume you could cut back from 30 to 18k (pretty optimistic) by eliminating the parsing of the A bit, the Prefix options in the packet, etc. You’ve still only reduced things by 12k of the 30k you’re adding, so it’s still a bad idea.

> And your argument is moot if the host in question needs additional configuration options beyond RDNSS.

But most hosts just don’t need additional configuration options beyond RDNSS with the notable exceptions of enterprise and imaging (and not all imaging).

> So, those that are designing products that meet this criteria *already have* the solution that they need. Making RDNSS mandatory doesn't change their situation in any way.

Sure it does. In the case of router vendors that don’t yet support RDNSS, or, in the situation where they are (for reasons admittedly passing understanding) saddled with Windows Servers.

OTOH, it does mean that adding the RDNSS requirement really doesn’t effect very many people other than a few developers in Redmond, WA.

> Thank you for validating my point that RDNSS has failed to gain market share. Your experience echoes my own in this area.

Huh? What I’ve said is that because there are notable failures of client implementations to support RDNSS, there are products that are holding off on IPv6 implementations.

If you want to use that as a justification to claim RDNSS has failed to gain market share, then I will hold up the fact that Android has refused to implement DHCP6 as an equally valid indication that DHCP6 has failed to gain market share and thank you for making the same point about DHCP.

The reality is that both are failures by vendors that are harming real networks and both should be rectified.

> However it's mystifying to me that while recognizing that we have one failed "solution looking for a problem" and one successful solution that matches what operators want, and already have deployed; your proposed fix is to bulk up the failed solution.

First, you are putting words in my mouth that simply don’t represent anything remotely resembling my perspective or my statements.

If there is a failed solution looking for a problem here, it’s DHCP. However, I don’t think that is the case, either.

I would say that we have a combination of failed solutions which have resulted in incompatible implementations on both the “address consumer” and the “address supplier” side of the equation which has become an untenable failure which is preventing deployment and adoption of IPv6 overall.

My solution is to mandate that both the address consumer developers and the address supplier developers be required to provide implementations capable of supporting BOTH solutions wherever feasible so that operators can choose whatever combination of solutions best fits their particular environment.

The mechanisms to enable operators to do so already exist in the form of the A, M, and O bits of the RA. The part that is missing (and the most notable failures) are RDNSS client support (Microsoft) and DHCPv6 Client support (Android).

> I am sorry to repeat myself yet again, but that is a bad engineering decision. The correct engineering decision is for us to make DHCP robust, and allow implementors that do not want SLAAC to do away with it entirely.

I argue that’s a worse engineering decision than making the smallest number of effective changes necessary to resolve the current situation, namely, requiring the developers/vendors to implement both solutions whenever feasible. The simple reality is that if Microsoft would incorporate RDNSS support and Android would incorporate DHCPv6 Client support, we’d actually be more than 99% done with this issue.

I’m not sure why you are so resistant to this or why you believe that solving the enterprise at the expense of virtually every other stakeholder group somehow is a good engineering decision.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Apr 2017 12:24:03 +0900

> Is it finally time to get it done?

Only if you have reason to believe that a new attempt to get consensus is
going to be more successful than the past three. I very much doubt that's
the case; in fact, if you proposed it again, I expect you'd see more
opposition from host OS developers than there was last time.

We've seen how there has been substantial opposition to "MUST implement
getting DNS servers from stateless DHCPv6" from those developers -
including developers of major OSes that *already implement it*. I'd expect
those developers would oppose a DHCPv6 route option even more, citing the
clear disadvantages it has compared to RA-only routing configuration such
as inability to support multiple sources of information,
difficulty/inability to update things due to lack of RECONFIGURE support,
lack of fate sharing, difficulty in supporting
draft-ietf-rtgwg-enterprise-pa-multihoming, lack of necessity given that we
already have a way to configure routing, complexity due to having two ways
of configuring the same information, etc.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 22:49:08 -0700

> On Apr 2, 2017, at 3:54 PM, Doug Barton <[email-masked]> wrote:
> 
> Owen, you said yourself in another message that vendors don't make products that rely on RDNSS because they know they can't rely on it being present in a network.

Sure, but those same vendors don’t make products that rely on DHCP6 support because they can’t afford the bloat in the code base that would require.

Further, they can’t exactly depend on DHCP6 being there, either, so the assumption that my statement somehow supports the idea that RDNSS and SLAAC are unnecessary and only DHCP is needed is an absurd over-extension of my statement into something I obviously didn’t say.

> And yes, many vendors have solutions for RDNSS, but they are not all up to the same level of compliance with the latest RFCs, and this feature is not a reason anyone is going to be buying new hardware/software. The mere fact that a solution exists, in some form, does not mean that it is reliable, or widely deployed. Again, as you yourself have pointed out.

Right and the reality is that as long as we continue this idiotic deadlock of arguing for one solution over another at the specification level instead of recognizing that there are legitimate needs for both solutions in the real world and we therefor need to require vendors to implement both solutions wherever feasible so that we can get rid of the negative effects of the stupid religious war and move forward with deployment recognizing that operators need to be free to choose the solution that best fits their application instead of trying to let the IETF or vendors pick for them, and, especially instead of allowing vendor A to choose a single incompatible implementation option on the server side from the single implementation chosen by a vendor B on the client side.

The simple fact is that if you have a router that supports both DHCP6 and RDNSS and a client that supports both DHCP6 and RDNSS, then you have a situation where the operator can choose any combination that works for them.

OTOH, if you have a router that only supports DHCP6 and a client that only supports RDNSS, then you’re screwed.

Similarly, if you have a router that only supports RDNSS and a client that only supports DHCP, you’re also screwed.

So, it seems to me that the clear choice is to require implementations (note, this is software/hardware implementations, not deployments) to provide support for both and allow the operator to configure the choice they want. This should _NOT_ require specific client configuration except in the case where the operator wants to use static client configuration.

Short of the MUST on RDNSS and DHCP6 support, everything necessary to achieve this is in place.

> Yes, that's a result of Lorenzo's religious decision not to support it. That isn't evidence that RDNSS is good, or that DHCP is bad.

I could argue that the failure to support RDNSS on Windows and Windows phones is equally religious stupidity on Microsoft’s part, but really, where does that get us… Nowhere useful.

> How do you leap to that conclusion?

Windows hosts can support RDNSS (admittedly with open source add-on software). Between Linux, Mac, and Windows, you have the vast majority of non-phone hosts covered.
Beyond that, it’s mobile devices (tablets/handhelds). Windows Phone is the only major tablet/handheld OS that doesn’t support RDNSS and that’s clearly a tiny fraction of the overall market.

So in summary, supports RDNSS: Windows, Linux, Mac, iOS, Android
Does not support RDNSS: Windows Phone

If you want to argue that there are more hosts in the “Windows Phone” camp than all the others, I think that’s a pretty hard case to make.

If you are willing to stipulate to the fact that Windows+Linux+Mac+iOS+Android = more hosts than Windows Phone, then I’d say my statement stands…

More hosts support RDNSS than do not.

If you want to make the argument that Windows doesn’t support RDNSS because it requires add-on software, that might be a somewhat valid case, but even there, I don’t think Windows desktop is enough to really tip that balance, though I will admit it might come closer.

According to Gartner, device shipments, 2015:
	Android	54%
	iOS/Mac	12.3% (276M iOS, 21M macOS)
	Windows	11.7%
	Others	21.6%

So even if we put Windows and Others (whatever they are) together and assume that they don’t support RDNSS, you’re looking at 33.3%, well under half.

Android alone being 54% of all device shipments in 2015 (not an anomalous year from looking at earlier statistics), and Windows showing a declining trend in terms of market share, I think you’re really hard pressed to make the case that I am wrong, EVEN if you include Windows desktop as “not supporting RDNSS”.

> How many of those handsets also support DHCPv4, and how many of them are operating on v6-only networks? (And yes, I realize that the latter number is larger than most people realize.)

Probably all of them support DHCPv4, but so what and who cares?

How is that at all relevant to the damage caused to v6 deployment by allowing vendors to implement incompatible subsets of IPv6 host auto configuration and still claim compliance with the host requirements RFCs?

> I have very intentionally avoid using the term "important" in my discussion, because I agree that the other use cases you describe are also "important," whatever that means. See my previous response for why your arguments about some of those environments not doing DHCPv6 don't hold up.

Your previous response didn’t really hold up IMHO.

> Meanwhile, my argument is that yes, it's largely enterprise network operators who are clamoring for robust DHCPv6, but that is "important" (again, for whatever value you want to place on it) because that's where the bulk of the money is going to be spent, and where the bulk of the hosts under management exist.

OK, so what? I’m not arguing against robust DHCPv6, I’m arguing for robust requirements to support both so that operators can decide which one to use in their network deployments. Meanwhile, you seem to be arguing that RDNSS should remain a second class citizen which seems ridiculous and utterly unjustifiable to me.

> I think all the low-power, IOT, restricted devices, etc. etc. are awesome (to the extent that they have decent security, can't be used as DDOS vectors, etc.) and I am not saying that RDNSS should be taken away from them. But (again, repeating myself) making it mandatory doesn't help those people. If they need it, they are already running it.

Wrong and wrong and wrong again. Lots of them are getting implemented IPv4 only _BECAUSE_ there are still enough installations that don’t have router-side RDNSS support. Cisco has only added it fairly recently. There are still some vendors that don’t support it, unfortunately. Making it mandatory on the router side ABSOLUTELY helps this situation.

> If you don't want to run DHCPv6, don't. I don't care. :)  My point is that people are going to run DHCP should not have to ALSO run SLAAC. To them, SLAAC is all the things you just said you don't like about DHCP.

You don’t have to run SLAAC… You are perfectly free to set the M bit, turn off the A bit, take the PREFIX options out of your RA and you can already run DHCP without SLAAC, so I’m really not sure what your bitching about.

> Seriously, please try to understand what I just wrote.

I completely understand what you just wrote… Do you?

Are you trying to say you should be able to run DHCP without depending on RAs? In that case, how does an unconfigured host decide which protocol to ask for which information? Where does it get its default router information? Please elaborate on exactly what incredibly poor engineering decision you are proposing.

Note, I’m being very specific here… If you truly mean without SLAAC, then, an RA with M=1, O=1, A=0 and no prefix options will do _EXACTLY_ what you have specified already.

If you mean without RAs, then that really is a different kettle of bad ideas.

> That would not be the case if we made DHCPv6 robust, given that the market has already expressed its preference for it. If operators could do DHCP-only that is what they would implement, and you could rely on it being present for any network where there are hosts more complex than toasters.

But the MARKET hasn’t done so. Some segments of the market have expressed a strong preference for DHCP6. Other segments have expressed a strong preference for SLAAC and RDNSS.

Operators _CAN_ do DHCP only today. I’m not sure why you are arguing that they can’t, nor have you made it clear what you mean by “made DHCP6 robust”. Since I don’t have any implementations where I actually care about DHCP for anything other than PD, I admit I didn’t consider it particularly relevant to the discussion of an acceptable solution, but now that you’re arguing that “robust DHCP6” (whatever that means) is somehow a magic bullet that solves the problems of all the hosts outside of the enterprise too, let’s hear what you have to offer and see if it actually holds up.

> The status quo is the result of the anti-DHCP crowd refusing to give up on making SLAAC/RA mandatory.

I call BS on this.

I’m _NOT_ anti-DHCP. DHCP is a fine protocol for what it does and where it is needed/useful. The addition of DHCP-PD is especially useful (and the only real use I’ve found for DHCP in _ANY_ implementation I have worked on, though I do understand its usefulness in the enterprise desktop support context (which is a world I have fortunately avoided for the majority of my career)).

The status quo is the result of the combination of failures to make proper support of both tools sufficiently mandatory in device and software implementations that the operator can configure the devices on his network as he sees fit for whichever legitimate combinations of the existing tools said operator desires.

> Making it "more mandatory" is, therefore, not the answer.

It is, actually. Making both it _AND_ DHCP more mandatory gives operators freedom of choice and ensures a compatible set of options across all devices.

> Further, the anti-DHCP people know this, which is why they keep trying to make SLAAC more robust, and more mandatory.

Again, you continue to approach me with this ridiculous us vs. them attitude that is the real problem. I’m not “them” in that I’m _NOT_ anti-DHCP.

I am PRO-SLAAC and PRO-RDNSS, but that doesn’t make me anti-DHCP.

I’m all for putting an option into DHCP6 to provide route information. In fact, I’d like to see it be a robust multi-instance option that can support a 16 octet prefix, 1 octet prefix_length and 16 octet next-hop specification.

I’m well aware that the “RA purists” out there vehemently oppose this, but I never have. I’ve always supported it. (Note, I refer to the RA purists because I don’t believe that all (or even most) of them are actually “anti-DHCP”).

I admit that there is an anit-DHCP crowd, but I think they are a relatively small minority at this point.

> This is laughably out of touch with reality. (You need only to look at the status quo to demonstrate that I'm right.)

The status quo is the result of poorly specified requirements which you are (apparently) defending. It doesn’t demonstrate that you are right, it demonstrates how wrong you are. Vendors won’t reliably implement what they are not required to implement by the RFCs unless they get strong requirements from their user base. The fact that RDNSS has received wider vendor acceptance than DHCP client support would, if anything, serve as evidence of just how out of touch with reality you are and bolster my position.

Owen

---

From: [email-masked]
Date: Mon, 03 Apr 2017 08:04:21 +0200 (CEST)

> Which vendors? Juniper supports RDNSS, Cisco supports RDNSS, RADVD supports RDNSS$,1s&(B
> 
> Which major router platforms are you thinking of that don$,1ry(Bt support RDNSS?

Huawei. No support, no plans last time we asked them.

Steinar Haug, AS2116

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 23:11:01 -0700

> On Apr 2, 2017, at 4:11 PM, Doug Barton <[email-masked]> wrote:
> 
> I've addressed this several times already. I will simply repeat my point that your perspective is obviously wrong because the market has not aligned itself to it.

Now I feel like I’m talking to Fox news. No matter how many times you repeat the same falsehood, it still remains false.

I’ve provided statistics showing that the market has, in fact, aligned with my position and not yours.

> No, more arguments about how to define "constrained host," "purpose built host," etc. are not only not going to help, they are going to make the problem worse (and make it that much more difficult to reach consensus).
> 
> Let RA+RDNSS continue to exist for those whose needs it meets. For those folks, they know that's all they need, so that's all they run. I am totally fine with that. (POWER TO THE PEOPLE!)

Except you don’t want to require vendors to implement it so that they can actually count on being able to deploy it. (FAIL!)

> But if you don't over-engineer the spec in the first place, you don't have to "grant exceptions." And if you do need to grant exceptions, your idea of "mandatory" is seriously flawed.

OK… Let’s get rid of DHCP altogether then so that we aren’t saddled with an over-engineered spec. SLAAC and RDNSS is mostly fine with me. Oh, wait, there are those places where we need PD. OK, let’s get rid of IA_NA and all the host configuration options from DHCP.

If we do that, then there are no needs for exceptions. Those people who want an over-engineered spec can do DHCP if they can convince their vendors. If the market has moved in that direction as you claim, then surely the lack of a standards-based requirement will not be an obstacle to implementation.

> Sorry, you're just flat-out wrong here. The fact that there is not "One True Solution" is offensive to certain mindsets, but it doesn't match the operational reality.

I don’t care who it is offensive to, the reality is that there isn’t “one true solution”.

Given that, failing to create requirements that a compatible subset exist across all implementations remains bad engineering.

> Thank you for giving me so much credit. :)  But the fact that there are so many "DHCP zealots" probably should give you the idea that we're on to something.

I’m not seeing so many. Perhaps I missed a head count somewhere. In this thread there seems to be 1.

> As I've pointed out several times now, if we are going to run DHCP anyway, then there is no reason for us to support RDNSS. Every dollar and person-hour spent on supporting that option is wasted. The IETF mandating it to satisfy a certain mindset that needs "One True Solution" is ludicrous on its face.

Sure, but lots of deployments ARE NOT GOING TO RUN DHCP anyway, so there is need for RDNSS there.

I’m not seeking “One True Solution”. If anything, you are in your arguments against RDNSS being mandatory. I’m arguing that both solutions MUST be supported in vendor implementations wherever feasible so that operators can make an informed decision about which subset they want to use on their networks.

Your argument boils down to “Since I want to run DHCP and I think most of the IT dollars are in my camp, I assert that implementing RDNSS is a waste of time and money.”

That’s great for you, but those same routers and servers that you are deploying in your environment also get deployed in other environments that don’t want to run DHCP and need RDNSS, so failing to require the vendor to implement RDNSS is just as useless to those installations as failing to require DHCP is to you.

> Further, as you so ably point out, "Mandate both" is never going to happen, there are always going to be exceptions, and that can only lead to more confusion, and more "angels on the heads of pins" debates about what is and isn't an exception. So not only do you not get what you're asking for, you make the problems (and arguments) worse instead of better.

I think that the exceptions could be sufficiently narrowly defined so as to limit confusion. Especially since there seems to be exactly one class of exclusions for each of the two requirements:

	RDNSS CLIENT is optional in a purpose built host whose application cannot be deployed without DHCP6.
	DHCP CLIENT is optional in a host with such limited resources (memory, battery life, etc.) that DHCP implementation would significantly
		reduce the hosts suitability for its intended purpose.

I don’t think those exceptions are open to a lot of interpretation or confusion and I don’t think vendors are generally so stupid that they would have trouble understanding the intent.

> I've already pointed out that your thinking on possible solutions is severely constrained by assuming that SLAAC must always exist.

I have no such assumption. Without SLAAC, you can’t do stateless DHCP, so it’s required in all those cases (you discarded my reference to IA_NA in an earlier message arguing in favor of stateless DHCP).

However, as I have repeatedly stated, if you want to turn off SLAAC, go for it. Set your RAs to M=1, O=1, A=0 and remove the prefix options and you’re good to go.

> I have offered a better solution here, and have have been offering it for over a decade:
> 
> Let SLAAC/RA (and I guess we'll thrown in RDNSS too) exist for those who want it, and for whom it meets their needs.

But this doesn’t reliably happen if we don’t mandate support for it in vendor implementations.

> Let DHCP hand out network and gateway information so that those who are going to run DHCP anyway can do so without SLAAC.

Now I’m confused… SLAAC doesn’t hand out gateway information and it can be turned off already.

Short of DHCP route options, this is already implemented and I’ve repeatedly stated my support for a DHCP route option.

> That is the simplest, lowest common denominator, best ENGINEERING solution. It eliminates the costs and complexities involved for those on the host side who only need one solution, and it will allow the market to gravitate in the direction that the money already wants to go.

But that’s simply not true because it is exactly how we have ended up where we are today… Some vendors choosing the SLAAC religion and some choosing DHCP and many implementing incompatible subsets of the protocol(s).

> The only reason NOT to follow that plan is to continue to cater to those who want to avoid DHCPv6 at all costs. But that's what got us into this mess in the first place.

As someone who needs to avoid DHCP6 in a number of deployments, I’m unwilling to accept that failing to cater to that need is valid.

So I’d say that’s a darn good reason NOT to follow that plan.

What got us into the mess is the zealots on BOTH sides. What we need is for people to step back and realize that continued zealotry is not helpful and we need to accept and properly support both protocols if anything useful is to come out of this.

Owen

---

From: [email-masked]
Date: Mon, 03 Apr 2017 08:27:32 +0200 (CEST)

> operators have spoken overwhelmingly in favor of DHCP.

There are also plenty of operators who have significant infrastructure
and support systems based on DHCP, and will continue to use this for
IPv6.

Also, some of these operators have legal requirements to log and keep
(for some time) the association between IP address and customer - a
requirement which doesn't go away with IPv6, and which for IPv4 is
easily provided by DHCP. With IPv6 and RA/SLAAC it means we need to
(additionally) start scraping the router IPv6 neighbor tables, instead
of having it all in one convenient place (the DHCP server). Absolutely
doable, but an added IPv6 pain which in my opinion should be completely
unnecessary.

Steinar Haug, AS2116

---

From: [email-masked]
Date: Mon, 03 Apr 2017 08:35:11 +0200 (CEST)

> to gravitate in the direction that the money already wants to go.

+1

(not optimistic it'll happen - but yes, that would be a great solution.)

Steinar Haug, AS2116

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 23:36:54 -0700

> On Apr 2, 2017, at 5:06 PM, Doug Barton <[email-masked]> wrote:
> 
> For what it's worth, mine is based on decades of experience configuring, and working with large enterprises to configure, DNS and DHCP solutions that meet real world needs.

Unfortunately, your experience seems to be limited only to that world and large enterprises alone do not represent all (or necessarily even a majority) of deployed hosts or networks.

They _MIGHT_ represent a majority of IT spend, but that’s hardly the same thing.

You completely ignore all of the SMB, service provider, R&E, and other types of installations where DHCP is utterly unnecessary and unwanted overhead.
> On this point I don't follow you at all. The market has "voted" overwhelmingly in favor of deploying DHCP, and not deploying RDNSS. My point was that requiring vendors to implement RDNSS does nothing to encourage operators to deploy it.

No, it has not. In fact, if anything, the market is close to evenly split between DHCP and RDNSS. Who cares whether operators are encouraged to deploy it or not… That’s not what we are after here. What we are after is requiring vendors to implement BOTH RDNSS and DHCP wherever feasible so that operators don’t have to be encouraged to deploy either one, they can choose the one(s) that works for their deployment(s).

> Where did I go wrong there? (That's a sincere question, if I missed something I want to know.)

I will attempt to answer, sincerely:

	1.	Drop the us vs. them mentality.
	2.	Recognize that there is a world beyond the large enterprise and it matters.
	3.	Recognize that we aren’t arguing for encouraging use of one protocol over the other, but, rather
		for mandating vendor implementation of both (to the largest extent feasible) so that
		operators can choose and deploy as they wish.

> I am sure that is your recollection of the situation, and I don't fault you for it. I was around when RDNSS was first suggested, and I remember the same conversations you do (including the dentist's office scenario).
> 
> However, I also remember that the very first proposed version of what became RDNSS had only the name server list. Those of us who were deeply involved on an operational level doing actual host configuration pointed out that the name server list is only one of several features that hosts on modern networks need to do name lookups, and that at minimum you would also need to include the search string feature, and that really if you have a host with sufficient complexity that it needs to do DNS lookups in order to get its job done the right answer is to use DHCP, which will be able to provide all of the appropriate configuration.
> 
> The response to that conversation was not, "Oh, I see ... thanks!" It was instead, "Ok, we'll add the search string!" on the one hand, followed by over a decade of denial that DHCP is the right answer here, along with further attempts to glue necessary configuration elements into SLAAC.

Perhaps people legitimately think DHCP isn’t the right answer here in their installations?

> So from your perspective adding RDNSS was a perfectly reasonable response to the realization that RA alone was not sufficient. From mine it was the result of the complete failure to recognize that RA alone only ever applied to a very limited set of hosts, and never should have been made mandatory to implement in the first place.
> 
> On the one hand there continues to be lack of enthusiasm for RA in the marketplace, along with ongoing clamor for robust DHCP. On the other hand, the response from the IETF has been continued insistence that RA remain mandatory.

Again, this expresses what I believe to be a severely limited and biased view of the marketplace tilted very heavily to one (admittedly sizable) subset of a much broader market to the exclusion of many other segments which are quite enthusiastically happy with RA+RDNSS. 

> You may take offense at my characterization of this situation being allowed to exist for the better part of 14 years, followed by the current recommendations to make RDNSS, or both RDNSS and DHCP mandatory to implement (the latter being something that even its proponents recognize isn't realistic) as "the inmates are running the asylum," but I frankly can't see any other way to describe it.

I could argue that the insistence on DHCP to the exclusion of RA would be a bigger example of the inmates running the asylum if it were allowed to pass, but fortunately, at least for now, that seems unlikely.

> Only in the sense of RDNSS.

True. We’ve specified at least 4 ways to assign host addresses:

IA_NA DHCP
Stateless DHCP using SLAAC
SLAAC
Static

Then, of course, there are the other (more bizarre) subsets if you count privacy addresses, etc.

> I don't think there is any confusion on that point in the operator community. The extraordinarily limited situations where RA+RDNSS are sufficient on their own are well understood by the people that are operating those types of hosts.

Referring to this as “extraordinarily limited” is disingenuous at best. In reality as soon as you step out side of the large enterprise environment, the vast majority of use cases can actually do quite well with RA+RDNSS.

> Everyone else wants DHCP.

Where everyone else is Large enterprises and a handful of other specialized cases.

> It's not the operators who are confused. :)

Oh, yes, yes it is in many many cases.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 2 Apr 2017 23:38:01 -0700

> On Apr 2, 2017, at 5:10 PM, Doug Barton <[email-masked]> wrote:
> 

Long overdue in my opinion, just as requiring vendors to implement support for both mechanisms is also long overdue IMHO.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Apr 2017 15:48:05 +0900

On Mon, Apr 3, 2017 at 3:27 PM, <[email-masked]> wrote:

> (additionally) start scraping the router IPv6 neighbor tables
>

That argument sounds plausible but it's actually not true. See RFC 7931
section 9.1, but briefly:

   - If you don't have strong L2 security, DHCP tracking cannot track
   malicious hosts.
   - If you do have strong L2 security, you don't need DHCP for tracking.

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Apr 2017 16:50:25 +1000

Hi,

On 1 April 2017 at 05:26, Fred Baker <[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."
>

Although the primary perspective was a combination of a DHCPv6 client
and server in a CPE verses a DHCPv6 relay, I think took that approach
when describing those issues in the section titled "Internet
Transparency and Application Configuration" in this draft

" IPv6 CE Device DHCPv6 Option Transparency"
https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00

I also discussed some of the consequences of lack of application
configuration option support in routers in the Introduction.

Some people might think this is an IS-IS vs OSPF type situation. I
think it is quite different. The decision to use IS-IS or OSPF is
internal to the network, and the choice isn't visible to external
parties.

I think this situation is different because we're talking about a
configuration interface between the network and the hosts, and it is
quite common that the operators of the network are different from the
operators of the hosts.

So this is an external interface between systems. If routing protocols
can be used an analogy, then we'd be in the same situation if some
router vendors only supported BGP, while other router vendors only
supported Inter-Domain Routing Protocol (ISO 10747, basically ISOs
version of BGP).

<snip>

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 3 Apr 2017 09:20:01 +0200 (CEST)

On Fri, 31 Mar 2017, Fred Baker wrote:

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

What I would like to see (this is not breakage though, only potential 
breakage and cause of confusion) is what a host should do if it gets RDNSS 
information and potentially DNS resolver information via DHCP. If a host 
doesn't implement a logic for this, there is potential breakage. I have 
already run into this when I dual stacked enterprise wifi Internet access 
and wired enterprise network was single stack IPv4, and windows chose the 
IPv6 resolver which was on the wrong side of "split horizon". Remedy there 
was no not provide any resolver in any IPv6 mechanism, so it's not really 
applicable to the RDNSS vs DHCPv6 resolver debate.

So if we decide to MTI a mechanism, do we at the same time want to 
recommend something on what to do with multiple resolvers, perhaps along 
the lines of RFC6731 ?

Personally I would like to MTI RDNSS and keep DHCPv6 optional, mostly 
because that would mean I didn't have to configure DHCPv6 for basic 
Internet IPv6 access.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Apr 2017 17:26:08 +1000

<snip>
> going to run DHCP anyway can do so without SLAAC.

"IPv6 RAs Mostly Necessary"
http://www.users.on.net/~markachy/IPv6_RAs_Mostly_Necessary.pdf

> That is the simplest, lowest common denominator, best ENGINEERING solution.
> It eliminates the costs and complexities involved for those on the host side
> who only need one solution,

No, it doesn't eliminate costs and complexities. It increases them.

This whole discussion is caused by having two protocols that perform
the same function. You would be to creating the same situation with
DHCPv6 by duplicating RA functionality in it.

Think about the better conversations we could be having about unsolved
problems rather than having to sort out the problem of having two
solutions to one problem when each of them don't have a clear
advantage over the other.

> and it will allow the market to gravitate in the
> direction that the money already wants to go.
>
> The only reason NOT to follow that plan is to continue to cater to those who
> want to avoid DHCPv6 at all costs. But that's what got us into this mess in
> the first place.
>

No, what got us in this mess in the first place is not following what
is in RFC1958,

" 3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements."

RDNSS isn't a significant improvement over stateless DHCPv6, which is
why host and router vendors are unsure about which one to implement,
and operators are unsure about which one to deploy when they have a
choice.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 3 Apr 2017 09:58:59 +0200 (CEST)

> doable, but an added IPv6 pain which in my opinion should be completely 

There are other ways to skin that cat, but you already know that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Apr 2017 18:49:36 +0900

On Mon, Apr 3, 2017 at 4:20 PM, Mikael Abrahamsson <[email-masked]> wrote:

> information and potentially DNS resolver information via DHCP.

Per RFC 8106, it prefers DHCP. (Assuming it supports DHCP, which it is not
required to do.)

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 3 Apr 2017 14:43:44 +0200

Le 31/03/2017 à 20:26, Fred Baker a écrit :
[...]
> 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.

Not quite a breaking statement, and more implementation aspects:
- the main OS distribution on Raspberry Pi does not implement DNS in RA
   (other such distrib does, but it's rather marginally deployed).
- I understand Windows PCs and routers at IETF dont implement DNS in
   RA, but rather DNS in DHCP.

A speculative breaking statement would be: resolver address delivered by 
RA overwrites the one delivered by DHCP, despite M==1  (or vice-versa). 
But never tried it :-)

Alex

>
> YMMV, and probably does.
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: [email-masked]
Date: Mon, 03 Apr 2017 15:26:45 +0200 (CEST)

>    - If you do have strong L2 security, you don't need DHCP for tracking.

The L2 security is strong enough for $REGULATORY_AUTHORITY.

I didn't find a section 9.1 in RFC 7931 "NFSv4.0 Migration:
Specification Update", so I assume you meant a different RFC.

Steinar Haug, AS2116

---

From: Doug Barton <[email-masked]>
Date: Mon, 3 Apr 2017 06:33:16 -0700

On 04/02/2017 11:38 PM, Owen DeLong wrote:
> Long overdue in my opinion,

Glad to see we agree on something. :)

Meanwhile, I'm taking a break from replying to you. Your latest replies 
continue to be in contradiction to things I didn't say, and/or am not 
proposing, making the conversation rather exhausting.

Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Apr 2017 01:39:49 +1200

Lorenzo,
> opposition from host OS developers than there was last time.

I take a rather simplistic view of this. If the IETF defines two complete
solutions, the "market will decide" applies. The particular combination
of MUSTs and SHOULDs that we write down won't really matter; they could
all just as well be MAYs. I might have my preferences, but all I really
care about is that everybody gets connectivity.

At the moment the IETF has defined two incomplete solutions, and as this
thread shows, that makes it essentially impossible to define a combination
of MUSTs and SHOULDs that make sense.

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 03 Apr 2017 14:52:52 +0100

> of MUSTs and SHOULDs that make sense.

which is the critical point: all attempts to augment the DHCPv6 protocol
to make it feature complete are actively blocked because of what are for
the most part, religious / political arguments.

It would be helpful if those people who were consistently throwing
hurdles in the path of e.g. dhcpv6 route option and one or two other
feature gaps would kindly desist from doing so, particularly noting that
they do not in general use the dhcpv6 protocol themselves.

Nick

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Apr 2017 23:56:59 +1000

> Specification Update", so I assume you meant a different RFC.

What he is is saying is that neither DHCPv4 or DHCPv6 were designed to
accurately audit IP address use on a link. If they were, they'd also
somehow record static addresses in use and for DHCPv6, link-local
addresses use. They don't and can't.

This needs to be called out as often as possible, because people
assume the security mechanism that relies on this false assumption is
effective at its purpose, when it actually it isn't. This group
shouldn't accept this as a reason for using stateful DHCPv6 for
addressing.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Apr 2017 22:57:46 +0900

> The L2 security is strong enough for $REGULATORY_AUTHORITY.

Then we should explain to $REGULATORY_AUTHORITY that what they are asking
for is insecure and they should follow the best current practices in RFC
7934.

I didn't find a section 9.1 in RFC 7931

https://tools.ietf.org/html/rfc7934#section-9.1

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Apr 2017 02:05:38 +1200

On 03/04/2017 19:26, Mark Smith wrote:
...
> and operators are unsure about which one to deploy when they have a

Being the editor of RFC1958, I'll make a final comment (then try to shut
up on this thread): We were in a bind in this case. SLAAC was aimed
at the dentist's office scenario. DHCPv6 was not part of the initial IPv6
design - it was a retro-fit for enterprise scenarios, when DHCP(v4) became
a success. And IMHO we screwed up by not clearly separating the scenarios
and not thinking jointly about the points where the functional requirements
overlapped.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 3 Apr 2017 14:44:50 +0000

On 1 Apr 2017, at 15:04, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

No, there is not, but there should be a draft on this capability soon; it was left out of the netmod core work on router config as that focused purely on 4862 features.

(Now half way through the 117 emails on this thread :)

Tim

---

From: "Jeffry Handal (jehandal)" <[email-masked]>
Date: Mon, 3 Apr 2017 14:46:09 +0000

From: v6ops <[email-masked]> on behalf of Lorenzo Colitti <[email-masked]>
Date: Monday, April 3, 2017 at 1:48 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [v6ops] Making RDNSS a MUST?

On Mon, Apr 3, 2017 at 3:27 PM, <[email-masked]<mailto:[email-masked]>> wrote:

That argument sounds plausible but it's actually not true. See RFC 7931 section 9.1, but briefly:

  *   If you don't have strong L2 security, DHCP tracking cannot track malicious hosts.
  *   If you do have strong L2 security, you don't need DHCP for tracking.
************************
When I was on the operations side, we solved this with 802.1x and radius accounting. This provided us with the identity and ipv4/ipv6 address of that user. Therefore, having good security and proper logging helps you solve the tracking issue without DHCPv6.
Old sample output from a radius log:
Tue Oct 21 09:35:56 2014 username=[email-masked]<mailto:[email-masked]> Acct-Session-Id=54466e8f/78:7e:61:50:98:a5/10438500 Framed-IP-Address=173.xxx.168.163 Framed-IPv6-Address=2xxx:105:b00b:4810:8548:e6a3:da0a:1d79 Framed-IPv6-Address=2xxx:105:b00b:4810:82c:18e2:bd5b:f1fa Framed-IPv6-Address=2xxx:105:b00b:4810:181f:e66e:1cb1:ee3b
Regards,
--
Jeffry Handal
(832) 602-4211

---

From: Mark Smith <[email-masked]>
Date: Tue, 4 Apr 2017 01:11:09 +1000

> the most part, religious / political arguments.

I think they'e being characterised as religious/political because
people don't want to accept they're practical.

People who think DHCPv6 should be extended with RA features aren't
recognising that this specific RA/DHCP DNS issue and the related
discussion, which is about the exact same type of scenario - two
different ways to solve one problem where there is no clear advantage
for either of them - is an example of would also be repeated in much
greater depth by adding RA features into DHCPv6.

Even more human effort would be being spent on problems that have
already been solved adequately enough and that work instead of being
spent on new problems that haven't been solved.

> they do not in general use the dhcpv6 protocol themselves.

There needs to be a compelling reason why it is worth doing so, which
would need to include showing scenarios where RAs aren't or cannot be
made adequate.

A reason of "it's different to how IPv4 worked" is a subjective
("religious/political"), not objective.

A replacement method or an alternative method has a higher bar to
reach to be acceptable and succeed, because there is already a method
that is demonstrated to work, and in this case, one that has been
deployed to literally billions of devices and has worked successfully
for at least 18 years (that's when I first ran up radvd if I recall
correctly). This is really what people are saying when they say "where
were you in 1995 (or earlier)" - in 1995 the costs of changing this
would have been far, far cheaper than they are today because there was
no installed base.

I accept that RAs are the way to convey default router and other link
specific layer 3 configuration information because that's how it was
done when I learned IPv6. If DHCPv6 had instead been used, I'd have
accepted that method.

To me, it is more important to have a single solution to a single
problem that works well enough, regardless of the actual method. It's
simpler, and that means less things to choose between, less things
that can conflict with each other and less things that can break. That
lowers opex and increases availability - entirely practical benefits
of having a single solution.

Regards,
Mark.

---

From: Michael H Lambert <[email-masked]>
Date: Mon, 3 Apr 2017 11:43:21 -0400

> On 2 Apr 2017, at 12:22, Owen DeLong <[email-masked]> wrote:
> 

I'm just considering this last line without prejudice for or against the merits of RA/SLAAC, DHCPv6, etc.  I would argue for MAY, not SHOULD.  In our environment, we operate DHCPv4 servers as separate middle boxes.  If and when we deploy DHCPv6, I would expect to do the same.  Any requirements or strong suggestions that DHCPv6 servers be deployed in a network should be from the perspective that nodes on a given network segment have reachability to DHCPv6 services, not that routers on the network segment provide those services.

Michael

---

From: Philip Homburg <[email-masked]>
Date: Mon, 03 Apr 2017 17:57:26 +0200

>("religious/political"), not objective.

There are currently deployed networks that have to change a lot more to 
support RAs then they would have if there would be a DHCPv6 default router
option.

That's not subjective, that's an additional cost.

There are also the vendors that do not support IA_NA. Forcing a change to
SLAAC. That's even more expensive. 

Obviously, adding support for two ways of doing things also has cost. 

Somehow it seems that RA is the new religion. Adding something to RAs is
way easier than adding an option to DHCP. 

DHCP was already completely standard in 2003 when RDNSS was first described.
It seems the aversion against DHCPv6 was so great that in 2007 people were
willing to except it as experimental. 

You would say that in 2010, most implementations would already support the
one standard of getting DNS resolvers for IPv6, i.e. using DHCP, so
RFC 6106 would just be duplicate effort.

Yet somehow, the argument of duplicate functionality only comes up when people
ask for support for DHCP.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 3 Apr 2017 18:48:28 +0200 (CEST)

On Mon, 3 Apr 2017, Philip Homburg wrote:

> Yet somehow, the argument of duplicate functionality only comes up when 
> people ask for support for DHCP.

Whenever I ask to extend ND or put new things into RA, I get lots of 
pushback. A lot more pushback than when I want a new DHCP option for 
something that relates to information for the device.

The only major pushback that I have seen to put into DHCPv6 is the default 
router option for DHCPv6, because if we allow that then I would say that 
there are lots of other options in RA not currently available in DHCPv6 
that I would basically say should be MTI. These are for instance MTU, PIOs 
with lifetimes etc.

I think saying everything should be configurable using DHCP is 
short-sighted and removes a lot of the new functionality that IPv6 
actually supports in current incarnation, that IPv4 currently doesn't.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 03 Apr 2017 19:08:05 +0200

>something that relates to information for the device.

The text you quoted says 'duplicate functionality'.

It is way easier to add new option to DHCP than in RA or ND. The reason is
in DHCP if the client doesn't ask for the option, you just don't send it.

Historically, RAs (and to some extend ND) are based on multicast where you
don't have that kind of negotiation.

>that I would basically say should be MTI. These are for instance MTU, PIOs 

I'm missing the point why that would be a big deal. Just about every
system already has interfaces for static configuration of MTU and
routes. So it would only be a tiny amount of code to support an MTU or
an onlink prefix option.

More worrying is that you are willing to delay deployment of IPv6 in
enterprises because of fear that two new options would have to be added to
DHCP.

>actually supports in current incarnation, that IPv4 currently doesn't.

A lot of that functionality is perfectly useless in many environments.
(Note I'm not saying that we should kill RAs. Though I get the impression
that they are hugely overvalued).

But for some reason, not supporting functionality only provided by DHCP
is perfectly alright. Weird.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Apr 2017 10:21:35 -0700

My reaction to this long and very predictable high-bandwidth back-and-forth is that I suspect the outcome will be the same as it was last time: no action.

This is frustrating.   It seems clear to me that requiring support for RDNSS would improve the situation.   Possibly requiring support for DHCPv6 would also improve the situation if it were done correctly (which is not a given).   But whenever anybody proposes requiring RDNSS, we get this demand for parity, and then a giant explosion of opinions, and then no action.

Essentially what I see here is a viable solution being held hostage to demands for a controversial solution.   It may be that the controversy isn't valid, and that really requiring DHCPv6 is the right thing to do.   But the controversy exists, and makes requiring DHCPv6 problematic.

I don't see any justification for a technical objection to RDNSS.   So my personal opinion is that despite the loud protests to the contrary, there is consensus to require RDNSS.   It may also be the case that there is consensus to require DHCPv6, on the same basis.   However, that would require a document that describes what "require DHCPv6" actually means.

It is of course entirely possible that the document authors are just plotzing at this discussion, or perhaps have chosen to ignore it, since the document isn't explicitly mentioned anywhere in the thread.   It would be valid for them to say that this is simply not an opportunity to re-open this issue.   However, the section in the document on Zero Touch Configuration certainly looks like a good place to insert a requirement.

My personal preference would be that if there is any serious desire for DHCPv6 to be required, that the proponents of this requirement write up in a document what that support looks like.   I don't think it makes sense to do that in this document.   I think it does make sense to require RDNSS in this document, because I don't think there's any question as to what that looks like.

I realize that holding that hostage probably looks like a great way for proponents of DHCPv6 support to get their way, but I don't think that's what would happen: what would happen would be that the authors of the document would say nothing at all on this topic.   So that's your choice: improve the situation, but don't get everything you want, or get nothing.   For those who do not want RDNSS, of course, the scorched earth approach will be fine, but for the rest of us I think it's not fine.

---

From: Chuck Anderson <[email-masked]>
Date: Mon, 3 Apr 2017 13:51:50 -0400

> shouldn't accept this as a reason for using stateful DHCPv6 for

DHCP enables the security functionality in L2 switches that have DHCP
Snooping, ARP Inspection and IP Source Guard features.  This makes it
possible to require that endpoints complete a DHCP transaction, and
they are only allowed to send packets with a source address that
matches a DHCP lease for that specific client while the DHCP lease is
still valid and unexpired.

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 Apr 2017 11:07:20 -0700

> My reaction to this long and very predictable high-bandwidth back-and-forth is that I suspect the outcome will be the same as it was last time: no action.

I'm not sure I disagree. From my perspective, the best action would be to select one methodology - use the RA or use DHCP in some form, but not both.

What I don't see in this is an emerging consensus. I see two sets of people, one with a consensus around the RA and the other with a consensus around DHCP, and I don't see them convincing each other. Absent consensus, I don't think we have a basis for action, and are likely to therefore not act. In a different email, I commented on there being, apparently, two sets of users or operators - those who favor the RA, and those who favor DHCP. This discussion may come down to their respective information security policies and their financial and operational impacts. At the moment, I would hazard a guess that in residential and small corporate networks the RA sounds like not needing a separate DHCP server, and therefore not managing or investing in one, and in larger enterprise networks and perhaps SP networks, information security policies mandate DHCP regardless of your and my technical viewpoints.

I'd be happy to be proven wrong, especially if the argument results in a consensus on this particular point.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 03 Apr 2017 20:27:54 +0200

In your letter dated Mon, 3 Apr 2017 11:07:20 -0700 you wrote:
>What I don't see in this is an emerging consensus. I see two sets of people, o
>ne with a consensus around the RA and the other with a consensus around DHCP, 
>and I don't see them convincing each other.

It seems to me that there is quite a bit of support for making both
MTI both in routers and in hosts.

There are some parties that will do everything possible to never ever
have to support DHCP. So actual consensus is not going to happen.

There are also parties that only want to use DHCP and don't see a need for
RDNSS. Though it is not clear to me of they would block a proposal that 
requires support for both protocols in routers and hosts.

>email, I commented on there being, apparently, two sets of users or operators 
>- those who favor the RA, and those who favor DHCP. This discussion may come d
>own to their respective information security policies and their financial and 
>operational impacts. At the moment, I would hazard a guess that in residential
> and small corporate networks the RA sounds like not needing a separate DHCP s
>erver, and therefore not managing or investing in one, and in larger enterpris
>e networks and perhaps SP networks, information security policies mandate DHCP
> regardless of your and my technical viewpoints.

As long as we are disscussing what hosts and routers should support, then
requiring support for both protocols should make all operators happy.

---

From: Fred Baker <[email-masked]>
Date: Mon, 3 Apr 2017 11:38:50 -0700

> On Apr 3, 2017, at 11:27 AM, Philip Homburg <[email-masked]> wrote:
> 

Perhaps. I'm certainly willing to see that in the document. That said, I also see a lot of commentary about picking the writer's favorite.

> have to support DHCP. So actual consensus is not going to happen.

Pretty much. I don't see a way forward other than making both Mandatory-to-Implement; each side wins their half.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 3 Apr 2017 11:53:09 -0700

On 4/3/17 11:07, Fred Baker wrote:
> What I don't see in this is an emerging consensus. I see two sets of people, one with a consensus around the RA and the other with a consensus around DHCP, and I don't see them convincing each other.
As the implmentor of an end system device one may have a different
vantage point then that of a network operator or the the designer of
routers. ultimately I think the demand to be able to signal information
in an RA vs stateful DHCP reflects differing priorities for network
mobility. the fact taht router advertisement as a function doesn't not
exist in ipv4 necessarily constrains mobility in certain ways (e.g.
network operators have to account for information provided with a lease
(life the default GW) being stable for the lifetime of the lease)
whereas with the RA and slack generally much shorter lifetimes are feasible.
>  Absent consensus, I don't think we have a basis for action, and are likely to therefore not act.
Imho I personally see them both as feasisble from a network equipment
standpoint. I can see cases where a network operator might support only
one or the other, and in cases where there's a high degree of vertical
integration that seems easy enough, if you don't control what equipment
is on your network however you may have limited choice afterall there
are legacy operating systems that either need to be configured manually
or use well-know addresses, I don't personally have any of those
machines anymore, but I also don't run an airport or a railroad.
>  In a different email, I commented on there being, apparently, two sets of users or operators - those who favor the RA, and those who favor DHCP. This discussion may come down to their respective information security policies and their financial and operational impacts. At the moment, I would hazard a guess that in residential and small corporate networks the RA sounds like not needing a separate DHCP server, and therefore not managing or investing in one, and in larger enterprise networks and perhaps SP networks, information security policies mandate DHCP regardless of your and my technical viewpoints.
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Apr 2017 05:09:06 +1000

In message <[email-masked]>, Fred Baker writes:
> > My reaction to this long and very predictable high-bandwidth
> > back-and-forth is that I suspect the outcome will be the same
> > as it was last time: noaction.
>
> I'm not sure I disagree. From my perspective, the best action would be to
> select one methodology - use the RA or use DHCP in some form, but not both.
>
> What I don't see in this is an emerging consensus. I see two sets of
> people, one with a consensus around the RA and the other with a
> consensus around DHCP, and I don't see them convincing each other.
> Absent consensus, I don't think we have a basis for action, and are
> likely to therefore not act. In a different email, I commented on there
> being, apparently, two sets of users or operators - those who favor
> the RA, and those who favor DHCP. This discussion may come down to
> their respective information security policies and their financial
> and operational impacts. At the moment, I would hazard a guess that in
> residential and small corporate networks the RA sounds like not
> needing a separate DHCP server, and therefore not managing or investing
> in one, and in larger enterprise networks and perhaps SP networks,
> information security policies mandate DHCP regardless of your and
> my technical viewpoints.
>

What I see is that there are two sets of operators with different
requirements.  In almost all devices it isn't that hard to implement
*both* RA and DHCPv6 (stateful and stateless).  Why are we trying
to choose one.  Just implement all in both routers and hosts.

I want my laptop to work when it is connected to the home network
using SLAAC and to networks that use DHCPv6.

I also want routers I buy to be able to work in whatever mode I
want to configure the network.  I want to be able to configure a
SLAAC network.  I want to be able to configure a DHCPv6 base network.

For some networks I want the DHCP server to be in the router for
others I want it to be centralised and only a DHCP relay is present
or just to be able to tell the nodes that there is a DHCP server
on the network.

For some networks I want DHCP server to act as DHCP client to get
resources.

There is no one correct way to run a network.  We should acknowlege
that and build systems that handle and many of these requirements
as possible.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Mon, 03 Apr 2017 21:20:48 +0200

>the fact taht router advertisement as a function doesn't not

Router advertisements for IPv4 are specified in RFC 1256, published in
1991.

They were popular for a brief period of time, but lost traction when 
DHCP got popular.

---

From: james woodyatt <[email-masked]>
Date: Mon, 3 Apr 2017 12:28:08 -0700

> Pretty much. I don't see a way forward other than making both Mandatory-to-Implement; each side wins their half.

That would entail telling every developer of Internet-enabled home appliances that expect their products to be deployed mostly (if not entirely) behind RFC 7084-compliant routers that their designs will fail IPv6 Node Requirements compliance testing unless they include a DHCPv6 client.

If IETF were to publish such a requirement, then I would strongly recommend to my product managers that this requirement can be safely ignored (and should be ignored) until RFC 7084 is revised to include some kind of administrative interface for configuring the DHCPv6 service to provide specific configuration to individual home appliances based on some kind of standard secure identity. (And I’m not going to hold my breath waiting for all of that to happen.)

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 3 Apr 2017 21:36:38 +0200

Hi,

> that and build systems that handle and many of these requirements

This!

Gert Doering
        -- Operator

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Apr 2017 12:47:51 -0700

Hm, what I mean by consensus is that there's a clear benefit to doing X, a lot of people agree that X should be done, and nobody has any technical objection to doing X.   You can definitely say this for RDNSS.   You may be able to say this for DHCP; my technical objection is pretty easily addressed, I think.

So yes, you can take the position that since you don't have people agreeing violently, you don't have consensus, but I don't think that's a constructive approach.   This is a real problem.   There is clearly consensus that it is a problem.   Both solutions to the problem are valid, and there are clear consensuses for both solutions.   One of the solutions can be done now; the other needs more work.

So I would really like to see us do the work, rather than not doing it because not everybody agrees.

> On Apr 3, 2017, at 11:07 AM, Fred Baker <[email-masked]> wrote:
> 
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 3 Apr 2017 21:48:23 +0200 (CEST)

On Mon, 3 Apr 2017, Chuck Anderson wrote:

> possible to require that endpoints complete a DHCP transaction, and they 
> are only allowed to send packets with a source address that matches a 
> DHCP lease for that specific client while the DHCP lease is still valid 
> and unexpired.

All of this is true. What is also true is that there are documents doing 
the same for SLAAC A=1 deployments as well.

https://tools.ietf.org/wg/savi/

Do note that the FCFS document predates the DHCP one by 3 years. Also note 
that there are multiple different ways to skin this cat, most of which not 
requires the use of DHCPv6.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 3 Apr 2017 20:07:52 +0000

> It seems to me that there is quite a bit of support for making both MTI both
> in routers and in hosts.

Personally, I am dead-set against stateful and heavily opposed to stateless DHCPv6 client on hosts.
The technical reasons have been stated by others: DHCPv6 client adds complexity and demands memory, CPU, and power. Stateful more so than stateless.

The original proposal was stateless as a requirement. Discussions around enterprises wanting to use DHCPv6 for address assignment are an irrelevant distraction in this context. This would be a justification for hosts *that are designed to be used in such enterprise networks* to implement stateful and not just stateless. It is inappropriate for such enterprises to attempt to use IETF as some sort of bludgeon on mass market device manufacturers to try to force them to add cost and complexity to their devices to make them suitable for such an enterprise environment. Enterprises who want/need to do DHCPv6 address assignment will simply have to live with the fact that there will exist devices targeted at the mass market (home and small business) that will not be able to attach to their networks. That is what it is. Host device manufacturers that see a market driver to add DHCPv6 client complexity will do so. And those that don't won't.

The only justification given so far for not mandating enterprise routers implement RDNSS is "some of the enterprise router vendors haven't implemented it, yet". That is the lamest excuse I have ever seen. It's *not* a technical justification. There exists no technical justification for why an enterprise router cannot implement RDNSS. Enterprise routers must do RA for route advertisement. It's totally required. Adding RDNSS to the already-being-sent RA is simple, and the additional cost/complexity is negligible as a percentage of the overall system. If CE routers can all do it (which they do), enterprise routers can definitely do it.

I've seen no technical justification for why an enterprise that is willing to allow attachment by devices without stateful DHCPv6 clients is incapable of enabling RDNSS (if implemented in their enterprise router). 

Summary:
There is no technical justification for any router not to implement RDNSS.
There is no technical justification for an enterprise that does not restrict address assignment to DHCPv6, not to enable RDNSS. 
It sounds like all enterprise routers are implementing DHCPv6 stateful server. All IPv6-capable CE routers are implementing RDNSS and either stateless or stateful DHCPv6 server (per RFC 7084). Good. Let them keep doing what they're doing wrt DHCPv6 server.
There *is* technical justification for some hosts not to implement a DHCPv6 client (stateless or stateful).
Forcing costly and complex enterprise requirements onto mass market consumer devices is unconscionable.
There is no significant technical justification for hosts not to implement RDNSS. It will not break interoperability with the embedded base if the current RFC 6434 SHOULD is changed to must for RDNSS. So if people want to mandate host RDNSS implementation, I have no objection to that. Then again, if nothing is done to mandate new host behavior, I have no objection to that either. 
The only broken (causing interoperability issues) elements I've read about in this thread are the enterprise routers. To me, it was pretty obvious from reading RFC 6434 (back in 2011) that routers had to implement RDNSS and DHCPv6 server (stateful or stateless) to support all RFC 6434 nodes. Enterprise router manufacturers and enterprises have had a few years to figure this out.

Barbara

---

From: james woodyatt <[email-masked]>
Date: Mon, 3 Apr 2017 13:53:25 -0700

Hi everyone,

In case I didn't make myself clear (and private email from one correspondent suggests I did not), when I said below that I would recommend to product managers responsible for certain kinds of IPv6-capable hosts intended for deployment in home networks that they ignore any forthcoming requirement to implement a DHCPv6 client, I did not mean to allow that to be interpreted as a promise to recommend ignoring it for every product in every category intended for every use case on the global Internet forever and always.

I hope my comments are received as a statement of my opinion about specifically what technical recommendations I would make for products that are targeted principally for deployment behind RFC-7048 routers, i.e. those for home network deployment by retail customers, where no special additional support is provided for alternative deployment on managed enterprise networks.

—sent from my phone

> On Apr 3, 2017, at 12:28, james woodyatt <[email-masked]> wrote:
> 
> --james woodyatt <[email-masked]>
> 
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Apr 2017 07:06:11 +1000

In message <[email-masked]>, james woodyatt writes:
> Hi everyone,
>
> In case I didn't make myself clear (and private email from one
> correspondent suggests I did not), when I said below that I would
> recommend to product managers responsible for certain kinds of
> IPv6-capable hosts intended for deployment in home networks that they
> ignore any forthcoming requirement to implement a DHCPv6 client, I did
> not mean to allow that to be interpreted as a promise to recommend
> ignoring it for every product in every category intended for every use
> case on the global Internet forever and always.

Stuff "designed for homes" gets put on corprate nets all the time.  It
should just work there.  There is very little, if anything, that doesn't
get connected to both types of nets.

> I hope my comments are received as a statement of my opinion about
> specifically what technical recommendations I would make for products
> that are targeted principally for deployment behind RFC-7048 routers,
> i.e. those for home network deployment by retail customers, where no
> special additional support is provided for alternative deployment on
> managed enterprise networks.
>
> —sent from my phone
>
> >> Pretty much. I don't see a way forward other than making both
> Mandatory-to-Implement; each side wins their half.
> >
> >
> > That would entail telling every developer of Internet-enabled home
> appliances that expect their products to be deployed mostly (if not
> entirely) behind RFC 7084-compliant routers that their designs will fail
> IPv6 Node Requirements compliance testing unless they include a DHCPv6
> client.
> >
> > If IETF were to publish such a requirement, then I would strongly
> recommend to my product managers that this requirement can be safely
> ignored (and should be ignored) until RFC 7084 is revised to include some
> kind of administrative interface for configuring the DHCPv6 service to
> provide specific configuration to individual home appliances based on
> some kind of standard secure identity. (And I’m not going to hold my
> breath waiting for all of that to happen.)
> >

---

From: "Russ White" <[email-masked]>
Date: Mon, 3 Apr 2017 14:22:44 -0700

> Perhaps. I'm certainly willing to see that in the document. That said, I also see
> a lot of commentary about picking the writer's favorite.

I'm perfectly fine with this -- if I can get a list of the docs to ref, I'll add it to the next revision.

😊

Russ

---

From: james woodyatt <[email-masked]>
Date: Mon, 3 Apr 2017 14:30:20 -0700

> get connected to both types of nets.

As I wrote in private to my correspondent off list, "compute resources for things that add absolutely no customer value to the design significantly increase recurring manufacture costs. I’m not going to fight with senior vice presidents for DHCPv6 clients in home appliances until I can explain to them in one slide and a 90 second demo what actual customer value the costs will buy.”

What I went on further to say is that it’s a completely different story when recommending how to other product teams might go about design similar or related products for more general deployment, for example where customers may need support for enterprise managed networks where DHCPv6 is mandatory and RDNSS is not recommended by the operator community. For what it’s worth, I would recommend RDNSS clients in those hosts on technical grounds, and I would recommend making the decision about whether to implement a DHCPv6 client based entirely on prevailing business considerations. I would explain that DHCPv6 is a matter of network operator taste, tastes vary, and they should decide accordingly. (It’s my understanding that decision has already been made, rather publicly, in some cases of specific network deployment scenarios, with both YES and NO outcomes, using business considerations I don’t think I understand very well, and I’m happy to stay out of that contest.)

---

From: Philip Homburg <[email-masked]>
Date: Tue, 04 Apr 2017 00:18:45 +0200

>The technical reasons have been stated by others: DHCPv6 client adds complexit
>y and demands memory, CPU, and power. Stateful more so than stateless.

I'm amazed at how horrible some IPv6 implementations must be.

Even the tiniest devices can do stateful DHCPv4. But some how, writing
compact code is a lost skill, so for IPv6, we cannot do this.

Really? Everybody can include a DHCPv4 client, but a DHCPv6 client is a 
bridge too far. And that is a 'technical reason'?

Of course ignoring that in the case of IPv6, it is actually the operator
who decides if the additional memory, CPU and power are actually needed.
When the 'M' and the 'O' bits are clear, you don't waste any of those
resources. Yes, you always need a slightly bigger flash chip. Big deal.

And, if a device is really constrained, there seems to be no opposition to
the idea that if DHCPv6 really doesn't fit, you leave it out.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Apr 2017 15:33:09 -0700

> On Apr 3, 2017, at 3:18 PM, Philip Homburg <[email-masked]> wrote:
> 

There are actually many tiny devices I’m aware of that can’t do stateful DHCPv4.
Beyond that, DHCP6 has a lot more overhead than DHCPv4.

> bridge too far. And that is a 'technical reason’?

Really. Take a long hard look at the differences in what it takes to implement a client
for DHCP4 (a minimal one) vs. a minimal conforming DHCP6 client. There’s a whole
lot more going on in the DHCP6 client.

> the idea that if DHCPv6 really doesn't fit, you leave it out.

But the opposition to mandating router vendors to implement RDNSS is still a problem
for these devices.

Owen

---

From: Mark Smith <[email-masked]>
Date: Tue, 4 Apr 2017 08:58:07 +1000

> I realize that holding that hostage probably looks like a great way for proponents of DHCPv6 support to get their way, but I don't think that's what would happen: what would happen would be that th…

The above all makes sense to me.

I don't like that RDNSS exists, because it has caused all this
trouble, discussion and interoperability problems. Just sticking to
using stateless DHCPv6 for this purpose would have made much more
sense to me.

I've always had the view that hosts need more than layer 3
configuration information conveyed by RAs (prior to RDNSS optoins),
and also need more than DNS information - most if not all devices have
or maintain real time clocks in them that need or should be set
accurately, and probably are informed of their timezone (having just
switched from daylight savings time over the weekend, I still have
about four more clocks to manually change ...). So I've assumed that
stateless DHCPv6 (not stateful, address assigning, DHCPv6) was a
necessity rather than an option, to do more than configure DNS
information.

However, now that RDNSS exists and is causing interoperability
problems, I see value in hosts implementing both stateless (to be
clear, not stateful) DHCPv6 and RDNSS to be able to adapt to what ever
method the network they attach to is using to convey DNS information.
The majority of hosts are mobile so it makes sense to me that they
adapt to the current network they're attaching to, rather than the
other way around.

This is a compromise I'm willing to make to my views to make the
current situation better. What I don't want to see is that then being
used to justify importing DHCPv6 options into RAs and RA options into
DHCPv6, as though there is and will be no problems and no additional
costs in doing so. This discussion is a real and live demonstration of
those sorts of problems and costs.

I think having two similar methods for configuring DNS has been a
mistake. We should call it out as such, work around it in the interest
of operability, and then say and make sure we're not going to make
that sort of mistake again (I think it has been already made twice -
SLAAC vs stateful DHCP for address configuration, a view that seems to
be commonly based on the flawed premise that DHCP provides an accurate
record of MAC addresses and corresponding address use).

I also think it is necessary to state whether stateless or stateful
DHCP is being described or referred to. If I don't see any qualifier,
I assume stateful, which I also think others do too, and that then
creates a loaded discussion that implies that IPv6 addressing will
also be handled by (stateful) DHCPv6. The conversation can then
devolve into one that is also discussing the use of SLAAC vs stateful
DHCPv6 for addressing too.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 04 Apr 2017 01:02:50 +0200

> Really. Take a long hard look at the differences in what it takes
> to implement a client for DHCP4 (a minimal one) vs. a minimal
> conforming DHCP6 client. Theres a whole lot more going on in the
> DHCP6 client.

I must have done something wrong then. The structure of my simple DHCPv6
client is roughly similar to what I expect from a DHCPv4 client. I 
have to admit, I never had to write a DHCPv4 client, so I may have missed
something.

In any case, a my standalone DHCPv6 client is about one quarter the
code I need for ND. And we keep adding complexity to ND.

> But the opposition to mandating router vendors to implement RDNSS
> is still a problem for these devices.

As far as I can tell, apart from the people who are never going to support
DHCPv6, there is quite a bit of support for making both RDNSS and DHCPv6 DNS
MTI. So tiny devices should be covered.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Apr 2017 16:05:40 -0700

> get connected to both types of nets.

Stuff might protect the end user's privacy by not doing certain protocols.   It might refuse to work if the network refuses to allow the end user their privacy.   This would seem to be correct behavior.   Correct behavior is sometimes "fail."   E.g., you do not want a TLS connection to succeed if the server cert doesn't validate.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Apr 2017 16:10:05 -0700

> On Apr 3, 2017, at 11:53 AM, joel jaeggli <[email-masked]> wrote:
> 

More importantly, RA provides a mechanism to shorten the timer after the “lease” has been issued.

It is possible for an RA with desired=3600 valid=86400 to be followed up with an RA with much
smaller values (or even 0 values if an immediate change is desired for some reason). In such
a case, the smaller values would immediately take effect and then reconfiguration could be
reliably considered complete N seconds (where N = new valid lifetime value in the
previous RA) after the old information is removed from the RA configuration.

DHCP4 provides no such mechanism and RA in IPv4 which does exist, but nobody uses also
lacks this capability to the best of my knowledge.

> machines anymore, but I also don't run an airport or a railroad.

Operator constraints for legacy systems aren’t really something we can address here in a
meaningful way. The question is can we get anywhere like consensus to recommend or
require both protocols in host and router implementations going forward, or, will we allow
the dichotomy of the Anti-DHCP camp and the Anti-RDNSS camp to continue to paralyze
progress in this area?

Owen
(Who is neither anti-DHCP nor anti-RDNSS, but does offer stronger support for RDNSS than DHCP)

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Apr 2017 16:27:31 -0700

> On Apr 3, 2017, at 3:58 PM, Mark Smith <[email-masked]> wrote:
> 

I don’t think that’s a fair characterization. I think that if you want to complain
about the trouble, discussion, and interoperability problems, you have to go
back to the root of bifurcating SLAAC and DHCP and allowing multiple zero
configuration address assignment protocols in the first place. RDNSS is
simply the minimum necessary modification to SLAAC to make it actually
usable as a zero-conf protocol.

Those that are opposed to RDNSS were mostly opposed to SLAAC without
DHCP for at least O-bit purposes before RDNSS existed and are also
mostly the same people still pushing for routing options in DHCP.

> those sorts of problems and costs.

I don’t think that the former is being proposed at all and as to the latter,
the route information in DHCP6 option has been something some subset
of the populace has been pushing for long before, so I don’t think adding
MTI RDNSS for routers and hosts will significantly change that situation.

> record of MAC addresses and corresponding address use).

I think allowing incompatible subsets of the two mechanisms is the mistake.
Requiring the overhead of DHCP just to provide DNS server information was
a mistake and the original demand for RDNSS is sufficient proof of that that I
don’t feel the need to expand further.

> DHCPv6 for addressing too.

I think it’s important to recognize that we are talking about a MTI requirement,
not a must use or must deploy requirement. IMHO, the MTI should, for hosts,
include SLAAC, RDNSS, and where practical/feasible stateless and stateful
DHCP6. For routers, it should include SLAAC, RDNSS, stateful and stateless
DHCP6.

In this way, the routers and hosts ship with the ability for the operator to choose
the subset of SLAAC/RDNSS/Stateful/Stateless that best suits their environment
and best meets the needs of their hosts and users.

Owen

---

From: Mark Smith <[email-masked]>
Date: Tue, 4 Apr 2017 09:36:16 +1000

> MTI. So tiny devices should be covered.

I think the above is a perfect example of the problems of not stating
whether stateful or stateless DHCPv6 is being referred to.

I think stateless DHCPv6 implementations, limited to what is described
in RFC3736 and RFC424, are going to be significantly simpler than
stateful DHCPv4 ones.

 (I think it would be possible to implement a simpler stateless DHCPv4
client, however as there is no alternative way to automate address
configuration, it is likely that there is no such thing has been
specifically implemented.)

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Apr 2017 16:42:23 -0700

> On Apr 3, 2017, at 8:43 AM, Michael H Lambert <[email-masked]> wrote:
> 

I’m not requiring you to use the capability on the router, I’m saying that the router vendor SHOULD make it available for you to choose whether you want to use it or not.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Apr 2017 17:06:06 -0700

> On Apr 3, 2017, at 5:43 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> A speculative breaking statement would be: resolver address delivered by RA overwrites the one delivered by DHCP, despite M==1  (or vice-versa). But never tried it :-)

A network with M=1 and RDNSS in the RA packet is, IMHO, misconfigured by definition, so predictable behavior should not be expected.

Owen

---

From: Fernando Gont <[email-masked]>
Date: Tue, 4 Apr 2017 01:42:36 +0200

On 03/31/2017 08:26 PM, Fred Baker wrote:
> 
> 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.

FWIW, somehow we're saying that. At this point, we're saying "do both",
and if we make RDNSS (only) a MUST, we'd be saying "do SLAAC, which is
the only one that you can expect to work with all nodes".

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

So far we've managed to get the most important bits duplicated into
SLAAC (DNS info, and current effort on duplicating DHCPv6-PD), but have
not done the same to replicate essential info into DHCPv6 (namely routes).

> and incontrovertible statement of what breaks,

One option of "what breaks" would be: "nodes will not learn a DNS
server, and since nodes generally access services via names rather than
literals, they would be unable to access such services"

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

Mandating both RDNSS and stateless DHPv6 would seem to be the most
impartial option....

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

THe only alternative that lets operators decide is to mandate both.

If you don't, then an operators is forced to do *both* RDNSS and
stateless DHCP to cope with Android and Windws (one failing to do
stateless DHCPv6, and the other failing to do RDNSS).

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

FWIW, our I-D was and is meant to avoid such shouting, by making both
RDNSS and stateless DHCPv6 -- i.e., not taking sides with either
protocol, and let folks decide which one they want to use in their own
networks (while supporting all systems).

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 4 Apr 2017 01:49:51 +0200

On 04/03/2017 11:49 AM, Lorenzo Colitti wrote:
> On Mon, Apr 3, 2017 at 4:20 PM, Mikael Abrahamsson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     What I would like to see (this is not breakage though, only
>     potential breakage and cause of confusion) is what a host should do
>     if it gets RDNSS information and potentially DNS resolver
>     information via DHCP.
> 
> 
> Per RFC 8106, it prefers DHCP. (Assuming it supports DHCP, which it is
> not required to do.)

Lovely. Nice outcome in an heterogeneous network.

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 04 Apr 2017 09:47:00 +0200

> I think allowing incompatible subsets of the two mechanisms is the
> mistake.  Requiring the overhead of DHCP just to provide DNS server
> information was a mistake and the original demand for RDNSS is
> sufficient proof of that that I dont feel the need to expand further.

And this line of thinking let to RFC 7710 (captive portals) defining a RA
option next to the DHCPv6 option.

Does that make sense? Why not set the 'O' bit and let the host do a
DHCP lookup. It does make sense if, as a vendor, you refuse to support DHCP.

In a few years, no doubt we are going to a see a NTP option in RA. 
Just this last bit of missing information. Why require the overhead of
DHCP for that?

And somewhere, somebody is probably trying to do PXE boot using RAs.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Apr 2017 10:01:19 +0200

Le 04/04/2017 à 02:06, Owen DeLong a écrit :
>> Le 31/03/2017 à 20:26, Fred Baker a écrit : [...]
>>> 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.
>>
>> Not quite a breaking statement, and more implementation aspects: -
>> the main OS distribution on Raspberry Pi does not implement DNS in
>> RA (other such distrib does, but it's rather marginally deployed).
>> - I understand Windows PCs and routers at IETF dont implement DNS
>> in RA, but rather DNS in DHCP.
>>
>> A speculative breaking statement would be: resolver address
>> delivered by RA overwrites the one delivered by DHCP, despite M==1
>> (or vice-versa). But never tried it :-)
>
> A network with M=1 and RDNSS in the RA packet is, IMHO, misconfigured
> by definition, so predictable behavior should not be expected.

So, if I put RDNSS in RA then I can not deliver an address with DHCP? 
Sounds strange too.

Alex

---

From: Tim Chown <[email-masked]>
Date: Tue, 4 Apr 2017 08:54:56 +0000

On 3 Apr 2017, at 17:48, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:

Whenever I ask to extend ND or put new things into RA, I get lots of pushback. A lot more pushback than when I want a new DHCP option for something that relates to information for the device.

Yet we have RFC7710 as recently as December 2015, which allows any URI to be plugged into an RA - https://tools.ietf.org/html/rfc7710#section-2.3.  I was pretty surprised this one got adopted.

The only major pushback that I have seen to put into DHCPv6 is the default router option for DHCPv6, because if we allow that then I would say that there are lots of other options in RA not currently available in DHCPv6 that I would basically say should be MTI. These are for instance MTU, PIOs with lifetimes etc.

Have you read https://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00 ?  This was written by Ralph in 2009, but encountered rough seas soon after sailing from port. But there was no shortage of people on that boat.

I think saying everything should be configurable using DHCP is short-sighted and removes a lot of the new functionality that IPv6 actually supports in current incarnation, that IPv4 currently doesn’t.

There are certainly technical merits to the RA-based approach.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 4 Apr 2017 09:00:40 +0000

> On 3 Apr 2017, at 18:21, Ted Lemon <[email-masked]> wrote:
> 

Ted, I don’t disagree; while there are some very good points made on both "sides”, a “no action” outcome doesn’t move us forward.

A reminder that “make support for RDNSS a MUST” is an open issue in RFC6434-bis (draft-clw-rfc6434-bis-01), as well as the Requirements for IPv6 Routers draft (draft-ali-ipv6rtr-reqs-02). 

Tim

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 4 Apr 2017 11:25:21 +0200 (CEST)

On Tue, 4 Apr 2017, Tim Chown wrote:

> Yet we have RFC7710 as recently as December 2015, which allows any URI 
> to be plugged into an RA - 
> https://tools.ietf.org/html/rfc7710#section-2.3.  I was pretty surprised 
> this one got adopted.

I have raised that in 6MAN, and my hope is that it won't happen again the 
way it did.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 4 Apr 2017 21:55:25 +0900

On Tue, Apr 4, 2017 at 2:21 AM, Ted Lemon <[email-masked]> wrote:

> This is frustrating.   It seems clear to me that requiring support for
> RDNSS would improve the situation.

+1

As a reminder: the original question in this thread was very simple: do we
have rough consensus to say that hosts MUST implement RDNSS?

Given the strong opposition from major host OS developers, and others on
this thread such as Barbara and James, I really don't see us getting to
consensus that hosts MUST implement DHCPv6. Therefore, in practice there
are only two feasible options:

   1. Don't say anything, and have no mandatory mechanism that operators
   can rely on. Some network/device combinations won't work.
   2. Say that RDNSS is a MUST, and provide a mandatory mechanism that
   network operators can rely on, even if it's not the one they like the most.

The question is not whether we prefer DHCPv6 or RDNSS. The question is
whether we want to do #1 or #2.

---

From: Tim Chown <[email-masked]>
Date: Tue, 4 Apr 2017 13:12:19 +0000

Hi,

On 4 Apr 2017, at 13:55, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Apr 4, 2017 at 2:21 AM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
This is frustrating.   It seems clear to me that requiring support for RDNSS would improve the situation.

+1

As a reminder: the original question in this thread was very simple: do we have rough consensus to say that hosts MUST implement RDNSS?

Given the strong opposition from major host OS developers, and others on this thread such as Barbara and James, I really don't see us getting to consensus that hosts MUST implement DHCPv6. Therefore, in practice there are only two feasible options:

  1.  Don't say anything, and have no mandatory mechanism that operators can rely on. Some network/device combinations won't work.
  2.  Say that RDNSS is a MUST, and provide a mandatory mechanism that network operators can rely on, even if it's not the one they like the most.

The question is not whether we prefer DHCPv6 or RDNSS. The question is whether we want to do #1 or #2.

I’m seeing strong support for RFC6801 RDNSS as a MUST. Personally, I would like to see this, for clients and routers, in RFC6434-bis and draft-ali-ipv6rtr-reqs respectively.

And that would give one MTI method to (on paper at least!) break the current deadlock.

But that doesn’t rule out a statement on *stateless* DHCPv6 support, does it? RFC8601 explicitly discusses what to do in the presence of both mechanisms, and iirc says to place a resolver address learnt by DHCP ahead of any learnt by the RDNSS option, effectively preferring stateless DHCPv6 if present. While I personally believe the RA-based option is technically better, I also see enterprise network admins running IPv6 today who are wondering how they’ll configure (say) NTP server settings, or other settings only available by stateless DHCPv6 and not via RAs. What’s the answer for them, as we move to IPv6-only operation?

Tim

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Apr 2017 15:32:49 +0200

Le 04/04/2017 à 15:12, Tim Chown a écrit :
>> As a reminder: the original question in this thread was very simple:
>> do we have rough consensus to say that hosts MUST implement RDNSS?
>>
>> Given the strong opposition from major host OS developers, and others
>> on this thread such as Barbara and James, I really don't see us
>> getting to consensus that hosts MUST implement DHCPv6. Therefore, in
>> practice there are only two feasible options:
>>
> I’m seeing strong support for RFC6801 RDNSS as a MUST. Personally, I
> would like to see this, for clients and routers, in RFC6434-bis
> and draft-ali-ipv6rtr-reqs respectively.
>
> But that doesn’t rule out a statement on *stateless* DHCPv6 support,
> does it? RFC8601 explicitly discusses what to do in the presence of both
> mechanisms, and iirc says to place a resolver address learnt by DHCP
> ahead of any learnt by the RDNSS option, effectively preferring
> stateless DHCPv6 if present. While I personally believe the RA-based
> option is technically better, I also see enterprise network admins
> running IPv6 today who are wondering how they’ll configure (say) NTP
> server settings, or other settings only available by stateless DHCPv6
> and not via RAs. What’s the answer for them, as we move to IPv6-only
> operation?

I agree with the question.

I would also like to suggest make clearer that any additional 
RA-specific recommendation (like DNS-in-RA) does not impede DHCPv6-PD, 
in addition to stateless DHCPv6.

Alex

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 4 Apr 2017 14:31:16 +0000

> Stuff "designed for homes" gets put on corprate nets all the time.  It should
> just work there.  There is very little, if anything, that doesn't get connected
> to both types of nets.

I guess my employer's corporate network must be very different from that of others. Here, there are very explicit prohibitions (with dire warnings for consequences re continued employment) against attaching unapproved devices. There is zero expectation that "it should just work". In fact, I suspect that failure of such devices to successfully attach would be considered a positive feature. Of course, the corporate network is completely distinct from our pervasive "hotspot" Wi-Fi network that lets anything and anyone attach with ease (used by guests and employee personal devices). I suspect that when these 2 networks deploy IPv6, their addressing architectures will be very different from one another. YMMV. Not all corporate/enterprise networks are the same. IMO, any enterprise network that allows any device to attach is not overly concerned with security or with tracking who and what attaches and runs traffic over their network.
Barbara

---

From: Tim Chown <[email-masked]>
Date: Tue, 4 Apr 2017 14:53:30 +0000

Hi Barbara,

On 4 Apr 2017, at 15:31, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:

It’s a bit of an aside, but since you raised it… consider a university campus, where the WiFi allows any staff or student device to attach. In Europe, and more slowly elsewhere, eduroam is becoming the dominant SSID on campuses. The main reason is that it allows roaming between users of any participant university, by using 802.1X-based user authentication and accountability.  A hierarchy of RADIUS proxies facilitates relaying of credentials. If interested, you can see deployment maps at https://monitor.eduroam.org/map_service_loc.php; the UK has over 1600 sites running eduroam, and it extends to over 70 countries.

There will certainly also be administratively managed systems at university campuses, locked down as you describe above, but the point is that BYOD doesn’t have to equate with no security.

Tim

---

From: Philip Homburg <[email-masked]>
Date: Tue, 04 Apr 2017 17:34:31 +0200

In your letter dated Tue, 4 Apr 2017 14:31:16 +0000 you wrote:
>I guess my employer's corporate network must be very different from that of ot
>hers. Here, there are very explicit prohibitions (with dire warnings for conse
>quences re continued employment) against attaching unapproved devices. 

'approved' doesn't always mean that the network team gets to veto a device.

Say somebody has decided on a particular model of internet connected light
bulbs. So now you have across the building hundreds of light bulbs that
all use privacy extensions. If you are really lucky, they also use MAC
randomization. One of them behaves weird, good luck.

Of course in 99% of the cases there is a simple way out: just don't deploy
IPv6. If IPv4 does what you want and IPv6 doesn't, then why bother.

On a smaller scale, ignoring enterprise requirements, if you have to debug
a network problem, do you really want to keep track of a large collection 
of random 64-bit IIDs? (Of course nobody bothered to set up reverse DNS).
Maybe that's when you want to set up a DHCP server that allocates address
from a relatively small range. Just to restore some kind of sanity.

Too bad, you didn't bother to buy only enterprise ready devices, so most of
them won't cooperate.

---

From: t.petch <[email-masked]>
Date: Tue, 4 Apr 2017 16:59:47 +0100

----- Original Message -----
From: "STARK, BARBARA H" <[email-masked]>
Sent: Tuesday, April 04, 2017 3:31 PM

> I guess my employer's corporate network must be very different from
that of others. Here, there are very explicit prohibitions (with dire
warnings for consequences re continued employment) against attaching
unapproved devices. There is zero expectation that "it should just
work". In fact, I suspect that failure of such devices to successfully
attach would be considered a positive feature. Of course, the corporate
network is completely distinct from our pervasive "hotspot" Wi-Fi
network that lets anything and anyone attach with ease (used by guests
and employee personal devices). I suspect that when these 2 networks
deploy IPv6, their addressing architectures will be very different from
one another. YMMV. Not all corporate/enterprise networks are the same.
IMO, any enterprise network that allows any device to attach is not
overly concerned with security or with tracking who and what attaches
and runs traffic over their network.

<tp>
Barbara

Yup, very different.  I use a large campus network (probably tens of
thousands of users) where it is basically Bring Your Own (laptop etc).
And yes there are periodical outages because a virus got loose.  WiFi is
available but the buildings have, historically, made wired more reliable

On the other hand, it is the only network I know where the constraints
on passwords remotely approach the entropy needed for present day
security.  And I just failed to access e.g. the Irish state Mapping
Agency because MacAfee decided that that that site is unsafe; most
access is to internal corporate servers, not external ones. I suspect it
knows every external web site I have accessed but I have no knowledge
yet of its view of DHCP v RDNSS.

Tom Petch

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Apr 2017 05:08:34 +1000

In message <[email-masked]>, "STARK, BARBARA H" writes:
> I guess my employer's corporate network must be very different from that
> of others.

No.  You are confusing "management permission to connect a device"
with "will that device work when connected".

Is a "Apple TV" a "home device" or just a "device"?
Is a "Amazon Echo" a "home device" or just a "device"?
Is a "Smart TV" a "home device" or just a "device"?
Is a "Refrigerator" a "home device" or just a "device"?

One can go down lists of so-called "home devices" and find that
they have corporate uses.  They should be capable of working when
connected to corporate nets.

> Here, there are very explicit prohibitions (with dire warnings
> for consequences re continued employment) against attaching unapproved
> devices. There is zero expectation that "it should just work". In fact, I
> suspect that failure of such devices to successfully attach would be
> considered a positive feature. Of course, the corporate network is
> completely distinct from our pervasive "hotspot" Wi-Fi network that lets
> anything and anyone attach with ease (used by guests and employee
> personal devices). I suspect that when these 2 networks deploy IPv6,
> their addressing architectures will be very different from one another.
> YMMV. Not all corporate/enterprise networks are the same. IMO, any
> enterprise network that allows any device to attach is not overly
> concerned with security or with tracking who and what attaches and runs
> traffic over their network.
> Barbara

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Apr 2017 08:10:11 +1200

On 05/04/2017 02:31, STARK, BARBARA H wrote:
> I guess my employer's corporate network must be very different from that of others.

Yes. There are lots of enterprise networks, for example probably every university
that supports IPv6, where BYOD is the norm. There are also lots of enterprise
networks that are strict. One size definitely does not fit all. "MUST implement"
is very different from "MUST enable". I believe we're talking about "MUST implement."

    Brian

>Here, there are very explicit prohibitions (with dire warnings for consequences re continued employment) against attaching unapproved devices. There is zero expectation that "it should just work". In fact, I suspect that failure of such devices to successfully attach would be considered a positive feature. Of course, the corporate network is completely distinct from our pervasive "hotspot" Wi-Fi network that lets anything and anyone attach with ease (used by guests and employee personal devices). I suspect that when these 2 networks deploy IPv6, their addressing architectures will be very different from one another. YMMV. Not all corporate/enterprise networks are the same. IMO, any enterprise network that allows any device to attach is not overly concerned with security or with tracking who and what attaches and runs traffic over their network.
> Barbara

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Apr 2017 08:20:22 +1200

On 04/04/2017 12:06, Owen DeLong wrote:
> A network with M=1 and RDNSS in the RA packet is, IMHO, misconfigured by definition, 

I don't understand that assertion. There's nothing in the definition
of M to suggest that. And even for the O bit, DNS info is only given
as an example use. [RFC4861]

Certainly there's *potential* for misconfiguration, if RDNSS and (stateless)
DHCPv6 supply different DNS server addresses. But if they supply the same
address, so what?

> so predictable behavior should not be expected.

Only to the extent discussed in 
https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem
which people seem to have lost interest in.

   Brian

---

From: 神明達哉 <[email-masked]>
Date: Tue, 4 Apr 2017 13:23:36 -0700

At Tue, 4 Apr 2017 21:55:25 +0900,

[...]
> whether we want to do #1 or #2.

Right, and we should really stop discussing in this thread
- whether we should deprecate DNS-related options from DHCPv6 in
  addition to choice #2 above
- whether stateless DHCPv6 for DNS configuration MUST be implemented
- whether both (RDDNS and DHCPv6 for DNS config) MUST be supported
- whether we should provide default router information via DHCPv6
etc.
It's quite obvious that these points are a distraction for the main
question of the thread, which itself is even very contentious already.
If we really want to discuss these additional matters we should
separate the thread.

Now, focusing on the main question, I see some level of support for
option #2, although I also see a non-marginal number of objections.
I'm not sure if we can call it a rough consensus, but if not, I don't
see a possibility to reach one just by continuing this thread.  Maybe
this is the point where we should ask the wg chairs to assess the
sense of the wg.  If the conclusion is that it's a rough consensus,
we'd basically wrap up the document with it and send it to the IESG
(people who oppose the conclusion can still make objection at the time
of the IETF last call).  If it's that we fail to reach a rough
consensus, I think we should accept the reality that we'll never reach
one, and use our time for other issues.

BTW, I can also support choice #2, even though I'm not necessarily a
fan of RDNSS and I see this MUST may have its own adverse effects.

--
JINMEI, Tatuya

---

From: Enno Rey <[email-masked]>
Date: Tue, 4 Apr 2017 22:26:53 +0200

Hi,

> which people seem to have lost interest in.

there's slightly more detailed results (from 2015) in
https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf

For Win10 there's some update in:
https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/

Those results are not exactly encouraging (re: predictable behavior) and I don't see the situation to get better, now that RFC 8106 is there. 
We will release an updated version of the above paper incl. current Android and iOS releases in the next weeks, probably before RIPE74.

best

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Gert Doering <[email-masked]>
Date: Tue, 4 Apr 2017 22:53:58 +0200

Hi,

On Sun, Apr 02, 2017 at 03:22:49PM -0700, Owen DeLong wrote:
> Which vendors? Juniper supports RDNSS, Cisco supports RDNSS, RADVD supports RDNSS???

Cisco?  For a small fraction of their platforms.  Last time I looked,
"IOS XE on ASR1000" - not classic IOS, not IOS XR, not NX-OS.

So, one customer paid enough to make them add it for their use-case,
but "Cisco the company" doesn't seem to believe RDNSS is useful (which
is reflected in comments that you can find online, "why should we
implement RDNSS if everything important can do DHCPv6?").

Annoying, this.

Gert Doering
        -- NetMaster

---

From: Enno Rey <[email-masked]>
Date: Tue, 4 Apr 2017 23:08:26 +0200

Hi Gerd,

> "IOS XE on ASR1000" - not classic IOS, not IOS XR, not NX-OS.

not sure if this correct (or I understand your statement correctly), but see here:
http://blog.ipspace.net/2014/03/cisco-ios-xe-supports-rfc-6106-rdnss.html

[in the comments some more detail on IOS trains]

cheers

Enno

-- 
Enno Rey

---

From: Owen DeLong <[email-masked]>
Date: Tue, 4 Apr 2017 16:34:16 -0500

> On Apr 4, 2017, at 15:20, Brian E Carpenter <[email-masked]> wrote:
> 

AIUI, M=1 says "This network is managed and information in RAs should not be used for anything other than routing information."

I specifically stated M=1 rather than O=1 because I agree that O=1 with RDNSS may be a perfectly valid combination so long as the RDNSS data in the RA (if present) agrees with the DNS information in the DHCP6 respons(es) (if present).

> DHCPv6 supply different DNS server addresses. But if they supply the same

Yes, but in the case of stateless, that's a different more specific criteria needed to constitute misconfiguration. I specifically addressed the stateful case (M=1) where I believe that M=1 effectively instructs the host to ignore any RDNSS data even if it is present. I believe that placing known unusable data in an RA packet constitutes misconfiguration.

Owen

---

From: Enno Rey <[email-masked]>
Date: Tue, 4 Apr 2017 23:45:28 +0200

On Tue, Apr 04, 2017 at 04:34:16PM -0500, Owen DeLong wrote:
> >>> Le 31/03/2017 ?? 20:26, Fred Baker a ??crit :
> >>> [...]

huh? 
All (DHCPv6-capable) OSs I know and I've tested (quite a few) perform a stateful DHCPv6 exchange when M=1 AND fully process the RA incl. namely the PIO (hence they have several addresses once A=1). This is, afaik, perfectly valid as of RFC 4862 et al.

> Yes, but in the case of stateless, that's a different more specific criteria needed to constitute misconfiguration. I specifically addressed the stateful case (M=1) where I believe that M=1 effectively instructs the host to ignore any RDNSS data even if it is present.

that's not correct. Many OSs take RDNSS information from *both* sources (but behave differently when it comes to prioritize/order those). See
https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf, p. 13.

Also section 5.3.1 of both RFCs 6106 and 8106 wouldn't be needed if your assertion was correct.

> I believe that placing known unusable data in an RA packet constitutes misconfiguration.

It may also constitute the network operator's will to properly support different clients in a heterogenuous environment, say a Guest WLAN serving both Android and Windows clients.

best

Enno

-- 
Enno Rey

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Apr 2017 09:56:38 +1200

> AIUI, M=1 says "This network is managed and information in RAs should not be used for anything other than routing information."

That is not, however, what RFC4861 says.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Apr 2017 10:44:23 +1000

<snip>
> usable as a zero-conf protocol.

Being pedantic and in the interests of accuracy, SLAAC has nothing to
do with this and using that term will confuse the discussion. SLAAC is
an address configuration method that that uses the RA PIO options, and
is not involved in DNS configuration.

RDNSS and DNSSL information is also conveyed via RA options that are
independent of PIO options that are used for SLAAC, so I think it is
better to use the general terms "RA RDNSS" or RDNSS to describe the
use of these RA options for DNS configuration.

> mostly the same people still pushing for routing options in DHCP.

I'm for using SLAAC for addressing and using stateless DHCPv6 for
configuring upper layer host parameters such as DNS, NTP, timezone
etc. options.

I think the problems are different enough that there should be two solutions.

Link specific network layer IPv6 parameters such as what the link's
address space is, what available default routers are, what address
space is on-link, and what the ND operational parameters are is a
separate and link specific problem. A different instance of that
problem exists on each link in the network, so the problem is local to
a link. A local solution to a local problem is going to be more robust
than a remote solution to a link local problem.

Upper layer host parameters are host specific and have values that are
independent of the link. While it might be useful to have sets of
these parameters that are grouped according to a link, there is no
inherent requirement to do so - each host on a link can have different
upper layer parameters, and it won't prevent them from communicating
on the link or beyond it.

Flipping that example around, it is error prone for a host to be able
to learn of a default gateway that is off-link. That is always a risk
if the default gateway information has come from an off-link source
such as via DHCP.

> MTI RDNSS for routers and hosts will significantly change that situation.

It has already happened at least once, and RDNSS was used to justify it.

"The IPv6 Router Advertisement Option for NTP Configuration"
https://tools.ietf.org/id/draft-chen-ntps-ra-opt-00.txt

"The reasons of
   using RAs to transport the prefix information option based on the ND
   protocol [RFC4861] are very similar with those of using RAs to
   transport the information of DNS servers [RFC5006]:"

This RA NTP option proposal is what prompted me to mention limiting
upper layer RA options to RDNSS in the "Internet Transparency and
Application Configuration" section of this draft:

"IPv6 CE Device DHCPv6 Option Transparency"
https://tools.ietf.org/id/draft-smith-v6ops-ce-dhcpv6-transparency-00.txt

> don’t feel the need to expand further.

I don't understand this view that DNS information is the only
additional information a host needs over its addresses and default
gateways. How does a host set its real time clock correctly in an
automated fashion?

I find pages like this one to be ridiculous when it is possible to buy
an off-the-shelf near self driving car.

http://www.internode.on.net/support/guides/general_settings/

When I configured the DHCPv6-PD server on the BRAS at that
organisation, I put all of those parameters in as DHCPv6 parameters,
so that they could be configured automatically, rather than the
customer having to manually cut-and-paste them, a possibly error prone
procedure.

The reason I wrote the above draft was that even though the DHCPv6-PD
server might support providing those options, the down stream hosts
which would want and use those options may not be able to successfully
ask for them, because the CPE's combined DHCPv6 WAN side client and
LAN side server might not support the DHCPv6 options that the up
stream DHCPv6-PD server and the downstream host client supported.

> and best meets the needs of their hosts and users.

I think one of the major causes of the gap we're now encountering is
because operators of networks, including and more recently
enterprises, don't have as much control over the features and options
of the devices/host implementations that expect to attach to the
network as they used to. End-users expect the mobile device that
they've bought independently of their employer to be able to be
seamlessly be attached to their employer's network. Retail of the
shelf devices such as Apple TVs are expected to just work when they're
plugged into the corporate network (assuming the person buying it has
permission to use it).

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Apr 2017 05:48:16 +0200 (CEST)

On Tue, 4 Apr 2017, Owen DeLong wrote:

> AIUI, M=1 says "This network is managed and information in RAs should 
> not be used for anything other than routing information."

Nope, the only thing it indicates is a hint to devices on the link that 
there might be additional addresses available using DHCPv6.

Btw, from a MIF scenario, what happens if there are two routers on the 
link advertising different PIOs, and both of them have DHCPv6 IA_NA 
providing servers. Does this even work? What about stateless information, 
can they each provide a resolver (so a MIF aware host can use each 
resolver depending on if it's going to use an address out of PIO1 or 
PIO2).

R1 announces PIO1 and M=1
R2 announces PIO2 and M=1

R1 --- H1
R2 -/

(all devices are on the same LAN)

Both R1 and R2 has a built in DHCPv6 server. Does getting one IA_NA out of 
each PIO work?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Apr 2017 16:33:45 +0900

> Both R1 and R2 has a built in DHCPv6 server. Does getting one IA_NA out of

In theory, maybe. In practice, no, because clients use the first OFFER they
receive.

DHCPv6 is pretty fundamentally incompatible with having multiple sources of
information. Even if clients chose between multiple offers, and were thus
able to select from multiple sources of information at the time the SOLICIT
was sent, how would you deal with introducing a new source of information?

This is one of the many reasons why DHCPv6 does not work well in dynamic
networks, and of course, it is a problem that RAs and RDNSS do not have.

The only reason why DHCP works well today is because in IPv4 you only have
one address and one default route, and most networks are NATed so nothing
needs to change. In fact, I personally think the biggest lie in DHCP is the
D. It should have been called SHCP - where S is for Static. :-)

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Apr 2017 16:36:04 +0900

On Tue, Apr 4, 2017 at 10:12 PM, Tim Chown <[email-masked]> wrote:

> I also see enterprise network admins running IPv6 today who are wondering
> how they’ll configure (say) NTP server settings, or other settings only
> available by stateless DHCPv6 and not via RAs. What’s the answer for them,
> as we move to IPv6-only operation?
>

Speaking for the Android implementation only - Android has never supported
any of those options anyway, even in IPv4:

    /* package */ static final byte[] REQUESTED_PARAMS = new byte[] {
        DHCP_SUBNET_MASK,
        DHCP_ROUTER,
        DHCP_DNS_SERVER,
        DHCP_DOMAIN_NAME,
        DHCP_MTU,
        DHCP_BROADCAST_ADDRESS,  // TODO: currently ignored.
        DHCP_LEASE_TIME,
        DHCP_RENEWAL_TIME,
        DHCP_REBINDING_TIME,
        DHCP_VENDOR_INFO,
    };

---

From: Tim Chown <[email-masked]>
Date: Wed, 5 Apr 2017 08:58:18 +0000

> On 5 Apr 2017, at 08:33, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Wed, Apr 5, 2017 at 12:48 PM, Mikael Abrahamsson <[email-masked]> wrote:
> Both R1 and R2 has a built in DHCPv6 server. Does getting one IA_NA out of each PIO work?
> 
> In theory, maybe. In practice, no, because clients use the first OFFER they receive.
> 
> DHCPv6 is pretty fundamentally incompatible with having multiple sources of information. Even if clients chose between multiple offers, and were thus able to select from multiple sources of information at the time the SOLICIT was sent, how would you deal with introducing a new source of information?

Well, we batted around thoughts on this some time ago in RFC4477, in the context of DHCPv4 and DHCPv6 co-existing; no clash on addresses, but potentially a clash on other configuration information.  If it’s one administrative domain, it should be consistent information.

> This is one of the many reasons why DHCPv6 does not work well in dynamic networks, and of course, it is a problem that RAs and RDNSS do not have.

I agree on the technical merits of RA-based config, but in a typical enterprise the addresses of the DNS, NTP and other servers is pretty stable. I don’t remember changing them at our uni for many years.  

> The only reason why DHCP works well today is because in IPv4 you only have one address and one default route, and most networks are NATed so nothing needs to change. In fact, I personally think the biggest lie in DHCP is the D. It should have been called SHCP - where S is for Static. :-)

So file an erratum :)

Tim

---

From: Tim Chown <[email-masked]>
Date: Wed, 5 Apr 2017 09:03:12 +0000

> On 5 Apr 2017, at 08:36, Lorenzo Colitti <[email-masked]> wrote:
> 
> I also see enterprise network admins running IPv6 today who are wondering how they’ll configure (say) NTP server settings, or other settings only available by stateless DHCPv6 and not via RAs. What’s the answer for them, as we move to IPv6-only operation?  
> 
> Speaking for the Android implementation only - Android has never supported any of those options anyway, even in IPv4:
> 

That’s actually a very handy thing to know, thanks.

Tim

---

From: Philip Homburg <[email-masked]>
Date: Wed, 05 Apr 2017 11:23:27 +0200

>option #2, although I also see a non-marginal number of objections.

If the question is "Do you support making RDNSS a MUST, saying nothing
about DHCP DNS" then my answer is that I oppose that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Apr 2017 18:37:45 +0900

> about DHCP DNS" then my answer is that I oppose that.

Ok, so you're saying that of the two options, you choose option #1: do
nothing and keep the current situation where there no method is required to
be supported.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 05:23:24 -0700

> about DHCP DNS" then my answer is that I oppose that.

Because it would cause what problem?

---

From: Philip Homburg <[email-masked]>
Date: Wed, 05 Apr 2017 14:40:07 +0200

>Because it would cause what problem?

If we have two mechanisms and make only one a MUST, then we implicitly send
a message that the other one is optional, and given that it's a duplicate,
ready to be deprecated.

In the long run giving preferential treatment to RDNSS and telling vendors
that it is ok to not support DHCP, will lead to more RA options for values
that are better served by DHCP, but have to be included in RA because there
is no support for DHCP.

Do we really want a RA option for NTP servers? One way forward is to duplicate
lots of DHCP options in RA, just because some vendors refuse to support DHCP.
That doesn't strike a good protocol design to me. RFC 7710 shows that that
process has already started.

So the way forward is that everywhere where we require some RA/SLAAC feature
and there is a corresponding DHCP feature, we require that feature as well.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 05:46:15 -0700

> and there is a corresponding DHCP feature, we require that feature as well.

This is very tight, but the premise that you are assuming is that people won't implement DHCP because it's not required.   They are already doing that.   So I don't think it serves as a valid downside.   As for not putting DHCP in the router, do you really think that's realistic?   Do you know of any routers that don't have it?   It's there because there's a clear demand for it.   The problem we have is that RDNSS is not on an equal footing with DHCP right now, because people who decide what features to implement don't realize that it's important.

Right now, if you want DHCP on the host side, it's there on the network side, or at least can be; if it's not there, it's because the network doesn't need to tell you about NTP servers (and, by the way, you are _insane_ if you trust the DHCP server to tell you what NTP server to talk to, but that's a side issue).   So a host that doesn't do DHCP isn't doing it because all it needs is RDNSS.   But if the network doesn't provide RDNSS, the host can't get it.

_This is the problem_.   The problem is not that router vendors aren't implementing DHCP.

---

From: [email-masked]
Date: Wed, 05 Apr 2017 14:59:21 +0200 (CEST)

> This is very tight, but the premise that you are assuming is that
> people won't implement DHCP because it's not required.

>From my point of view it looks more like some people don't want to
implement DHCPv6 for political reasons. As Nick Hilliard said on

> particular protocol deployment path.

There is unfortunately a significant lack of trust in the intentions
of those who want to make RDNSS a MUST.

Steinar Haug, AS2116

---

From: Tim Chown <[email-masked]>
Date: Wed, 5 Apr 2017 13:13:17 +0000

> On 5 Apr 2017, at 13:59, [email-masked] wrote:
> 

Is a way forward to say

a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and routers; it’s not a significant implementation or running cost to any device, and an operator may still choose whether to use it or not

b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in routers, noting implementation on IoT and constrained devices may not be realistic (noting Owen’s posted figures), but that managed enterprise environments will expect other configuration information beyond RDNSS and DNSSL to be available, so that local services can be used (rather than, say, Google DNS or time servers).  Again, it’s up to the operator to enable it

This gives a common MTI method, and acknowledgment that stateless DHCP may be omitted in IoT, but is expected in managed enterprises.
 
And we have an RFC that describes how to handle the case of both being enabled (i.e., prefer DHCP by inserting a resolver learnt by DHCP at the top of the resolver list)

Tim

---

From: Philip Homburg <[email-masked]>
Date: Wed, 05 Apr 2017 15:17:47 +0200

> people won't implement DHCP because it's not required.   They are
> already doing that.   So I don't think it serves as a valid downside.
> As for not putting DHCP in the router, do you really think that's
> realistic?   Do you know of any routers that don't have it?   It's
> there because there's a clear demand for it.   The problem we have
> is that RDNSS is not on an equal footing with DHCP right now,
> because people who decide what features to implement don't realize

If all routers already support DHCP and want to continue to support
DHCP, then adding a requirement to implement both DHCP and RDNSS is no
problem right?

Just add both as a requirement, problem solved.

> Right now, if you want DHCP on the host side, it's there on the
> network side, or at least can be; if it's not there, it's because
> the network doesn't need to tell you about NTP servers (and, by
> the way, you are _insane_ if you trust the DHCP server to tell you
> what NTP server to talk to, but that's a side issue).   So a host
> that doesn't do DHCP isn't doing it because all it needs is RDNSS.
> But if the network doesn't provide RDNSS, the host can't get it.

Secure NTP is a huge problem, so by and large NTP data is not authenticated.
Beyond that, you either have to manually configure NTP servers or you
use pool. If you trust pool more than your local network admins, you probably
have bigger issues than NTP.

> aren't implementing DHCP.

So, you have a host operating system. You know that there is universal 
support for DHCP by routers, and you still leave out DHCP and wait for a BCP
that makes RDNSS mandatory in routers. Does that make sense?

Note that where this incompatibility happens in practice is with hosts
that have a quad core processor and 4 gig memory.

---

From: David Farmer <[email-masked]>
Date: Wed, 5 Apr 2017 08:21:40 -0500

> Because it would cause what problem?

Because it delays maximal effectiveness of the solution. Yes, eventually
all non-compliment host and routers will be replaced.

However, If we require both RDNSS and DHCPv6 for both routers and host, we
reach maximal effectiveness sooner.  Within any environment by requiring by
both for both, once all non-compliment hosts or all non-compliment routers
are upgraded the site is guaranteed to be good. And with both for both, the
probability of a site achieving functional compliance before a guarantee of
compliance is much higher.   Otherwise, if you only require RDNS for both
hosts and routers then both all non-compliment hosts and routers need to be
upgraded to guarantee of compliance, and the probably of rechaing
functional compliance is lower.

In some situations and sites the difference between these will be
negligible, however in other situations and sites the difference could be
many years.

-- 
===============================================
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: Timothy Winters <[email-masked]>
Date: Wed, 5 Apr 2017 09:28:37 -0400

Hi Tim,

I would add that supporting 3736 as Relay Agent.   I'm guessing that many
routers will just use the relay function to send the DHCP messages to a
central server.

~Tim

On Wed, Apr 5, 2017 at 9:13 AM, Tim Chown <[email-masked]> wrote:

> a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and
> routers; it’s not a significant implementation or running cost to any
> device, and an operator may still choose whether to use it or not
>
> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in
> routers, noting implementation on IoT and constrained devices may not be
> realistic (noting Owen’s posted figures), but that managed enterprise
> environments will expect other configuration information beyond RDNSS and
> DNSSL to be available, so that local services can be used (rather than,
> say, Google DNS or time servers).  Again, it’s up to the operator to enable
> it
>
> This gives a common MTI method, and acknowledgment that stateless DHCP may
> be omitted in IoT, but is expected in managed enterprises.
>
> And we have an RFC that describes how to handle the case of both being
> enabled (i.e., prefer DHCP by inserting a resolver learnt by DHCP at the
> top of the resolver list)
>
> Tim

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: [email-masked]
Date: Wed, 05 Apr 2017 15:31:13 +0200 (CEST)

> that have a quad core processor and 4 gig memory.

I believe the lack of DHCPv6 in Android is a political descision. It
certainly isn't due to lack of hardware resources.

Steinar Haug, AS2116

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 01:35:45 +1200

On 05/04/2017 12:44, Mark Smith wrote:
...
> gateways.

That isn't the assertion. It's that DNS information is the only
additional information a host needs *in order to get basic
connectivity to the Internet*.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 01:51:34 +1200

On 06/04/2017 00:59, [email-masked] wrote:
...
> of those who want to make RDNSS a MUST.

On 06/04/2017 01:31, [email-masked] wrote:
...
> I believe the lack of DHCPv6 in Android is a political descision.

I don't believe we will get the right answer based on that sort of
argument. It shouldn't matter what the motivations of implementers
or operators are; what matters is what we observe in running networks.
And that is a mixture of two solutions. The rational response to
that is that our BCP should say "everybody, implement both".

(If you doubt that, imagine a world in which some cities deploy
traffic lights and other cities deploy Stop signs. Some drivers
stop only at red lights and others stop only at Stop signs.)

   Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 5 Apr 2017 14:06:40 +0000

> On 5 Apr 2017, at 14:28, Timothy Winters <[email-masked]> wrote:
> 
> Hi Tim,
> 
> I would add that supporting 3736 as Relay Agent.   I'm guessing that many routers will just use the relay function to send the DHCP messages to a central server.  

Yes, indeed.

It’s basically what Owen was proposing what feels like a few hundred emails ago; a clear model for hosts and routers, but adding qualifications for the SHOULD. I think my MUSTs and SHOULDs are the same as he proposed.

Tim

> Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR
>

---

From: Erik Kline <[email-masked]>
Date: Wed, 5 Apr 2017 23:15:20 +0900

On 5 April 2017 at 23:06, Tim Chown <[email-masked]> wrote:

> > I would add that supporting 3736 as Relay Agent.   I'm guessing that
> many routers will just use the relay function to send the DHCP messages to
> a central server.
>
> Yes, indeed.
>
> It’s basically what Owen was proposing what feels like a few hundred
> emails ago; a clear model for hosts and routers, but adding qualifications
> for the SHOULD. I think my MUSTs and SHOULDs are the same as he proposed.
>
> Tim

We shouldn't pretend, though, that DHCPv6 DNS and RA DNS are the same and
the choice is between two equal things.

>From my point of view, RA DNS is way more expressive and useful than DHCPv6
DNS.

Specifically, consider the case where 2 RAs are sent on the network each
with different PIOs, RIOs, and RDNSS sets.  End nodes can associate all
this information with each next hop, and make better, logically consistent
use of essentially two different networks a la RFCs 7556 and 8028.

I don't think DHCPv6 DNS can do that.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 5 Apr 2017 14:25:42 +0000

That is correct as DHCP assumes a single provisioning domain and if the two RAs are from different ones, there’s no way to indicate that. DHCP could send a combined list, but not ones specific to an internet.

There was MIF work on PVD option for DHCPv6, but a patent issue pretty much killed that. See https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-dhcp-support/.

-          Bernie

From: v6ops <[email-masked]> on behalf of Erik Kline <[email-masked]>
Date: Wednesday, April 5, 2017 at 10:15 AM
To: Tim Chown <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] Making RDNSS a MUST?

On 5 April 2017 at 23:06, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:
> On 5 Apr 2017, at 14:28, Timothy Winters <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Tim,
>

Yes, indeed.

Tim

We shouldn't pretend, though, that DHCPv6 DNS and RA DNS are the same and the choice is between two equal things.

From my point of view, RA DNS is way more expressive and useful than DHCPv6 DNS.

Specifically, consider the case where 2 RAs are sent on the network each with different PIOs, RIOs, and RDNSS sets.  End nodes can associate all this information with each next hop, and make better, logically consistent use of essentially two different networks a la RFCs 7556 and 8028.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 05 Apr 2017 16:30:37 +0200

>I don't think DHCPv6 DNS can do that.

In the context of IA_NA, each Advertise message may have its own set of
DNS resolvers (and default router, if some people would stop blocking that
option). No difference there.

In addition, DHCP can tailer responses per client. So you can give some 
clients a different set of resolvers, even based on the device vendor.

With support for Reconfigure, DHCP can also support quickly changing 
configuration without waiting for a timeout.

---

From: Richard Hartmann <[email-masked]>
Date: Wed, 5 Apr 2017 16:30:59 +0200

I don't write often, even if I lurk extensively. Also, please note
that I quote out of order in this reply.

> that is that our BCP should say "everybody, implement both".

And that's what could, and should, end this and similar threads forevermore.

> or operators are; what matters is what we observe in running networks.

Leaving the realms of technical solutions and delving into the depths
of humanity, this and similar threads are blocked by a stand-off in
which neither side of an old argument is willing to cede that one last
bit which could make the other one feature complete and thus "win".
And that's why even having both at once seems not to be able to reach
consensus.

Two more points:
Having two full implementations at my disposal, I would probably use
the smaller, light-weight one for larger network segments and server
setups (i.e. ISP, colo, CPEs, etc) and the more feature-rich one for
end user networks (i.e. enterprise and whatever's behind the CPE).
Choosing what fits a particular and specific set of engineering
constraints and requirements seems like a good approach.
Also, from lurking the TLS and related lists, I can say that the
implementors on very low powered devices will do what they want (or
need) to do anyway. Catering to them specifically and holding the
standards at large back due to those considerations might not be the
best of ideas and TLS thankfully stopped doing that.

And yes, I know, none of this is new or surprising to anyone on this list.

Back to lurking,
Richard

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Apr 2017 16:35:21 +0200 (CEST)

> configuration without waiting for a timeout.

This sounds like one DHCP server. I was talking about a LAN with multiple 
DHCP servers (for instance, built into two separate routers).

---

From: [email-masked]
Date: Wed, 05 Apr 2017 16:46:01 +0200 (CEST)

> Is a way forward to say
> 
> a) RFC8601 RA-based support for RDNSS & DNSSL is a MUST in hosts and routers; it's not a significant implementation or running cost to any device, and an operator may still choose whether to use it or not
> 
> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in routers, noting implementation on IoT and constrained devices may not be realistic (noting Owen's posted figures), but that managed enterprise environments will expect other configuration information beyond RDNSS and DNSSL to be available, so that local services can be used (rather than, say, Google DNS or time servers).  Again, it's up to the operator to enable it

I'd actually like to explore a slightly different scenario for hosts:
RFC3736 stateless DHCP *and* RFC3633 Prefix Delegation both being MUST
for hosts (but not RFC3315 IA_NA/IA_TA).

I'm suggesting this because my impression is that at least some of the
resistance against DHCPv6 for hosts is the fact that IA_NA only gives
you *one* address. Prefix delegation can hand out a /56 or a /48 if
needed. Yes, prefix delegation is supposed to be for routers - but in
my book an Android with several other devices tethered behind it is
definitely a router.

It's of course entirely possible that prefix delegation doesn't make
DHCPv6 any more interesting for those who are opposed today. Having
some idea of the status here would be interesting.

Steinar Haug, AS2116

---

From: Philip Homburg <[email-masked]>
Date: Wed, 05 Apr 2017 16:48:36 +0200

>DHCP servers (for instance, built into two separate routers).

The DHCP protocol supports multiple servers. See Section 17.1.3 of RFC 3315
(https://tools.ietf.org/html/rfc3315#section-17.1.3)

Traditionally, a host gets one address from one server. So there may be
corner cases that would need to be addressed.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 08:12:37 -0700

On Apr 5, 2017, at 5:59 AM, [email-masked] wrote:
> implement DHCPv6 for political reasons.

What, they are trying to get elected, and by taking this political position they hope to appeal to their demographic?   They are competing in a marketplace.   If they can say "no, I won't implement this" and not lose market share, then saying it's "political" is just a way of applying a pejorative label to a design decision you don't like.

---

From: james woodyatt <[email-masked]>
Date: Wed, 5 Apr 2017 08:13:42 -0700

On Apr 5, 2017, at 07:46, [email-masked] wrote:
> 
> It's of course entirely possible that prefix delegation doesn't make [Stateless] DHCPv6 any more interesting for those who are opposed today. Having some idea of the status here would be interesting.

My principle long-standing criticism of Stateless DHCPv6 [RFC 3736] has always been for its lack of adequate methods for immediately reconfiguring hosts when the network configuration parameters change. I think Lorenzo has often made the same criticism, but I think he has a longer list of additional technical objections.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 08:15:06 -0700

On Apr 5, 2017, at 6:21 AM, David Farmer <[email-masked]> wrote:
> However, If we require both RDNSS and DHCPv6 for both routers and host, we reach maximal effectiveness sooner.

Right, but if we do neither, we reach maximal effectiveness later.   That is the status quo.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 08:20:11 -0700

On Apr 5, 2017, at 7:48 AM, Philip Homburg <[email-masked]> wrote:
> (https://tools.ietf.org/html/rfc3315#section-17.1.3 <https://tools.ietf.org/html/rfc3315#section-17.1.3>)
> 

DHCP clients don't typically talk to more than one DHCP server per interface at the same time, so this model totally breaks down when you try to get the behavior that Erik is describing.   In principal you can have a DHCP server provide a different DNS server per IA_NA, but in practice I don't see that happening, and I doubt it would be reliable to try to count on it working.

Of course, the same can be said for what Erik described, but I suspect Erik was describing a particular and rather widespread implementation, and perhaps motivating his reasoning for preferring this solution in that implementation.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 05 Apr 2017 17:36:48 +0200

>    DHCP clients don't typically talk to more than one DHCP server
>    per interface at the same time, so this model totally breaks
>    down when you try to get the behavior that Erik is describing.
>    In principal you can have a DHCP server provide a different DNS
>    server per IA_NA, but in practice I don't see that happening,
>    and I doubt it would be reliable to try to count on it working.

Prior to RFC 8028 (First-Hop Router Selection by Hosts in a
Multi-Prefix Network) hosts were not really aware of multiple default
routers and how they relate to source addresses.

Additional requirement for hosts get published all the time. If we think that
supporting multiple DHCP servers is important, then we can just as well
publish a BCP that says that.

Even today, it is very unlikely that hosts will keep DNS resolver information
received from different routers apart. Most hosts already have trouble keeping
DNS resolvers on different interfaces separate.

So we are talking protocols and what hosts can do potentially. Not what
operators can rely on that most host implementations already do. For an
operator it doesn't really help to use a feature that is supported by
only one vendor (unless you are willing to limit yourself to only products
from that vendor).

And I guess you are not going to tell me that Erik's employer cannot affort
to fix a DHCP client implementation to support multiple DHCP servers.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Apr 2017 00:39:22 +0900

On Wed, Apr 5, 2017 at 10:13 PM, Tim Chown <[email-masked]> wrote:

> routers

I don't think we should recommend stateless DHCP support in hosts because
it is technically inferior to RDNSS. (For a list of reasons why, see
https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html , and
also see what James just wrote) Taking a host that is capable of doing
RDNSS and forcing it to also implement a less-capable protocol is a bad
tradeoff for that host's users.

That is why host OS developers are opposed to DHCPv6, and I'm afraid that
opposition is not going to go away. "My network, my choice" (as Job
succinctly described a similar position in IEPG), is certainly not
sufficient justification to change it. "This is what we do in IPv4" is also
not - mass deployment of IPv4 will eventually go away, but the choices we
make now are going to shape IPv6 for several decades after that.

We should all be providing what's best for our users.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Apr 2017 00:41:55 +0900

> publish a BCP that says that.

Even if you do, you still have the problem that it is impossible to add a
new DHCPv6 server to add more information while the client already has a
lease. DHCPv6 is a request-response protocol, and those protocols are
fundamentally not good ad distributing new information efficiently.

You also have the problem that if a server crashes nobody can tell the
client that something has changed because the nonce is gone.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 08:46:58 -0700

> publish a BCP that says that.

This is directed reasoning.   Speaking as someone who should probably know, what you are describing is a new standards track document, which would take a year at least to publish if we started right now, and if there were consensus to do it.   Getting DHCP to do what you are saying is not trivial. This isn't a small tweak—it's a substantial change in the flow of the protocol.   We certainly envisioned this possibility when we wrote RFC 3315, but it turns out that we didn't specify it clearly enough, and nobody implemented anything like it.   To fix that would be real work, not a line in a requirements doc.

---

From: Chuck Anderson <[email-masked]>
Date: Wed, 5 Apr 2017 11:48:54 -0400

Why are DNS resolvers a link-specific parameter that needs to be
distributed to clients at all?  Can't they just use some other
discovery mechanism to find a resolver or do full-recursion w/DNSSEC
validation?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 08:53:47 -0700

> discovery mechanism to find a resolver or do full-recursion w/DNSSEC

Because end-users would suffer if they didn't use the configured resolver: the DNS protocol is designed with caching in mind, and at this point CDNs use DNS extensively.   So if you don't use the local resolver, you will see major performance issues.   But yeah, aside from that quibble, what you are saying makes a lot of sense (seriously!).   :)

---

From: Philip Homburg <[email-masked]>
Date: Wed, 05 Apr 2017 18:00:56 +0200

>fundamentally not good ad distributing new information efficiently.

Of course you can. If a new router pops up and sends a RA with the M bit set
then the host can retry obtaining DHCP leases. We currently don't have
that specified. But that's only a few lines in a BCP.

>client that something has changed because the nonce is gone.

Yes, and using RAs it is very hard to have host specific configuration.

It is not clear to me what server you are talking about. If you are talking
about a DHCP server, then at the time scale DHCP server operate, certainly in
small networks, there are plenty of options of storing state persistently.

(Note that just about all IPv4 DHCP servers store DHCP leases persistently).

In bigger networks, it is way more efficient to have a cluster of DNS
resolvers, than to try to update all hosts and hope that all hosts also
support reloading DNS resolvers in running processes.

By all means, if you think that in your network it is likely that your DNS
resolvers change addresses, use RDNSS. However, that is very poor argument
for refusing to support DHCP in networks where the DNS resolvers will never
change addresses and people want the ability direct select hosts to different
resolvers. Or want to use DHCP to pass additional options to some hosts
and do not want to configure RDNSS on all routers just because some hosts
refuse to support DHCP.

---

From: Chuck Anderson <[email-masked]>
Date: Wed, 5 Apr 2017 12:04:21 -0400

> Because end-users would suffer if they didn't use the configured resolver: the DNS protocol is designed with caching in mind, and at this point CDNs use DNS extensively.   So if you don't use the l…

Okay, so can't clients just do a mDNS request to find a local resolver?

I have a strong dislike of involving the router in distributing
higher-layer parameters like RDNSS and DNSSL.  It causes real
operational problems when the DNS infrastructure and routers are
maintained by different teams.  Also, having DNS resolvers distributed
by routers means there is no fate-sharing between the provider of the
service and the distributor of the configuration.  If a DNS server
goes down, how do all the routers in the network magically get updated
with new DNS server configuration to distribute to the clients?

With DHCP, the DNS server can and often is co-located with the DHCP
server.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 09:05:20 -0700

> Okay, so can't clients just do a mDNS request to find a local resolver?

https://xkcd.com/927/ <https://xkcd.com/927/>

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Apr 2017 18:07:46 +0200

Hi,

> with new DNS server configuration to distribute to the clients?

I really wonder if anyone does it that way.  

"Our DNS server has died, so let's quickly provide new recursor addresses
to EVERYTHING"

instead of

"Our DNS server has died, let's put that address on the secondary box, 
so clients can just happily continue using the address they have learned
by whatever means"

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Wed, 5 Apr 2017 09:13:50 -0700

> Okay, so can't clients just do a mDNS request to find a local resolver?

Too expensive. Let’s just use link-local multicast CoAP to send a CoRE-RD query for rt=“dns” instead.

---

From: [email-masked]
Date: Wed, 05 Apr 2017 18:27:15 +0200 (CEST)

> so clients can just happily continue using the address they have learned

"One of our anycast DNS servers has died. While we work to get that
server up and running again, clients will happily continue using the
same anycast server address - but may experience slightly increased
latency."

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Apr 2017 01:34:54 +0900

> same anycast server address - but may experience slightly increased

Well, but that's not a useful argument. Just because certain networks don't
take advantage of RDNSS being better doesn't mean it's not better.

---

From: Ross Chandler <[email-masked]>
Date: Wed, 5 Apr 2017 17:36:01 +0100

> On 5 Apr 2017, at 15:46, [email-masked] wrote:
> 
>> Is a way forward to say
>> 
>> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in routers, noting implementation on IoT and constrained devices may not be realistic (noting Owen's posted figures), but that managed enterprise environments will expect other configuration information beyond RDNSS and DNSSL to be available, so that local services can be used (rather than, say, Google DNS or time servers).  Again, it’s up to the operator to enable it

+1

+1
> my book an Android with several other devices tethered behind it is

It seems their objections to DHCPv6 IA_NA/IA_TA has broadened since last year to include PD.

Does Google ever want Android devices getting more than a /64?

Ross

---

From: Chuck Anderson <[email-masked]>
Date: Wed, 5 Apr 2017 12:44:33 -0400

> take advantage of RDNSS being better doesn't mean it's not better.

The current operational reality is that irrespective of HOW DNS
configuration is distributed (and how many DNS servers are available),
Anycast DNS is the only way to provide highly-available DNS resolving
service to a diverse set of unmanaged local clients.

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Apr 2017 19:02:01 +0200

Hi,

> same anycast server address - but may experience slightly increased

Assuming old-style setups, where "one of our machines has died" actually
needs manual intervention to keep client happiness...

Our DNS recursors run anycast, and have used the very same IPv6 addresses
for 15+ years.  Replacing hardware and upgrading OS a number of times,
and no, we didn't announce new addresses to the clients every time we
broke something - neither RDNSS nor DHCPv6 (nor IPv4 DHCP, for that matter).

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Apr 2017 19:03:03 +0200

Hi,

> take advantage of RDNSS being better doesn't mean it's not better.

Using whatever mechanism to distribute new information instead of just
making sure that the existing information *works* is silliness.

Doesn't matter if it's silliness wrapped in RDNSS, DHCPv6 or puppet.

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 08:03:12 +1200

> tradeoff for that host's users.

implement != enable-by-default

Your argument might be valid against enable-by-default but it certainly isn't
valid against (implement & disable-by-default).

In fact one algorithm for travelling hosts might be that when attaching to
a new network, if no RDNSS has been received after N seconds, then try
stateless DHCPv6. That seems like a decent tradeoff for the host's users.

    Brian

---

From: Chuck Anderson <[email-masked]>
Date: Wed, 5 Apr 2017 16:13:01 -0400

> stateless DHCPv6. That seems like a decent tradeoff for the host's users.

Even better than that is just use the M & O bits to signal DHCPv6.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 5 Apr 2017 20:31:27 +0000

+1 (for both Brian's comment and use of M&O).

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Chuck Anderson
Sent: Wednesday, April 05, 2017 4:13 PM
To: [email-masked]
Subject: Re: [v6ops] Making RDNSS a MUST?

On Thu, Apr 06, 2017 at 08:03:12AM +1200, Brian E Carpenter wrote:
> >> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST 
> >> in routers
> > 
> > 
> > I don't think we should recommend stateless DHCP support in hosts 
> > because it is technically inferior to RDNSS. (For a list of reasons 
> > why, see 
> > https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html , 
> > and also see what James just wrote) Taking a host that is capable of 
> > doing RDNSS and forcing it to also implement a less-capable protocol is a bad tradeoff for that host's users.
> 
> Your argument might be valid against enable-by-default but it 
> certainly isn't valid against (implement & disable-by-default).
> 
> In fact one algorithm for travelling hosts might be that when 
> attaching to a new network, if no RDNSS has been received after N 
> seconds, then try stateless DHCPv6. That seems like a decent tradeoff for the host's users.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 5 Apr 2017 22:24:47 +0100

Ted Lemon <[email-masked]> wrote:

> ... and, by the way, you are _insane_ if you trust the DHCP server to tell you what NTP server to talk to, but that's a side issue

Vs trusting some random device broadcasting a claim that it's a legitimate router on the network ?

> Specifically, consider the case where 2 RAs are sent on the network each with different PIOs, RIOs, and RDNSS sets.  End nodes can associate all this information with each next hop, and make better…

One thing that slightly concerns me is all this determination to put decisions into the device, rather than the network. In effect, fundamental decisions are made by <any old device> which may well be a device which the network admin has zero control over.

> discovery mechanism to find a resolver or do full-recursion w/DNSSEC

That's a good question. Not even private DNS zones answers that one - a host wouldn't know which interface it needed to use until it knows the IP address of the destination and look it up in the routing table. And it won't know the IP address until it's done the DNS query.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 14:34:24 -0700

> Vs trusting some random device broadcasting a claim that it's a legitimate router on the network ?

The difference is that an evil NTP server can expose you to attack.   A random device broadcasting on the network exposes you to denial of service or snooping/in-path attacks which, one hopes, your device is hardened against.   If it's not, working on that should be your priority.

> One thing that slightly concerns me is all this determination to put decisions into the device, rather than the network. In effect, fundamental decisions are made by <any old device> which may well…

The service on a particular link does not know the set of all links to which a device may be connected, and has no basis for telling that device how to behave.   While decisions made by <any old device> may not be ideal, they are much more likely to be correct than decisions made by the network, which is often attacking <any old device> in some way (e.g., captive portals).

---

From: Mark Smith <[email-masked]>
Date: Thu, 6 Apr 2017 07:49:52 +1000

> connectivity to the Internet*.

So then I'd say I don't understand how a host with basic connectivity
to the Internet with an unset real time clock is that all that useful.

Devices like this Chromebook are getting their time by having
hardcoded, Internet located NTP server addresses in their firmware.
There are potential trust, privacy and reliability issues with that
sort of model.

I think this would be a model that is encouraged by only requiring
RDNSS support.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 10:02:43 +1200

> Even better than that is just use the M & O bits to signal DHCPv6.

To make that watertight, the formal meaning of O would need to change:

OLD:
      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.

NEW:
      O              1-bit "Other configuration" flag.  When set, it
                     indicates that DNS server information is available
                     via DHCPv6. Configuration information on other
                     servers within the network MAY be included. 

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 15:04:40 -0700

On Apr 5, 2017, at 2:49 PM, Mark Smith <[email-masked]> wrote:\
> There are potential trust, privacy and reliability issues with that

It's probably got a domain name, not an IP address, encoded.   And it might even have a pre-shared key, although that's not ideal.   And it probably has an RTC with a battery, so that it can reject really weird values, closing the window of opportunity for replay of compromised keys quite substantially.

So in practice, all it needs in order to use the network is a working default route and a pair of working DNS resolvers.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Apr 2017 10:17:01 +1200

> to the Internet with an unset real time clock is that all that useful.

It depends what its job is. I don't care to generalise.

> There are potential trust, privacy and reliability issues with that

That is indeed a terrible model. Another well-known O/S has used an
FQDN with a sensible choice of servers for many years now.

> I think this would be a model that is encouraged by only requiring

I take the view that things like this, although fundamental, are
applications and should start with name resolution.

    Brian

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Apr 2017 08:40:49 +1000

I take a consumerist view, and I only contribute in that sense: I use
devices which move between underlying substrates and I want them to
work. Thats a common expectation. It reflects badly on BOTH client and
server implementor when I'm wedged because of decisions to not
implement in an A/B choice world. I understand that HAVING an A/B
choice was a 'wrong move' but post deployment, if you have one, you
have to live in one.

So I tend to a view that clients should be able to use the expected
configuration techniques, which is tending to 'implement the minimum
necessary sat of ALL of them" but I acknowledge that goes to 'which
applies, what ranking, if both are seen'. And, it goes to a lack of
control I have as a consumer: my purchase decision is made long, long
after the decision is baked in. In effect, I cannot enforce what I
require here.

In that context, I am the consumer of other peoples configuration. I
have been on networks with no automatic configuration, of any kind,
where use demands you configure by hand. Thats painful, but its a fact
of life. it also doesn't scale well. I have been on networks where you
are recruited to a VLAN/Switch model which is open access, to complete
migration through a portal and then wind up with a higher view which
then exposes new things, and I can imagine this applying in V6
autoconfig too: initial config in (a) and then subsequent config in
(b)

The idea that operations staff are going to 'obey' a directive as a
fiat statement isn't credible btw: I've met these people, and given an
ability to take a different path to the one you perceived, they hold
the genes which do this. Yes, thats unfortunate, but its simple
reality as I see it: there is no ACL they will not at some time have
considered on its merits, even ones which make IP (of any version)
untenably bad. And in that sense, venders implement the "tools" they
use to do this. This is not going to change. So, while I tend to
preferring SLAAC/RDNSS/RA worlds, because they appeal to my sense of
the future, I have no doubt there are operators out there who WILL
configure networks which demand DHCPv6 for reasons I cannot constrain.

This to me is the crux: I am going to wind up needing (for some value
of maslow) to get online, behind networks which don't do the "one true
way" and so I would prefer that my client support the worser kind as
well as the better kind, because in this particular prisoners dilemma,
I simply get nothing if I am let by a moral crusader to have only
version (a) code.

ie. much though I hate it, i think client MUST support (a) OR (b) and
server MUST support (a) AND (b) is probably where I head.

Here is why.

Some people here say "I am never going to do both (a) and (b)" which
is a strong statement. It goes to their power of decision, and their
market force.

What it says to me is: "I dare you to make my manager overrule me"
which of course, I cannot do. But I have a strong suspicion market
forces can (and do) override these decisions. Nobody I know wanted DRM
in the W3C standards stream. Here we are. Nobody I know wanted (as a
thing in itself) /64 but.. here we are. Nobody I know wanted v4-v6
transition to take this long, but here we are.

Arguing for purity in these times is a luxury I don't actually think
can be sustained. I suspect its more likely we'll get to deprecation,
which is exactly what happened to a bunch of things in the v4 world.
We don't do TOS bits any more. I expect future standards to deprecate
things, and then we get to a cleaner world.

I listened to the debate about constrained boxes with interest. Most
of the conversations I've had about these boxes tend to say they will
be on an Internet Protocol network, but not actually the public net,
for other reasons. I think the role of protocol standardization in
these cases is very narrow because its about implementation
consequence for private use at volume.  Statements about cellular
handsets don't apply to boxes which are planning for a bill of
materials where memory footprint is a cost constraint. Statements
about cellular network substrates do apply. So I find myself asking if
the HEAD END of these IoT networks actually will have a problem
implementing A and B, and I struggle with that. Which means I can
easily say, an IoT target context can drive to EITHER A or B, because
it can rely on a head end to do either too.  I know that argues
against my prior sense of things, but thats the fundamental
contradiction here: not all devices are alike.

Will all IoT devices wind up running Android? I suspect not. I suspect
that even in that market share, we will have a mix of A and B
configuration choices presented. So I begin to suspect, that the real
requirement is not on the clients, but on the servers. Clients will be
deployed which make a rigorous, memory constrained choice to do only
one form of configuration.

We need servers to do either, if we cannot constrain clients to only do one.

-G

---

From: David Farmer <[email-masked]>
Date: Wed, 5 Apr 2017 17:46:01 -0500

On Wed, Apr 5, 2017 at 10:15 AM, Ted Lemon <[email-masked]> wrote:

> reach maximal effectiveness sooner.
>
>

I'm sorry but here is the issue, there is a fear that a statement only
requiring RDNSS is just intended as an additional political statement
against DHCPv6, which is not really helpful.

In this discussion DHCPv6 proponents started with MUST support DHCPv6 for
both hosts and routers, this was rebuffed by RDNSS proponents. When a
compromise of SHOULD for hosts was just proposed, this too was rebuffed.
This just reinforces the feeling that the real objective here is to create
an additional argument against DHCPv6.

It sounds to me like there is a consensus to require routers to support for
RDNSS, stateless DHCPv6, and DHCPv6 relay. Furthermore, at least to me, it
sounds like there isn't consensus what to say anything about hosts on this
matter.  So, maybe we just don't say anything at all about hosts, and only
say something about routers. It should be noted that requiring all routers
to support the three items above does still move us forward, not as fast as
I think anyone wants, but it moves us forward.

Hosts are allowed to do as they please, support RDNSS, or not, support
DHCPv6, or not, which is what it seems host implementers want. This is not
optimal from an network operator perspective, but it seems like all we have
consensus for.  Furthermore, if DHCPv6 was only a SHOULD for hosts,
operationally we are in the same place anyway. For a network to guarantee
support for all hosts a network operator will have to support both RDNSS
and DHCPv6 on all links, but at least we will eventually have routers that
will support both host configuration protocols.

So, if host implementers want to be obstinate, lets have the router
implementers and network operators move things forward, by adding a
requirement to support RDNSS, stateless DHCPv6, and DHCPv6 relay in all
routers.  Then suggest a configuration option for the router to get the
RDNSS info from a DHCPv6 server on the link or via DHCPv6 Relay, either
with from a DHCPv6-PD request or an additional info request.  At least this
would operationally allow the DHCPv6 server to be the primary source of all
configuration info for a network, even for hosts that only support RDNSS,
if that were operationally desired.

Thanks.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 16:00:07 -0700

On Apr 5, 2017, at 3:46 PM, David Farmer <[email-masked]> wrote:
> In this discussion DHCPv6 proponents started with MUST support DHCPv6 for both hosts and routers, this was rebuffed by RDNSS proponents. When a compromise of SHOULD for hosts was just proposed, this too was rebuffed.  This just reinforces the feeling that the real objective here is to create an additional argument against DHCPv6.

Who cares?   I just want something to be MTI.   Getting DHCPv6 to be MTI requires more work than getting RDNSS to be MTI.   Insisting on "both or neither" means that it has to be done in a single document, and that document probably won't be this document.

I don't get why this is a fear-based argument.   It's simply a fact of how processes work.   If you want to require DHCPv6, you have to say what that means, and that's a new document.   This document is not that document.   So we can certainly say that RDNSS can't be added to _this_ document because DHCPv6 isn't done yet, but that is a _nonsensical_ thing to say.

The only reason to say it is to hold one requirement hostage in hopes that that will force the other.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Apr 2017 01:06:54 +0200

>                     servers within the network MAY be included. 

I think the old meaning is correct. When the O bit is set, a host should
try to get the DHCP options it supports.

In the ideal case, a host receives DNS information from either DHCP or
from RDNSS.

Note that if an important group of devices refuse to support DHCP, you
have to support RDNSS, but the operator may want to provide NTP servers
through DHCP. In that case it doesn't make sense if DHCP also has to 
provide DNS.

In the case a host receives DNS from both we need a merging algorithm. 
I don't have a preference for that. Though to allow DHCP to override 
global settings, it may make sense to have a preference for DHCP.

---

From: David Farmer <[email-masked]>
Date: Wed, 5 Apr 2017 18:16:11 -0500

On Wed, Apr 5, 2017 at 6:00 PM, Ted Lemon <[email-masked]> wrote:

> Who cares?   I just want something to be MTI.   Getting DHCPv6 to be MTI
> requires more work than getting RDNSS to be MTI.   Insisting on "both or
> neither" means that it has to be done in a single document, and that
> document probably won't be this document.
>

I'm just saying what George Michaelson said, in a different way; hosts do
(a) or (b), and routers do (a) and (b).

> I don't get why this is a fear-based argument.   It's simply a fact of how
> processes work.   If you want to require DHCPv6, you have to say what that
> means, and that's a new document.   This document is not that document.
> So we can certainly say that RDNSS can't be added to _this_ document
> because DHCPv6 isn't done yet, but that is a _nonsensical_ thing to say.
>

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 16:20:04 -0700

On Apr 5, 2017, at 4:16 PM, David Farmer <[email-masked]> wrote:
> I'm just saying what George Michaelson said, in a different way; hosts do (a) or (b), and routers do (a) and (b).

Okay.   I'm not objecting to that.   I am asking why it has to all happen at once.   I.e., if we have an opportunity to make (a) MTI right now, should we take it, or should we not?

---

From: David Farmer <[email-masked]>
Date: Wed, 5 Apr 2017 18:57:43 -0500

On Wed, Apr 5, 2017 at 6:20 PM, Ted Lemon <[email-masked]> wrote:

> Okay.   I'm not objecting to that.   I am asking why it has to all happen
> at once.   I.e., if we have an opportunity to make (a) MTI right now,
> should we take it, or should we not?
>

We are working on the document, "Requirements for IPv6
Routers" draft-ali-ipv6rtr-reqs-02, and it I think it would be good to get
this right the first time that why.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 17:05:56 -0700

On Apr 5, 2017, at 4:57 PM, David Farmer <[email-masked]> wrote:
> We are working on the document, "Requirements for IPv6 Routers" draft-ali-ipv6rtr-reqs-02, and it I think it would be good to get this right the first time that why.

Right, understood.  So do you know what text to write to require DHCPv6?

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Apr 2017 10:09:47 +1000

I'd be heading to 'MUST implement, SHOULD be configurable MAY be
turned off by default' type choices.

* it has to be there as a choice, to be able to meet the client
single-implement logic
* it has to be controllable but we don't constrain how that works.
maybe people make burned in decisions
* it doesn't have to be the one which is on at boot.

On Thu, Apr 6, 2017 at 10:05 AM, Ted Lemon <[email-masked]> wrote:
> We are working on the document, "Requirements for IPv6 Routers"
> draft-ali-ipv6rtr-reqs-02, and it I think it would be good to get this right
> the first time that why.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 17:12:41 -0700

> turned off by default' type choices.

This is a specification.   Can you tell me what specific text you would write?   I'm asking because I don't know, so handwaving about MUST and SHOULD is kind of off-topic.   I apologize for continuing to hammer on this, but I think that there may be some misconception that this is just a line of text.   It's not.

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Apr 2017 10:42:10 +1000

You're right.  Do you go further to say that my failure to be able to
write specific test is a strong test its a bad idea?

> b) RFC3736 stateless DHCP support is a SHOULD in hosts and a MUST in routers, noting implementation on IoT and constrained devices may not be realistic [...] but that managed enterprise environments will expect other configuration information beyond RDNSS and DNSSL to be available, so that local services can be used [...] it’s up to the operator to enable it

Tim owns that language not me, but thats what I think I'm heading to support.

Are there words in that, which can meet normative requirements for a
standards document?

-G

On Thu, Apr 6, 2017 at 10:12 AM, Ted Lemon <[email-masked]> wrote:
> This is a specification.   Can you tell me what specific text you would
> write?   I'm asking because I don't know, so handwaving about MUST and
> SHOULD is kind of off-topic.   I apologize for continuing to hammer on this,
> but I think that there may be some misconception that this is just a line of
> text.   It's not.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Apr 2017 18:28:46 -0700

> Are there words in that, which can meet normative requirements for a

No.   In order for it to be a normative requirement, I should in theory be able to know what tests to write to ensure that I am in compliance.   So:

Are routers required to implement a stateless DHCP server?
How is that server configured?
Is it required that the stateless DHCP server be configurable with a different set of RDNSS values than the RA server?
Is it required that the two servers' configurations be the same?
Is it required that the RDNSS server setting be configurable for both DHCP and RA with a single configuration parameter?
What M&O bits should be in the RA?
Should the O bit be set if DHCP service is enabled, or are the two settings independent?
If DHCP relay is supported, and stateless DHCP is supported, does the router relay for stateful requests and answer information requests directly?
Does it do both?
Must the stateless DHCP server support parameters other than RDNSS?

These are just the questions that pop off the top of my head.   The answer for RDNSS/RA is "must support, must be configurable."   That's a lot simpler.

I think that Tim's text is a great statement of intent, but if that were all that were in the document, I don't think we would have made the situation better.

---

From: Mark Smith <[email-masked]>
Date: Thu, 6 Apr 2017 12:54:46 +1000

On 6 April 2017 at 08:04, Ted Lemon <[email-masked]> wrote:
> It's probably got a domain name, not an IP address, encoded.   And it might
> even have a pre-shared key, although that's not ideal.   And it probably has
> an RTC with a battery, so that it can reject really weird values, closing
> the window of opportunity for replay of compromised keys quite
> substantially.
>
> So in practice, all it needs in order to use the network is a working
> default route and a pair of working DNS resolvers.
>

If this is a reasonable or ideal end host approach or model, then I
think RDNSS starts to become unnecessary too. Firmware vendors may as
well embed DNS addresses.

Google already do that with devices like their Chromecast, embedding
8.8.8.8 as the preferred DNS resolver (if that address is unreachable
the Chromecast switches to using the DHCPv4 supplied DNS resolver).
The approach makes sense. If you were a vendor of these sorts of
devices, you want to minimise the possibility of 3rd party's service
impacting the perceived performance of your product - Google wouldn't
want their Chromecast product to look bad because the local CPE or an
upstream ISP has a badly performing DNS resolver.

It seems the following is a recent example of an application using NTP
directly (Snapchat), rather than trusting the local host's clock. This
seems quite odd to go to the effort do, unless there had been enough
cases where the local host's clock wasn't accurate or accurate enough
for the application.

"Recent NTP pool traffic increase"
https://community.ntppool.org/t/recent-ntp-pool-traffic-increase/18

I'm pretty sure Microsoft and Apple too default to their own NTP
servers on their respective desktop OSes.

Perhaps this indicates a trend where host and application
implementations aren't going to trust the local network's services
because if they perform badly or incorrectly they'd make the host or
application look bad in the eyes of the device's non-technical
end-user.

Regards,
Mark.

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Apr 2017 13:30:35 +1000

Sorry Mark, but that feels orthogonal to the matter at hand.

It is true that vendors do this, it is true that large vendors of
closed ecologies do this, it doesn't alter the normative standards
drive to specify what should or should not be done, when systems want
to ask for locally supplied configuration.

So I don't see your comment saying anything material to what a
standards document would say, because the decision not to honour RDNSS
or related definition of local DNS service binding is not going to
appear in a document.

Unless you are seriously proposing text for a third option which goes
to 'or.. if you chose not to do this then ignore all of the above'

-G

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Apr 2017 20:32:11 -0700

> On Apr 5, 2017, at 4:00 PM, Ted Lemon <[email-masked]> wrote:
> 

OK, let me take a virtual hum. The reply-to on this message is [email-masked], in order to not deluge people (and the archive) with "+1" responses. I'll summarize next week; the time to respond is now.

Do we agree to, in some document, make RDNSS and Stateless DHCP "Mandatory to Implement" in the router, with a view to supporting both classes of networks?

Note that in posing the question, I paused a bit. RDNSS has to be in the RA, and therefore in the router that advertises it. Stateless DHCP can be in any system as long as folks can figure out who to ask. Stateless DHCP is a profile of DHCP, sez the RFC, so I presume that follows the same logic as DHCPv6 itself. I'm asking very specifically whether the *router* has to implement both, or whether if one wants to have stateless DHCP, one could install some other system for that. Very specifically, *what* is mandatory for *whom* to implement?

Four possible answers: 
(1) RDNSS and Stateless DHCP are both required (SHOULD or MUST) in the router
(2) RDNSS is required (MUST) in the router, and if the network wants stateless DHCP, it could implement a router that implements it, or it could install something else; the router MAY implement a DHCP server, and that server MAY/SHOULD/MUST implement whatever the DHCP documents say it MAY/SHOULD/MUST.
(3) Stateless DHCP (SHOULD or MUST) is required in the router, and if the network wants RDNSS (MAY), it could buy a router that implements it.
(4) The market decides. RDNSS and Stateless DHCP *MAY* be implemented in a router, or stateless DHCP could be implemented in some other system (present state).

Note also that, to me, the question answers itself. But I want the WG's viewpoint.

The next question is "in what document".

https://tools.ietf.org/html/rfc3736
3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for
     IPv6. R. Droms. April 2004. (Format: TXT=18510 bytes) (Status:
     PROPOSED STANDARD) (DOI: 10.17487/RFC3736)

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Apr 2017 20:45:27 -0700

> Who cares?   I just want something to be MTI.   Getting DHCPv6 to be MTI requires more work than getting RDNSS to be MTI.   Insisting on "both or neither" means that it has to be done in a single d…

Let me restate this "virtual hum". Someone replied with a better question, and now I'm asking it, v2. Again, the reply-to on this message is [email-masked], in order to not deluge people (and the archive) with "+1" responses. I'll summarize next week; the time to respond is now.

Do we agree to, in some document, make RDNSS and DHCP Relay "Mandatory to Implement" in the router, with a view to supporting both classes of networks?

Four possible answers: 
(1) RDNSS and DHCP Relay (or a DHCP server) are both required (SHOULD or MUST) in the router
(2) A router MUST implement RDNSS, and MAY implement DHCP Relay or a DHCP server.
(3) A router MUST implement DHCP Relay, and MAY implement RDNSS
(4) The market decides. RDNSS and DHCP (Relay or server) *MAY* be implemented in a router. This is the present state.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Apr 2017 12:55:06 +0900

On Thu, Apr 6, 2017 at 12:32 PM, Fred Baker <[email-masked]>
wrote:

> OK, let me take a virtual hum. The reply-to on this message is
> [email-masked], in order to not deluge people (and the archive)
> with "+1" responses. I'll summarize next week; the time to respond is now.
>

Is calling a poll - particularly one with four options - going to help us
reach rough consensus?

What happened to the original question of "do we have consensus to say that
RDNSS is MTI"? Have the chairs already decided there is no rough consensus
on that?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Apr 2017 13:01:29 +0900

On Thu, Apr 6, 2017 at 12:45 PM, Fred Baker <[email-masked]>
wrote:

> Do we agree to, in some document, make RDNSS and DHCP Relay "Mandatory to
> Implement" in the router, with a view to supporting both classes of
> networks?
>

I'm not sure it makes sense to ask this question in isolation. Suppose we
were to declare rough consensus on #3. We haven't improved things, because
it seems pretty clear to me that we won't get rough consensus on making
DHCPv6 a MUST for hosts, as there is substantial opposition to that from
the host software developers who are directly affected by it.

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Apr 2017 21:08:07 -0700

On Apr 5, 2017, at 9:01 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Thu, Apr 6, 2017 at 12:45 PM, Fred Baker <[email-masked]> wrote:
> I'm not sure it makes sense to ask this question in isolation. Suppose we were to declare rough consensus on #3. We haven't improved things, because it seems pretty clear to me that we won't get rough consensus on making DHCPv6 a MUST for hosts, as there is substantial opposition to that from the host software developers who are directly affected by it.

I'm not particularly in a position to measure that. I might be in a position to measure the operational viewpoint.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Apr 2017 13:12:53 +0900

Would it help if I dug up the objections from host OS developers and
collected them in one place to help you evaluate? If we end up saying that
routers MUST support DHCPv6 and we know that hosts OS developers don't want
that, then will have made things even worse than they actually are.

On Thu, Apr 6, 2017 at 1:08 PM, Fred Baker <[email-masked]> wrote:

> >> Do we agree to, in some document, make RDNSS and DHCP Relay "Mandatory
> to Implement" in the router, with a view to supporting both classes of
> networks?
> >
> > I'm not sure it makes sense to ask this question in isolation. Suppose
> we were to declare rough consensus on #3. We haven't improved things,
> because it seems pretty clear to me that we won't get rough consensus on
> making DHCPv6 a MUST for hosts, as there is substantial opposition to that
> from the host software developers who are directly affected by it.
>
> I'm not particularly in a position to measure that. I might be in a
> position to measure the operational viewpoint.

---

From: Mark Smith <[email-masked]>
Date: Thu, 6 Apr 2017 14:17:29 +1000

> Sorry Mark, but that feels orthogonal to the matter at hand.

Maybe it is to an extent.

Perhaps what it is is showing is that "host" is too general a term to
define even a required minimum of something such as RDNSS.

As the Chromecast example shows, it wouldn't get much value from being
required to implement RDNSS. Google have 2 x IPv4 and 2 x IPv6 public
DNS resolvers, if the CC can't reach any of them, it is probably
useless, and the network needs to be fixed to be able to reach them.
So Google could probably quite reasonably say, we're not going to
implement RDNSS, we're just going to embed our 4 public DNS servers'
addresses in our firmware.

When people in this thread are thinking of a typical "host", what are
they visualising in the mind?

- Traditional desktop PC running MS Windows or MAC OS?
- Smartphone or Tablet?
- A halfway between those two device types like a Chromebook?
- VOD type devices such as Chromecast or Apple TV?
- IOT devices such as AMI smart meter modules?

While there will be some commonality between what services they
require to function, how do they acquire that information might be
different based on both what the device's function is and the
environment where it is most likely used (e.g., BYO smartphone to a
public and private networks (residential or enterprise), or AMI smart
meter only ever connected to a single, fully managed private network.)

I think it would be ideal to define a single minimum, however you
don't really want to be foisting an minimum on a device for which it
won't ever be used.

Regards,
Mark.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Apr 2017 06:52:41 +0000

Hello Lorenzo :

This should certainly be on the table in one place, and I would welcome a draft that would live some time in the WG, as opposed to scattered information in so many emails. It would also be grand to document what can be done (and what’s missing) with ND-only solutions.

I’d also welcome a draft that documents the authors’ view of why and in which environment DHCPv6 should stay. Maybe a more industry-specific current practice, since at the end of the day, we are here to develop technology that people want to use.

I can see stuff to write in the IOT space., where some people use DHCP to ensure that hosts get short addresses that can be compressed statelessly,  a technique that has pros and cons, and maybe alternates, all of which should also be on the table.

Then node makers could decide what to place in their devices depending on the market they address and their role in the network.

Take care,

Pascal

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: jeudi 6 avril 2017 06:13
To: Fred Baker <[email-masked]>
Cc: IPv6 Operations <[email-masked]>; V6ops Chairs <[email-masked]>
Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2

Would it help if I dug up the objections from host OS developers and collected them in one place to help you evaluate? If we end up saying that routers MUST support DHCPv6 and we know that hosts OS developers don't want that, then will have made things even worse than they actually are.

On Thu, Apr 6, 2017 at 1:08 PM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 5, 2017, at 9:01 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Thu, Apr 6, 2017 at 12:45 PM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 6 Apr 2017 10:13:01 +0200 (CEST)

> so clients can just happily continue using the address they have learned

Flash renumbering of an entire LAN to for instance a different ISP and 
different resolvers. Think "fixed line went down, no running on mobile 
backup connectivity".

Yes, you can have your own caching resolver on ULAs to fix that problem, 
but being able to provide new information quickly might be better for some 
scenarios.

---

From: Ola Thoresen <[email-masked]>
Date: Thu, 6 Apr 2017 11:03:29 +0200

>> On Apr 5, 2017, at 2:49 PM, Mark Smith <[email-masked]> wrote:\
(...)
> well embed DNS addresses.

In that case, it would be better if the devices actually implemented 
their own resolvers, and did NOT relay on external resolvers at all.

Of course this would break a lot of cases where the admin is doing 
something "evil" with dns, like split horizons and stuff. And it would 
mean that a lot of firewalls will need to be adjusted.
OTOH, the host could detect that it is on an IPv6-only network, and use 
DNS64 for itself when it needs to connect to v4-only servers.

/Ola (T)

---

From: Richard Hartmann <[email-masked]>
Date: Thu, 6 Apr 2017 11:37:58 +0200

Hi chairs,

disregarding forced realities created by some host platforms, from the
engineering PoV, I see the hum as incomplete.

Are you willing to add a hum for:
(5) Hosts MUST implement both RDNSS and Stateless DHCP; routers MUST
implement one or the other and SHOULD implement both.

Hosts are moving from network to network, not the other way round.
They should be able to interoperate with the widest possible set of
network realities they encounter.

Richard

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Apr 2017 12:15:54 +0200

>that, then will have made things even worse than they actually are.

I think that would be helpful. Because it is my impression that of the
objections against DHCP very little has to do with code actually running
on a host os and a lot is telling operators how they should run their 
networks.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 6 Apr 2017 12:46:35 +0200

* Fred Baker <[email-masked]>

> (1) RDNSS and DHCP Relay (or a DHCP server) are both required (SHOULD

*hum*

Tore

---

From: Tore Anderson <[email-masked]>
Date: Thu, 6 Apr 2017 13:08:56 +0200

* Lorenzo Colitti <[email-masked]>

> that, then will have made things even worse than they actually are.

Keep in mind that there more to a host than the operating system, the
firmware is another important piece of the puzzle.

UEFI, in particular, is all about DHCPv6. It was added to the UEFI spec
all the way back in 2010 (in revision 2.3D), yet there is no shortage
of devices that are shipping today with firmware that implements older
revisions without any IPv6 support. The manufacturers move very slowly.

Furthermore, to the best of my knowledge, there's no functionality
equivalent to RFC5970 found in ICMPv6 ND today.

So if you want to build a network today without any DHCPv6, you won't
be able to provision devices until someone writes and publishes
RFC5970-for-ND, UEFI spins a new revision with that spec added, and the
device manufacturers starts shipping updated firmware that impements
that new UEFI revision. We're talking at least a decade here.

So from a completely practical standpoint, DHCPv6 is for me a
MUST. Not because I have any particular fondness for it, find myself in
the «DHCPv6 camp» (or the «RDNSS camp» for that matter), but it is the
only protocol that provides an absolutely essential tool.

So even if I considered myself a die-hard RDNSS fanboy and DHCPv6
hater, I still need DHCPv6 to get my job done. Apart from IPv4, there
exists no alternative. Thus, DHCPv6 is mandatory. C'est la vie.

Tore

---

From: Timothy Winters <[email-masked]>
Date: Thu, 6 Apr 2017 07:17:37 -0400

I also prefer option 1 as it leads to the most Interoperable solutions for
going forward but also legacy devices.

~Tim

--

---

From: Erik Kline <[email-masked]>
Date: Thu, 6 Apr 2017 21:25:45 +0900

As a vendor of a device that is sometimes a router I am opposed to, and
have precisely zero interesting in, implementing a DHCPv6 relay or server
function.  It adds nothing, and can actually break clients that prefer
DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes.​

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Apr 2017 14:52:50 +0200

>DHCPv6 DNS over RDNSS when the upstream IPv6 prefix changes.

Wow, I seldomly see such a user hostile attitude.

Suppose that I as a user of such a device want to pass a NTP, or a PXE boot
option to a downstream device that supports those options.

Great that you are telling me that you see no value in that.

---

From: David Farmer <[email-masked]>
Date: Thu, 6 Apr 2017 07:57:45 -0500

Lorenzo,

Unfortunately, I don't think there is any consensus to be had about hosts.
You have made it perfectly clear that you and others can not accept any
requirement for hosts to do DHCPv6 in any way (SHOULD or MUST).  And,
others are equally adamant that hosts have to be required (SHOULD or MUST)
to do DHCPv6 to move a RDNSS requirement for hosts forward.  I believe we
have an impasse on the subject, and having the two sides yell at each other
on the mailing list gets us no where.

As for routers; It's clear we need routers that support RDNSS to support
the hosts you and others are making.  Then, until you have convinced all
host OS vendors to remove DHCPv6 support, and the old hosts are all gone,
we need routers that also support DHCPv6.  There seems to be a consensus
that routers need support for RDNSS, at least DHCPv6 Relay (probably a
MUST), and Stateless DHCPv6 (probably a SHOULD).  It's just that simple
from an operational perspective that draft-ali-ipv6rtr-reqs-02 has.

Thanks.

---

From: Erik Kline <[email-masked]>
Date: Thu, 6 Apr 2017 21:59:14 +0900

> Great that you are telling me that you see no value in that.
That is correct: I see no value in supporting PXE booting from behind an
Android device in tethering mode.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 6 Apr 2017 13:12:39 +0000

+1 on 1.

I think for routers it is MUST for both. For DHCP, I’m talking about general purpose routers and not limited functionality routers (i.e., those that might be used for tethering – those could get by with RDNSS).

I think for hosts it should be MUST support RDNSS and SHOULD support (at least stateless) DHCPv6.

-          Bernie

From: v6ops [mailto:[email-masked]] On Behalf Of Timothy Winters
Sent: Thursday, April 06, 2017 7:18 AM
To: Tore Anderson <[email-masked]>
Cc: IPv6 Operations <[email-masked]>; V6ops Chairs <[email-masked]>
Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2

I also prefer option 1 as it leads to the most Interoperable solutions for going forward but also legacy devices.

~Tim

On Thu, Apr 6, 2017 at 6:46 AM, Tore Anderson <[email-masked]<mailto:[email-masked]>> wrote:
* Fred Baker <[email-masked]<mailto:[email-masked]>>

*hum*

Tore

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

--

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Apr 2017 01:35:04 +1200

> try to get the DHCP options it supports.

Why bother to look at that flag at all? It's so vaguely defined that
it could mean anything. Just try DHCP anyway - the worst that can happen
is nothing.

    Brian
 
> .

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Apr 2017 15:45:12 +0200

>it could mean anything. Just try DHCP anyway - the worst that can happen

For one, there is a difference between stateful and stateless DHCP requests.

In networks where multicast is expensive, it is not a good idea to have
lots of hosts multicast DHCP requests all the time.

For a host it is important to decide how long to wait for a DHCP response.
If the O flag is clear, the host can continue booting right after receiving
an RA. If the O flag is set, the host should probably wait a couple of retries.

(Some hosts are more advanced than others. Some hosts may continues booting
as soon as one DNS resolver is found. Others execute a number of steps and
then move on)

---

From: Ola Thoresen <[email-masked]>
Date: Thu, 6 Apr 2017 15:58:25 +0200

> as soon as one DNS resolver is found. Others execute a number of steps and

A related issue I just discovered while doing some tests is that 
NetworkManager - at least in Fedora 25 - will not start (nor stop) 
sending DHCP-requests if the flags changes after it has first received 
an RA.
So if the first RA it receives have O=M=0, it will never start sending 
DHCP-Solicits, even if a later RA has O or M=1
And also, if it has received a RA with O/M=1 and have gotten an 
DHCP-lease, it will continue to renew this, even if you later remove the 
O/M-flags from the RA-packets.

I am not sure the behaviour in this case (where the flags are changed) 
is defined in any RFCs?
Also, I am not sure how a host would behave if there were multiple 
sources of RAs, and some had O/M=1 and others had O/M=0.

Rgds.

Ola Thoresen

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 6 Apr 2017 14:12:58 +0000

Hi Erik,

> As a vendor of a device that is sometimes a router I am opposed to, and have precisely zero interesting in, 
> implementing a DHCPv6 relay or server function.  It adds nothing, and can actually break clients that prefer 

I was having a little trouble parsing this, and just wanted to make sure I understood you correctly.
1. You are opposed to implementing a DHCPv6 relay or server function in these devices' router function, but it is not "a router I am opposed to". I admit to misreading this the first few times (thinking you were opposed to the device sometimes being a router), so I thought I'd ask to make sure. From experience, I know that whenever I misread such statements, I'm never alone. I'm just not afraid to ask.

2. You say you don't want to break clients (hosts) that prefer DHCPv6 DNS over RDNSS. Since you oppose DHCPv6 relay or server (in the absence of a qualifier I take server to mean stateful or stateless -- so you oppose both types of server?), does this mean you believe the way to prevent breakage is to only offer RDNSS to clients (so their preference is irrelevant, and they had better also implement RDNSS in spite of their preference)? Or is it just stateful server that you oppose? If just opposed to just stateful server, are you in favor of stateless support in routers that don't do stateful, in order to support possible clients that only request DNS by DHCPv6 stateless?

No agenda; just trying not to misunderstand ...
Barbara

---

From: 神明達哉 <[email-masked]>
Date: Thu, 6 Apr 2017 08:09:37 -0700

At Wed, 5 Apr 2017 20:45:27 -0700,
Fred Baker <[email-masked]> wrote:

> > Who cares?   I just want something to be MTI.   Getting DHCPv6 to
> > be MTI requires more work than getting RDNSS to be MTI.
> > Insisting on "both or neither" means that it has to be done in a
> > single document, and that document probably won't be this
> > document.

> Do we agree to, in some document, make RDNSS and DHCP Relay
> "Mandatory to Implement" in the router, with a view to supporting
> both classes of networks?
>
> Four possible answers:

I don't see the point of answer #2 and #3 in this context.  I thought
the main purpose of this MTI discussion is to guarantee an
implementation situation where any combination of hosts and routers
(and DHCPv6 servers if DHCPv6 is used) can work as long as these nodes
are configured as such, or just say nothing about this topic.  In that
sense #2 and #3 don't help since some host implementations don't
support RDNSS and some other host implementations don't support
DHCPv6.  If we want to include these choices, don't these have to come
with a requirement to host implementations?  That is:

(2') A router MUST implement RDNSS, and MAY implement DHCP Relay or a
     DHCP server.  A host MUST implement RDNSS, and MAY implement
     stateless DHCPv6.
(3') A router MUST implement DHCP Relay, and MAY implement RDNSS.  A
     host MUST implement stateless DHCPv6, and MAY implement RDNSS.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 00:35:28 +0900

On Fri, Apr 7, 2017 at 12:09 AM, 神明達哉 <[email-masked]> wrote:

> > (4) The market decides. RDNSS and DHCP (Relay or server) *MAY* be
> implemented in a router. This is the present state.
>

Right. Specifying only one side of the equation won't solve the
interoperability problem. Which is why I said earlier that there's no point
trying to answer the router question without considering the host question.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Apr 2017 17:47:01 +0200

Le 05/04/2017 à 16:15, Erik Kline a écrit :
>> I would add that supporting 3736 as Relay Agent.   I'm guessing
>> that many routers will just use the relay function to send the DHCP
>> messages to a central server.
>
> Yes, indeed.
>
> emails ago; a clear model for hosts and routers, but adding
> qualifications for the SHOULD. I think my MUSTs and SHOULDs are the
> same as he proposed.
>
> Tim
>
>
> We shouldn't pretend, though, that DHCPv6 DNS and RA DNS are the
> same and the choice is between two equal things.
>
> Specifically, consider the case where 2 RAs are sent on the network
> each with different PIOs, RIOs, and RDNSS sets.  End nodes can
> associate all this information with each next hop,

I am not sure how precisely this works (associate DNS resolver with a
next hop).  Or maybe it is the rt table lookup that make it sound so.
I will have to look.

> and make better, logically consistent use of essentially two
> different networks a la RFCs 7556 and 8028.
>

Err- resolv.conf associates a domain name to a resolver IP address.  A 
smartphone with WiFi and cellular gets a different domain name per 
interface.  (true - some clients over-write resolv.conf, instead of 
appending to it, but that's another matter).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Apr 2017 17:49:59 +0200

> some idea of the status here would be interesting.

There is this PIO-X proposal over in 6MAN.  PIO-X is almost Prefix 
Delegation in ND messaging.

I disagree with it, but there it is.

Alex

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 6 Apr 2017 12:03:04 -0400

> trying to answer the router question without considering the host question.

Given that you have said that gaining rough consensus on host behavior
is unlikely, does this mean you are for option (4), do nothing?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 6 Apr 2017 16:04:53 +0000

> you *one* address.

Just for you information:

If a host wanted 3 addresses, it can just include 3 IA_NAs in the Solicit/Request.

DHCPv6 allows a host to get many addresses, not just 1.

Note: A DHCPv6 server might actually return more than one address for a single IA_NA instance, but that depends on the server's policy (configuration).

And, I think those not in favor of DHCPv6 would argue a few other points.

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Thursday, April 06, 2017 11:50 AM
To: [email-masked]
Subject: Re: [v6ops] Making RDNSS a MUST?

Le 05/04/2017 à 16:46, [email-masked] a écrit :
>> routers; it's not a significant implementation or running cost to any 
>> routers, noting implementation on IoT and constrained devices may not 
>> be realistic (noting Owen's posted figures), but that managed 
>> enterprise environments will expect other configuration information 
>> beyond RDNSS and DNSSL to be available, so that local services can be 
>> used (rather than, say, Google DNS or time servers).  Again, it's up 
>> to the operator to enable it
>

There is this PIO-X proposal over in 6MAN.  PIO-X is almost Prefix Delegation in ND messaging.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 01:06:44 +0900

> is unlikely, does this mean you are for option (4), do nothing?

I didn't say that. I said that gaining rough consensus on saying that
DHCPv6 is a MUST for hosts seems unlikely. I'm still not sure that we can't
reach rough consensus to say RDNSS is a MUST for hosts.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Apr 2017 18:07:48 +0200

Le 06/04/2017 à 00:04, Ted Lemon a écrit :
> On Apr 5, 2017, at 2:49 PM, Mark Smith <[email-masked]
> <mailto:[email-masked]>> wrote:\
> It's probably got a domain name, not an IP address, encoded.   And it
> might even have a pre-shared key, although that's not ideal.   And it
> probably has an RTC with a battery, so that it can reject really weird
> values, closing the window of opportunity for replay of compromised keys
> quite substantially.
>

No no, I disagree.

NTP timeservers change: some disappear. (so until DNS gets updated with 
that there is a risk).

Batteries get depleted.  Cheap CR2032 on BIOS lasts shorter than 
high-quality.  Car 12V battery in the cold, or even the powerful 
batteries of electrical cars are all risking depletion under certain 
conditions.

Some times even a daylight savings time change can disrupt (think server 
in a country not consdiering DST like S Korea and client in  a country 
considering DST, like, well, let's say, Argentina).

Some IP protocols break when the ends have too disparate times.

I went through a few emergencies because of each of these.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Apr 2017 18:13:58 +0200

(1)

---

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

On Thu, Apr 6, 2017 at 11:12 PM, STARK, BARBARA H <[email-masked]> wrote:

> have precisely zero interesting in,
> 2. You say you don't want to break clients (hosts) that prefer DHCPv6 DNS
> over RDNSS. Since you oppose DHCPv6 relay or server (in the absence of a
> qualifier I take server to mean stateful or stateless -- so you oppose both
> types of server?), does this mean you believe the way to prevent breakage
> is to only offer RDNSS to clients (so their preference is irrelevant, and
> they had better also implement RDNSS in spite of their preference)?

I think this is the sort of thing that Erik opposes. I thought I had sent
it to the list, but actually it was an off-list reply.

====
The Android phone in my pocket is a router when I go to the coffee shop
every morning and turn on tethering. As the maintainer of that code, I
absolutely do not want to spend software engineering time writing a DHCPv6
server that is not only less capable than the RDNSS implementation that we
have now, but also degrades functionality.

The reason it is degrades functionality is that with stateless DHCPv6 it is
impossible to implement even such basic things as "tell the client that its
DNS server is now gone because the cellular network went down and came back
up with a different prefix when you temporarily lost cell coverage". This
works today using RDNSS, but if we implement DHCPv6, this will stop working
for clients that support DHCPv6, even if they also support RDNSS.

   1. Client gets DNS addresses from both RDNSS and DHCPv6, and prefers
   DHCPv6 due to RFC 8106.
   2. Upstream goes down. We deprecate the prefix (we can't make it invalid
   because of the 2-hour rule), and declare the DNS servers invalid. We can't
   do anything about DHCPv6.
   3. The upstream comes back with a new prefix. We announce the new DNS
   servers using RDNSS. But the client still uses the out-of-date
   DHCPv6-provided DNS servers, because RFC 8106 says it should prefer DHCPv6
   over RDNSS.

I cannot live with breaking user experience like this.
====

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Apr 2017 18:28:03 +0200

Le 06/04/2017 à 18:19, Lorenzo Colitti a écrit :
[...]
> The Android phone in my pocket is a router when I go to the coffee
> shop every morning and turn on tethering.

Tethering?  Which standard is that?

> As the maintainer of that code, I absolutely do not want to spend
> software engineering time writing a DHCPv6 server that is not only
> less capable than the RDNSS implementation that we have now, but also
> degrades functionality.

Please ask the maintainer of that code which standard is s/he using for 
tethering, before we can discuss DNS-in-RA or -in-DHCP.

Alex

> The reason it is degrades functionality is that with stateless DHCPv6
> it is impossible to implement even such basic things as "tell the
> client that its DNS server is now gone because the cellular network
> went down and came back up with a different prefix when you
> temporarily lost cell coverage". This works today using RDNSS, but if
> we implement DHCPv6, this will stop working for clients that support
> DHCPv6, even if they also support RDNSS.
>
> DHCPv6 due to RFC 8106. 2. Upstream goes down. We deprecate the
> prefix (we can't make it invalid because of the 2-hour rule), and
> declare the DNS servers invalid. We can't do anything about DHCPv6.
> 3. The upstream comes back with a new prefix. We announce the new
> DNS servers using RDNSS. But the client still uses the out-of-date
> DHCPv6-provided DNS servers, because RFC 8106 says it should prefer
> DHCPv6 over RDNSS.
>
> I cannot live with breaking user experience like this. ====
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 6 Apr 2017 16:30:57 +0000

The reason it is degrades functionality is that with stateless DHCPv6 it is impossible to implement even such basic things as "tell the client that its DNS server is now gone because the cellular network went down and came back up with a different prefix when you temporarily lost cell coverage". This works today using RDNSS, but if we implement DHCPv6, this will stop working for clients that support DHCPv6, even if they also support RDNSS.

This is bogus. In this case the client is supposed to initiate DHCPv6 to discover new information. Yes, RFC 3315/3736 was not as clear as it could have been about this but that isn’t completely fair comparison because these were written a long time ago and the networking world was different back then.

RFC 3736 states:

   RFC 3315<https://tools.ietf.org/html/rfc3315> also does not provide any guidance about when a host might
   use an Information-request message to obtain updated configuration
   parameters when the host has moved to a new link.  The DHC WG is
   reviewing a related document, "Detection of Network Attachment (DNA)
   in IPv4" [8<https://tools.ietf.org/html/rfc3736#ref-8>], which describes how a host using IPv4 can determine
   when to use DHCPv4.  Either the DHC WG or a WG formed from the DNA
   BOF will undertake development of a similar document for IPv6.

But if a host detects that things may have changed (such as when a link goes down), it would be rather silly of it not to perform an update of its DHCP information.

https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-07 has:
18.2<https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-07#section-18.2>.  Client Behavior
   A client uses the Solicit message to discover DHCP servers configured
   to assign leases or return other configuration parameters on the link
   to which the client is attached.

   A client uses Request, Renew, Rebind, Release and Decline messages
   during the normal life cycle of addresses and delegated prefixes.
   When a client detects it may have moved to a new link, it uses
   Confirm if it only has addresses and Rebind if it has delegated
   prefixes (and addresses).  It uses Information-request messages when
   it needs configuration information but no addresses and no prefixes.

Perhaps we should be a bit more clear about all of the conditions in this text. The text about Confirm has a more extensive list:

18.2.3<https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-07#section-18.2.3>.  Creation and Transmission of Confirm Messages

   Whenever a client may have moved to a new link, the prefixes/

   addresses assigned to the interfaces on that link may no longer be

   appropriate for the link to which the client is attached.  Examples

   of times when a client may have moved to a new link include:

   o  The client reboots (and has stable storage and persisted DHCP

      state).

   o  The client is reconnected to a link on which it has obtained

      leases.

   o  The client returns from sleep mode.

   o  The client changes access points (such as if using a wireless

      technology).

-          Bernie

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Thursday, April 06, 2017 12:19 PM
To: STARK, BARBARA H <[email-masked]>
Cc: IPv6 Operations <[email-masked]>; Tore Anderson <[email-masked]>
Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2

[...]

2. You say you don't want to break clients (hosts) that prefer DHCPv6 DNS over RDNSS. Since you oppose DHCPv6 relay or server (in the absence of a qualifier I take server to mean stateful or stateless -- so you oppose both types of server?), does this mean you believe the way to prevent breakage is to only offer RDNSS to clients (so their preference is irrelevant, and they had better also implement RDNSS in spite of their preference)?

I think this is the sort of thing that Erik opposes. I thought I had sent it to the list, but actually it was an off-list reply.

====
The Android phone in my pocket is a router when I go to the coffee shop every morning and turn on tethering. As the maintainer of that code, I absolutely do not want to spend software engineering time writing a DHCPv6 server that is not only less capable than the RDNSS implementation that we have now, but also degrades functionality.

The reason it is degrades functionality is that with stateless DHCPv6 it is impossible to implement even such basic things as "tell the client that its DNS server is now gone because the cellular network went down and came back up with a different prefix when you temporarily lost cell coverage". This works today using RDNSS, but if we implement DHCPv6, this will stop working for clients that support DHCPv6, even if they also support RDNSS.
1.       Client gets DNS addresses from both RDNSS and DHCPv6, and prefers DHCPv6 due to RFC 8106.
2.       Upstream goes down. We deprecate the prefix (we can't make it invalid because of the 2-hour rule), and declare the DNS servers invalid. We can't do anything about DHCPv6.
3.       The upstream comes back with a new prefix. We announce the new DNS servers using RDNSS. But the client still uses the out-of-date DHCPv6-provided DNS servers, because RFC 8106 says it should prefer DHCPv6 over RDNSS.
I cannot live with breaking user experience like this.
====

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Apr 2017 09:33:46 -0700

> I went through a few emergencies because of each of these.

Really?   You went through emergencies because you couldn't reach an NTP server because it was hard-coded as a domain name?   You went through emergencies because your BIOS battery failed?   And you think that the solution to these emergencies is to mandate some additional network protocol?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 01:34:39 +0900

On Fri, Apr 7, 2017 at 1:30 AM, Bernie Volz (volz) <[email-masked]> wrote:

> The reason it is degrades functionality is that with stateless DHCPv6 it
> is impossible to implement even such basic things as "tell the client that
> its DNS server is now gone because the cellular network went down and came
> back up with a different prefix when you temporarily lost cell coverage".
> This works today using RDNSS, but if we implement DHCPv6, this will stop
> working for clients that support DHCPv6, even if they also support RDNSS.
>
>
>
> This is bogus. In this case the client is supposed to initiate DHCPv6 to
> discover new information. Yes, RFC 3315/3736 was not as clear as it could
> have been about this but that isn’t completely fair comparison because
> these were written a long time ago and the networking world was different
> back then.
>

Please explain how the host would know that it needs to run DHCPv6 again.

> But if a host detects that things may have changed (such as when a link
> goes down), it would be rather silly of it not to perform an update of its
> DHCP information.
>

The link did not go down. The upstream was renumbered. None of the
conditions in 3315bis 18.2.3 occurred.

Please don't tell me that the client needs to react to the RA with the new
DNS servers by starting DHCP to request DNS servers. :-)

---

From: Tore Anderson <[email-masked]>
Date: Thu, 6 Apr 2017 18:38:00 +0200

* Erik Kline

> As a vendor of a device that is sometimes a router I am opposed to,
> and have precisely zero interesting in, implementing a DHCPv6 relay
> or server function.  It adds nothing

Um, «adds nothing», really?

To the best of my knowledge, DHCPv6 is the *only* way to provision IPv6
name servers onto hosts running Microsoft Windows.

In my operational reality, «support for Microsoft Windows hosts» is
diametrically opposite to «nothing».

The exact same point goes for Android and RDNSS.

Thus, when operating a BYOD IPv6 network, it is absolutely essential to
support *both* RDNSS and DHCPv6. Otherwise you'll be excluding a
significant amount of devices from being able to use your network.

Tore

PS: Apologies to the WG and the chairs for the misdirected hum to the
list a couple of messages earlier in the thread. It appears my MUA
didn't interpret the Reply-To header as I thought it would. My bad.

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Apr 2017 09:38:13 -0700

> Tethering?  Which standard is that?

I believe that he is referring to RFC 7278, and by extension:

https://tools.ietf.org/html/rfc6459
6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet
     System (EPS). J. Korhonen, Ed., J. Soininen, B. Patil, T.
     Savolainen, G. Bajko, K. Iisakkila. January 2012. (Format: TXT=84769
     bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6459)

https://tools.ietf.org/html/rfc7278
7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership
     Project (3GPP) Mobile Interface to a LAN Link. C. Byrne, D. Drown,
     A. Vizdal. June 2014. (Format: TXT=19965 bytes) (Status:
     INFORMATIONAL) (DOI: 10.17487/RFC7278)

https://tools.ietf.org/html/rfc7934
7934 Host Address Availability Recommendations. L. Colitti, V. Cerf, S.
     Cheshire, D. Schinazi. July 2016. (Format: TXT=37124 bytes) (Also
     BCP0204) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7934)

   o  Extending the network (e.g., "tethering").

   o  /64 sharing [RFC7278].  When the topology supports it, this is a
      way to provide IPv6 tethering without needing to wait for network
      operators to deploy DHCPv6 Prefix Delegation (PD), which is only
      available in 3GPP release 10 or above ([RFC6459], Section 5.3).

   o  DHCPv6 Prefix Delegation (PD) [RFC3633].  DHCPv6 PD allows the
      client to request and be delegated a prefix, from which it can
      autonomously form other addresses.  If the prefix is shorter than
      /64, it can be divided into multiple subnets that can be further
      delegated to downstream clients.  If the prefix is a /64, it can
      be extended via L2 bridging, Neighbor Discovery (ND) proxying
      [RFC4389], or /64 sharing [RFC7278], but it cannot be further
      subdivided, as a prefix longer than /64 is outside the current
      IPv6 specifications [RFC7421].  While the DHCPv6 Prefix Delegation
      specification [RFC3633] assumes that the DHCPv6 client is a
      router, DHCPv6 PD itself does not require that the client forward
      IPv6 packets not addressed to itself, and thus does not require
      that the client be an IPv6 router as defined in the IPv6
      specification [RFC2460].  Also, in many cases (such as tethering,
      or hosting virtual machines), hosts are already forwarding IPv6
      packets and thus operating as IPv6 routers as defined in the IPv6
      specification [RFC2460].

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 01:42:43 +0900

> name servers onto hosts running Microsoft Windows.

We'll see how long that statement stays true.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 6 Apr 2017 18:48:40 +0200

* Lorenzo Colitti

> > To the best of my knowledge, DHCPv6 is the *only* way to provision
> > IPv6 name servers onto hosts running Microsoft Windows. 
> 

Years, certainly. Decade(s), probably. Keep in mind that Windows XP,
released in 2001, still has a significant install base.

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 01:51:45 +0900

> released in 2001, still has a significant install base.

The question is what will be the situation when we remove support for
DHCPv4. That is a similarly long time horizon.

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Apr 2017 09:52:38 -0700

> On Apr 6, 2017, at 9:42 AM, Lorenzo Colitti <[email-masked]> wrote:
> 

Perhaps you have knowledge that Microsoft plans to change it? I don't. 

I would have to say that a statement made by an operational group in the IETF needs to address the needs of the operators in the group, which I think Tore has pretty succinctly stated (and which fits the data arriving in my in-box; there are a variety of viewpoints, but if I had to call it right now, I would say that the developing consensus is for routers to support both as MTI). If a vendor of a product, however widely used, has an opinion, it's relevant and welcome (having myself been from the vendor side for quite some time), but this is first and foremost about operational viewpoints.

RFC 8106 came out of 6man (https://datatracker.ietf.org/doc/rfc8106/). I might suspect that 6man would consider a draft updating it to reverse its recommendation that DHCPv6 be preferred over RDNSS, although that is for its chairs to say. I think you have presented some very relevant arguments to support the viewpoint.

---

From: Enno Rey <[email-masked]>
Date: Thu, 6 Apr 2017 18:54:44 +0200

> We'll see how long that statement stays true.

I imagine some guys in Redmond mumbling "We'll see how long [Android not supporting DHCPv6] stays true".
Childish stubbornness can be found in various places.

At this occasion let me wholeheartedly thank both involved organizations for your continued support of the operational IPv6 community out here.

Enno

-- 
Enno Rey

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 02:14:58 +0900

On Fri, Apr 7, 2017 at 1:52 AM, Fred Baker <[email-masked]> wrote:

> I would have to say that a statement made by an operational group in the
> IETF needs to address the needs of the operators in the group, which I
> think Tore has pretty succinctly stated (and which fits the data arriving
> in my in-box; there are a variety of viewpoints, but if I had to call it
> right now, I would say that the developing consensus is for routers to
> support both as MTI). If a vendor of a product, however widely used, has an
> opinion, it's relevant and welcome (having myself been from the vendor side
> for quite some time), but this is first and foremost about operational
> viewpoints.
>

Actually, this has nothing to do with a vendors and everything to do with
operations. My position is that as a participant in an operational group I
cannot live with a MUST that will cause this sort of damage.

This problem is in no way limited to a specific vendor or a specific
product, or even to all portable hotspots. It's a problem in any
renumbering situation. A home network has exactly the same problem. Home
routers, today, hand out DNS server addresses using DHCPv6 and RDNSS, and
DHCPv6 provides no way to change those when the network is renumbered. A
small enterprise using draft-ietf-rtgwg-enterprise-pa-multihoming will also
have the same problem.

The fact of the matter is that DHCPv6 is fundamentally unsuited to telling
hosts that things have changed, and as such, *it only works well when
nothing changes*. It works great when you're doing BGP multihoming or in
IPv4 with NAT, but that's pretty much where it stops being effective.

Many of the operators who are advocating for DHCPv6 here say that everyone
uses anycast DNS anyway, and that their DNS servers have not changed for 15
years. That's great in an enterprise network that uses BGP, but the number
of such networks is dwarfed by the number of home networks that *don't* use
anycast DNS and *do* get renumbered. Saying that all those routers MUST
implement DHCPv6, and degrade the ability of those networks to renumber
like this, is fundamentally broken.

RFC 8106 came out of 6man (https://datatracker.ietf.org/doc/rfc8106/). I
> might suspect that 6man would consider a draft updating it to reverse its
> recommendation that DHCPv6 be preferred over RDNSS, although that is for
> its chairs to say. I think you have presented some very relevant arguments
> to support the viewpoint.
>

Changing 8106 won't avoid breakage to existing implementations. If we add
this MUST, then deploying a router that follows this MUST will break the
ability to renumber of existing clients. This is not good operational
practice and we should not do it.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 6 Apr 2017 19:20:38 +0200

* Lorenzo Colitti

> > > > To the best of my knowledge, DHCPv6 is the *only* way to
> > > > provision IPv6 name servers onto hosts running Microsoft
> > > > Windows.
> > >

Precisely. 10 year old Windows Vista was the first release to properly
support IPv6-only networks, yet it's only now that such networks is
starting to become viable (and even that might be an exaggeration).

So in the same way, even if Microsoft should release a new Windows
version with RDNSS support tonight, we should expect that at least 10
more years will need to pass before IPv6-only networks without
stateless DHCPv6 are viable.

We don't have that time.

Tore

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 6 Apr 2017 17:21:17 +0000

> Please don't tell me that the client needs to react to the RA with the new DNS servers by starting DHCP to request DNS servers. :-)

The client would react to the RA having new prefix information – such as that the old prefix was deprecated.

-          Bernie

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, April 06, 2017 12:35 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: STARK, BARBARA H <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2

On Fri, Apr 7, 2017 at 1:30 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
The reason it is degrades functionality is that with stateless DHCPv6 it is impossible to implement even such basic things as "tell the client that its DNS server is now gone because the cellular network went down and came back up with a different prefix when you temporarily lost cell coverage". This works today using RDNSS, but if we implement DHCPv6, this will stop working for clients that support DHCPv6, even if they also support RDNSS.

The link did not go down. The upstream was renumbered. None of the conditions in 3315bis 18.2.3 occurred.

Please don't tell me that the client needs to react to the RA with the new DNS servers by starting DHCP to request DNS servers. :-)

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 02:31:16 +0900

> stateless DHCPv6 are viable.

Your network might not. But the lots of networks do. Home networks, for
example. I'm pretty confident that 10 years from now the majority of home
networks will still provide IPv4. (Perhaps the quality of IPv4 Internet
access will be terrible, but the performance of querying your home gateway
over IPv4 or IPv6 will be the same.) There are countries which have zero
IPv6 deployment, even today. There are product categories like home
entertainment systems or TVs where the majority of devices that don't
support IPv6 at all, never mind IPv6-only.

My point here is that a MUST for routers is too broad. A MUST for
enterprise routers? No objection. Enterprises rarely change their network
configurations, because they use VRRP, DHCPv6 failover, anycast, and a host
of other technologies that we built during decades of IPv4 operation
because hosts couldn't have more than one address at a time and couldn't be
told that something had changed. But a MUST for dynamic networks will cause
operational impact, and that's not acceptable.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 02:37:45 +0900

On Fri, Apr 7, 2017 at 2:21 AM, Bernie Volz (volz) <[email-masked]> wrote:

> > Please don't tell me that the client needs to react to the RA with the
> new DNS servers by starting DHCP to request DNS servers. :-)
>
>
>

Can you cite an implementation that does this, or even a specification that
recommends or requires it?

Even if you can, from a design perspective saying "we use DHCPv6 to
distribute DNS information and the only way to know that that information
needs to be refreshed is to listen for an RA" is absurd, given that putting
the DNS servers in the RA is faster, simpler, and more reliable.

---

From: james woodyatt <[email-masked]>
Date: Thu, 6 Apr 2017 10:59:14 -0700

On Apr 6, 2017, at 09:19, Lorenzo Colitti <[email-masked]> wrote:
> Client gets DNS addresses from both RDNSS and DHCPv6, and prefers DHCPv6 due to RFC 8106.
> Upstream goes down. We deprecate the prefix (we can't make it invalid because of the 2-hour rule), and declare the DNS servers invalid. We can't do anything about DHCPv6.
> The upstream comes back with a new prefix. We announce the new DNS servers using RDNSS. But the client still uses the out-of-date DHCPv6-provided DNS servers, because RFC 8106 says it should prefer DHCPv6 over RDNSS.

It’s technically not required that we break user experience like this. We could add still more onerous requirements to work around the abject brokenness of DHCPv6.

Run a forwarding DNS resolver service in routers. Advertise it to hosts at a ULA in both RA and DHCPv6. Reset the forwarding addresses when the DNS information changes. If it’s a caching server, then be sure to flush the cache when the upstream server addresses change.

There are IPv6 routers in the real world today that do exactly this for precisely this purpose. I know, because I wrote it that way to keep from breaking the experience for Windows users. It caused other damage, but consensus seemed to be that the trade-off was worth it.

Do we love DHCPv6 enough to make standard requirements that keep from breaking user experience? Somehow, I’m not optimistic. We could do it, and if we did, then I’d have no major objection to mandatory DHCPv6 in routers. I don’t expect to see any significant appetite for it.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 6 Apr 2017 18:44:03 +0000

> IETF needs to address the needs of the operators in the group, which I think
> Tore has pretty succinctly stated (and which fits the data arriving in my in-
> box; there are a variety of viewpoints, but if I had to call it right now, I would
> say that the developing consensus is for routers to support both as MTI). If a
> vendor of a product, however widely used, has an opinion, it's relevant and
> welcome (having myself been from the vendor side for quite some time),
> but this is first and foremost about operational viewpoints.

I'd like to share one aspect of my response to v6ops chairs, in response to this. The hum question also asked for thoughts on which document.
What I said about which document was:
 - Leave RFC 7084 alone wrt this. [RFC 7084 already has delivery of DNS by RDNSS and either stateless or stateful DHCPv6 as MTI (MUST) for "CE Routers"; I'm opposed to introducing a DHCPv6 Relay requirement for this class of routers; which doesn't mean they can't or shouldn't implement Relay -- it just means Relay isn't relevant to the purpose of the doc.]
 - Make RDNSS, DHCPv6 Server (stateful), and DHCPv6 Relay MTI (MUST) in the newly adopted draft-ali-ipv6rtr-reqs. I do think that draft needs to be more clearly targeted towards non-mass-market routers (or maybe even just target enterprise, if that's where the big problem is). Many of the requirements are inappropriate for mass market routers (and some should even be recommended against for mass market routers). I'll provide those comments when the next rev comes out.

Note that if we do this, neither document would apply to 3GPP UEs that do tethering.

There is still the separate and completely distinct question about possibly evolving RFC 6434 to make RDNSS a MUST for hosts. Based on my reading of this thread's discussion, I'm leaning more and more towards "Yes" (away from my previous ambivalence, of accepting "Yes" or "do nothing"). 

WRT to the separate and distinct question about evolving RFC 6434 to make DHCPv6 (stateless or stateful) client MTI (MUST) for hosts, I continue to be opposed.
Barbara

---

From: Tore Anderson <[email-masked]>
Date: Thu, 6 Apr 2017 20:55:00 +0200

* Lorenzo Colitti

> networks will still provide IPv4.

Certainly if the expectation is that IPv4 will «always» be there to
save the day, we do not need DHCPv6 (or RDNSS for that matter).

I'd however like to see a solution that works as well as possible today
given what implemtations exist in the wild today, *without* requiring
IPv4.

> (Perhaps the quality of IPv4 Internet access will be terrible, but
> the performance of querying your home gateway over IPv4 or IPv6 will
> be the same.)

[...]

> But a MUST for dynamic networks will cause operational impact, and
> that's not acceptable.

If you're already implementing and pointing the downstream clients at a
resolver cache/proxy in the router, surely you could assign a static
and permanent IPv6 address (a ULA /128 for example) to it to alleviate
any concerns about not being able to update it?

Tore

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Apr 2017 21:01:41 +0200

>    There are IPv6 routers in the real world today that do exactly
>    this for precisely this purpose. I know, because I wrote it that
>    way to keep from breaking the experience for Windows users. It
>    caused other damage, but consensus seemed to be that the trade-off
>    was worth it.
> 
>    Do we love DHCPv6 enough to make standard requirements that keep
>    from breaking user experience? Somehow, Im not optimistic. We
>    could do it, and if we did, then Id have no major objection to
>    mandatory DHCPv6 in routers. I dont expect to see any significant
>    appetite for it.

I managed to quickly create about 8 reasons why Lorenzo's would not
have to be a problem in practice. This is one of them. In order of
appearance I have:

1) A stateless DHCP server doesn't to be enabled by default. Assuming that
   for most hosts it just works (either because of RDNSS or because of IPv4)
   you can just leave disabled until you really need it.
2) Refusing to implement any kind of DHCP does not recognize the fact that
   there is more to DHCP then just DNS.
3) It assumes that the DHCP by default automatically announces the upstream
   DNS resolvers. It would be quite possible to leave that upto the user
   and the user might for example configure Google's public DNS resolvers
   which work anywhere
4) It assumes that the DNS resolvers will stop working after the phone
   gets a different prefix. A mobile telco can just as well configure 
   static addresses that work anywhere in the mobile provider's network.
5) Your point. If we want to support this scenario, just include something
   like dnsmasq. Note that Lorenzo can just do that. There is no RFC that
   prohibits a local DNS resolver in a router.
6) An RA cannot actually withdraw addresses. So when the prefix changes,
   the validity of any addresses configured by downstream hosts is limited to
   two hours, but not actually withdrawn.

   One way around that is to cause a link down event. Obviously, hosts
   should try to reconfigure all resources after a link down event. Also
   the ones they got through DHCP
7) The lifetime can be limited to 10 minutes. Not ideal, but also not a
   disaster is this change happens rarely
8) The DHCP protocol supports reconfigure also for information-requests.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Apr 2017 21:48:24 +0200

Le 06/04/2017 à 18:38, Fred Baker a écrit :
>>> The Android phone in my pocket is a router when I go to the
>>> coffee shop every morning and turn on tethering.
>>
> https://tools.ietf.org/html/rfc6459 6459 IPv6 in 3rd Generation
> Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen,
> Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila.
> January 2012. (Format: TXT=84769 bytes) (Status: INFORMATIONAL) (DOI:
> 10.17487/RFC6459)
>
> https://tools.ietf.org/html/rfc7278 7278 Extending an IPv6 /64 Prefix
> from a Third Generation Partnership Project (3GPP) Mobile Interface
> to a LAN Link. C. Byrne, D. Drown, A. Vizdal. June 2014. (Format:
> TXT=19965 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7278)

If it is so, then I think developper should understand the qualifier
"INFORMATIONAL" next to this RFC7278.

Developper should know from a start that that code doing tethering has
no future, and it is not worth time investing in.

If developper accepts that, then we can talk about the necessity of DHCPv6.

(or otherwise enjoy coffee and forget tethering :-)

Alex

>
> https://tools.ietf.org/html/rfc7934 7934 Host Address Availability
> Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July
> 2016. (Format: TXT=37124 bytes) (Also BCP0204) (Status: BEST CURRENT
> PRACTICE) (DOI: 10.17487/RFC7934)
>
> delegated to downstream clients.  If the prefix is a /64, it can be
> extended via L2 bridging, Neighbor Discovery (ND) proxying [RFC4389],
> or /64 sharing [RFC7278], but it cannot be further subdivided, as a
> prefix longer than /64 is outside the current IPv6 specifications
> [RFC7421].  While the DHCPv6 Prefix Delegation specification
> [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 PD
> itself does not require that the client forward IPv6 packets not
> addressed to itself, and thus does not require that the client be an
> IPv6 router as defined in the IPv6 specification [RFC2460].  Also, in
> many cases (such as tethering, or hosting virtual machines), hosts
> are already forwarding IPv6 packets and thus operating as IPv6
> routers as defined in the IPv6 specification [RFC2460].
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Apr 2017 21:50:29 +0200

> name servers onto hosts running Microsoft Windows.

YEs.  But it has drawbacks, and should be improved.

It lacks a lifetime.  The server is there installed in Windows forever, 
until overwritten.

That makes that after going to IETF meeting and coming back to my 
non-IPv6 office network, my laptop still has a DHCPv6 server configured 
seen with "ipconfig /all".  I dont like that.

Were it to have a lifetime, it would expire.  But no.

I am suggesting to add that lifetime in DHCPv6.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Apr 2017 21:51:05 +0200

Le 06/04/2017 à 18:33, Ted Lemon a écrit :
> On Apr 6, 2017, at 9:07 AM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
> Really?   You went through /emergencies/ because you couldn't reach an
> NTP server because it was hard-coded as a domain name?   You went
> through /emergencies/ because your BIOS battery failed?   And you think
> that the solution to these emergencies is to mandate some additional
> network protocol?

Not that.

In that threaded conversation, my point was that it is good to to rely 
on time offered by a server, but not good to rely on a battery, not good 
to consider time servers are always there.

The solution to avoid that is first to reuse existing protocols to make 
sure time is right at boot up.

Ideally, use just one protocol to configure all these parameters, with 
as few messages as possible.

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 6 Apr 2017 20:02:59 +0000

> I am suggesting to add that lifetime in DHCPv6.

There already is - see https://datatracker.ietf.org/doc/html/rfc4242. It does have a min value of 10 minutes.

I think any lifetime has issues in the fact that if something happens before that lifetime expires, you'll have old data.

The lifetime is good and should be used, but the client also needs to use some knowledge of what's happened to the network to determine whether it should refresh (RFC 3315/3736/ draft-ietf-dhc-rfc3315bis have some conditions, perhaps they are incomplete).

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Thursday, April 06, 2017 3:50 PM
To: [email-masked]
Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2

It lacks a lifetime.  The server is there installed in Windows forever, until overwritten.

That makes that after going to IETF meeting and coming back to my
non-IPv6 office network, my laptop still has a DHCPv6 server configured seen with "ipconfig /all".  I dont like that.

Alex

> Thus, when operating a BYOD IPv6 network, it is absolutely essential 
> to support *both* RDNSS and DHCPv6. Otherwise you'll be excluding a

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Apr 2017 13:07:16 -0700

On Apr 6, 2017, at 12:01 PM, Philip Homburg <[email-masked]> wrote:
> A stateless DHCP server doesn't to be enabled by default.

So you're suggesting that the Settings panel on my Android phone should have a checkbox for "enable DHCPv6?"

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Apr 2017 23:02:13 +0200

>    So you're suggesting that the Settings panel on my Android phone
>    should have a checkbox for "enable DHCPv6?"

As far as I can tell, some people at Google just completely refuse to
implement DHCPv6, so it doesn't matter at all what we propose at this stage
to make it work better.

That said, in the tethering scenario, I don't expect issues, because a mobile
provider is likely to have just a few dns clusters with public addresses.

So in the unlikely event that hardly any hosts need DHCPv6 DNS and there is
also a significant percentage of cases where it breaks, then requiring the
user to enable it manually would be a good idea.

Looking at it from another angle, if you don't have dnsmasq or similar on
your router and you hand out the upstream DNS resolvers through DHCPv4
then you would end up in exactly the same situation as Lorenzo expects to
happen with DHCPv6. (Not) surprisingly, this is not an operational issue.

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Apr 2017 14:06:23 -0700

> On Apr 6, 2017, at 12:50 PM, Alexandre Petrescu <[email-masked]> wrote:
> 

Great suggestion to make to 6man or dhc. Not within the scope of v6ops charter.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Apr 2017 07:12:06 +1000

In message <[email-masked]>
, Lorenzo Colitti writes:
> and

And in doing so breaks any equipement that doesn't yet support RDNSS.

>    2. Upstream goes down. We deprecate the prefix (we can't make it
>    invalid because of the 2-hour rule), and declare the DNS servers
>    invalid. We can't do anything about DHCPv6.

So also bring up a ULA prefix and advertise the phone's address on
the ULA prefix as the validating recursive server and offer this
as well. This is what homenet does to provide stability of local
services in the presence of changing upstream prefixes.

There are lots of ways to solve problems. 

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Apr 2017 09:20:00 +1200

Lorenzo,

On 07/04/2017 05:31, Lorenzo Colitti wrote:
> But a MUST for dynamic networks will cause

I don't understand that statement. I think in essence what Bernie
suggested was: when there's a connectivity change, re-initialize
everything. That seems like normal defensive programming to me,
especially since it seems to be generally believed that RECONFIGURE
isn't much used.

I do agree with your implied goal of making the host stack's
connectivity as robust as possible. And I can see why RDNSS
would be a better bet when both are available. But to not
used stateless DHCPv6 when it's the *only* source of DNS info
seems to me to go against that goal.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Thu, 06 Apr 2017 23:27:03 +0200

> On Apr 6, 2017, at 2:02 PM, Philip Homburg <[email-masked]>
> wrote:
> >
> The attached is from my iPhone when I didn't have a WiFi link
> active. Look at the DNS Server address... and no, the app doesn't
> choose to tell me what *my* GUA or prefix is. I'm sure I have one.
> 
> I don't think there is a requirement that the DNS address be a GUA.
> It needs to be reachable from the systems that use it.

I should have been more careful when I wrote that. It is best
practice for a long time already to make sure that your resolvers are
not accessible outside your own network. With as exception the few
parties that provide globally accessible resolvers.

So if you change providers, then you probably have to change resolvers, 
because even if the address is global, it is probably firewalled.

So to go back to your phone, if that ULA is reachable throughout your 
provider's network, then it is as good as any public address.

I guess the only way to find out is to manually configure this address and
see if it breaks at some point. Or just watch the settings over a period
of time and see if you always get the same ULA.
outside.

---

From: Mark Smith <[email-masked]>
Date: Fri, 7 Apr 2017 08:03:27 +1000

"Tethering" is not a strict networking term. It is just the name that the
telco industry gave to using your phone as a router between the 3G and Wifi
interfaces, because they used to either prohibit it or charge for it.

So don't get caught up on it, all Lorenzo was describing was a use case
where a device is sometimes a host only, and sometimes​ both a host and a
router (sourcing/sinking packets for phone UI apps = host, forwarding
packets for Wifi attached devices = router)

Regards,
Mark.

On 7 Apr. 2017 05:49, "Alexandre Petrescu" <[email-masked]>
wrote:

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Apr 2017 08:37:12 +0200

Le 06/04/2017 à 22:02, Bernie Volz (volz) a écrit :
> I think any lifetime has issues in the fact that if something happens
> before that lifetime expires, you'll have old data.
>
> The lifetime is good and should be used, but the client also needs to
> use some knowledge of what's happened to the network to determine
> whether it should refresh (RFC 3315/3736/ draft-ietf-dhc-rfc3315bis
> have some conditions, perhaps they are incomplete).

So I guess my Windows has a big problem because it keeps that DHCPv6 
server address there forever, even if I only connect to it while at the 
IETF meetings.

Alex

>
> - Bernie
>
> -----Original Message----- From: v6ops
> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu Sent:
> Thursday, April 06, 2017 3:50 PM To: [email-masked] Subject: Re:
> [v6ops] Making RDNSS a MUST?, hum v2
>
>
>
>>> As a vendor of a device that is sometimes a router I am opposed
>>> to, and have precisely zero interesting in, implementing a DHCPv6
>>> relay or server function.  It adds nothing
>>
> non-IPv6 office network, my laptop still has a DHCPv6 server
> configured seen with "ipconfig /all".  I dont like that.
>
>> Thus, when operating a BYOD IPv6 network, it is absolutely
>> essential to support *both* RDNSS and DHCPv6. Otherwise you'll be
>> excluding a significant amount of devices from being able to use
>> your network.
>>
>> Tore
>>
>> PS: Apologies to the WG and the chairs for the misdirected hum to
>> the list a couple of messages earlier in the thread. It appears my
>> MUA didn't interpret the Reply-To header as I thought it would. My
>> bad.
>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 16:04:13 +0900

Philip,

here are the reasons why what you suggest are not desirable. Note that I
use Android as an example here, but most of these reasons are not specific
to Android; I'm mostly just using it as an example of a real product.

>    you can just leave disabled until you really need it.

Consumer devices often don't permit user configuration of this sort of
thing. Such a configuration option would almost certainly not be allowed by
the people who decide which options make it into mass market operating
systems. So MUST implement means MUST turn on default. (Since I'm sure
you're not arguing that the device MUST implement but disable it and not
allow the user to enable it.)

>    there is more to DHCP then just DNS.

In DHCPv4 Android doesn't implement pretty much anything else than what's
in the RA (IP addressing, DNS and MTU) and nobody has ever complained about
that. Lots of people seem to complain about addressing though. I would
deduce that those options aren't really that important for this type of
device.

>    and the user might for example configure Google's public DNS resolvers

It announces the global address of the device so that clients get the
benefit of caching. Believe it or not, this is per carrier requirements.

>    static addresses that work anywhere in the mobile provider's network.

But the product needs to work in the real world, and in the real world,
telcos don't do that.

>    prohibits a local DNS resolver in a router.

That is what it does.

>    two hours, but not actually withdrawn.

You don't need to withdraw addresses. You do need to withdraw DNS servers.
In any case, the problem is not so much withdrawing them as updating them
with new ones when the connection comes back.

>    the ones they got through DHCP

That would disrupt all communications between clients on the hotspot and
make users unhappy.

>    disaster is this change happens rarely

In a real-world product, a 10-minute outage is unacceptable. This does not
necessarily happen rarely. It happens every time you lose cell signal. In
some places that never happens. In some places it happens often. It is not
appropriate to inconvenience those users because other people want to run
DHCPv6 in their network. Given that you're arguing that routers MUST
implement DHCPv6 because "some operators want it", I'm sure you'll be
sympathetic to the fact that other operators (i.e., users) do *not* want it.

> 8) The DHCP protocol supports reconfigure also for information-requests.

Reconfigure requires a DUID and using DUIDs has privacy implications.

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 16:09:07 +0900

> And in doing so breaks any equipement that doesn't yet support RDNSS.

No, it only breaks equipment that does not support RDNSS and doesn't
support DHCPv4. There is no such equipment today, and it will be years or
decades before there is.

> There are lots of ways to solve problems.

Sure. And what benefit would the added complexity of this solution (add ULA
management; write a DHCPv6 server) provide the user? That they can connect
with (nonexistent) equipment that doesn't support IPv4?

---

From: Ola Thoresen <[email-masked]>
Date: Fri, 7 Apr 2017 09:09:34 +0200

On 07. april 2017 00:03, Mark Smith wrote:

> So don't get caught up on it, all Lorenzo was describing was a use 
> case where a device is sometimes a host only, and sometimes​ both a 
> host and a router (sourcing/sinking packets for phone UI apps = host, 
> forwarding packets for Wifi attached devices = router)
>

We need to stop pretending there is a sharp distinction between a router 
and a host.  My mobile phone can be both, my laptop can be both - it 
runs several VMs and some of these are even nested VMs, Any device 
participating in a mesh network of some sort needs to route packets one 
way or another...
What we need to be able to separate is the _role_ some _process_ on a 
device have at the moment.

This means that a lot of devices that in a legacy world are "host only" 
might start running code that turns them into routers.  And _that_ code 
probably needs to support both being a DHCPv6 client AND server, as it 
might need to accommodate PD.   Whether the OS itself should have all 
that code included by default will probably depend on the vendor or 
provider.

In an ideal world, that means that installing e.g. VMWare, KVM and such 
should depend on both a dhcpv6-server and client being installed (or 
bundled) on the host.
And when I turn on tethering on my phone, it should probably also enable 
a dhcpv6-client to get a prefix, and a dhcpv6-server to be able to serve 
clients behind it with prefixes, should they ask for a IA-PD.

This is not an argument to force install or enable DHCPv6 on all 
"clients" by default.  We just need to make sure it is available when 
some software on the device changes its role to a "router".

/Ola (T)

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Apr 2017 16:16:51 +0900

> especially since it seems to be generally believed that RECONFIGURE

Sure. When all clients that we need to serve implement this behaviour, it
will be safe to implement a DHCPv6 server. When that happens, let me know
when that is and I'll remove that particular objection. Until then we have
an operational problem.

Note that if I were such a client I try to avoid ever implementing that
behaviour. Some of the reasons are:

   - Dealing with non-deterministic behaviour during updates due to packet
   reordering or loss
   - Substantial nattery impact of spinning up a radio transmitter to send
   a DHCP request instead of just passively listening to an RA
   - Code complexity

> seems to me to go against that goal.

Remember we're talking about the router side of things here. In this case,
RDNSS is not the only source of DNS info because we also support DHCPv4.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 7 Apr 2017 09:34:21 +0200

Hi,

> would be a better bet when both are available.

I fully agree

> But to not

Having a DHCPv6 client implemented on the client doesn't mean it has to use it for every single option it supports. Maybe use it but only for things that haven't been provisioned in another way. How about:

1: Clients MUST implement both RDNSS and a DHCPv6 client
2: Both SHOULD be enabled by default so they can get connectivity on any network
3: Clients MAY (SHOULD?) choose not to request options over DHCPv6 that they already got through other mechanisms (i.e. RA or statically configured)
4: If a client has all the options it needs then it MAY choose not to do DHCPv6 at all

Or worded the other way around: allow a client to basically do RA-only unless it's missing something and then try to get that through DHCPv6.

This would be a deviation of the current behaviour where clients do SLAAC+RNDSS+DHCPv6 and use/combine all the information it got, but maybe this would be a better way to do it. The client would work on a DHCPv6-only network, but may choose to use only the information in the RA whenever it can. Would this work?

Cheers,
Sander

---

From: Richard Hartmann <[email-masked]>
Date: Fri, 7 Apr 2017 10:48:07 +0200

> This would be a deviation of the current behaviour where clients do SLAAC+RNDSS+DHCPv6 and use/combine all the information it got, but maybe this would be a better way to do it. The client would wo…

/me hums a happy tune.

This is better than what I wrote earlier; and aligns rather well with
"RA for lean, DHCPv6 for feature-rich networks".

Again, the common case is that, if anything moves at all, the host
moves between various networks. Thus it's that part of the whole
system which should work with what it encounters, not the other way
around.

-- 
Richard

---

From: Tore Anderson <[email-masked]>
Date: Fri, 7 Apr 2017 10:52:53 +0200

* Lorenzo Colitti

+1 

> Remember we're talking about the router side of things here. In this
> case, RDNSS is not the only source of DNS info because we also
> support DHCPv4.

You kicked off this thread calling for a MUST for routers to support
RDNSS (I agree with you on that, for what it's worth).

Now you appear to be making the argument that a MUST for DHCPv6¹ is not
warranted because all routers and all hosts support DNS server
discovery over DHCPv4 anyway.

That argument, however, applies 100% against your proposed addition of
a MUST for RDNSS too. You can't have it both ways.

When also considering IPv4 and dual-stack, operational reality today
for a BYOD network operator needing to provision attaching nodes with
DNS servers can be expressed in one of these ways:

1) MUST DHCPv4 OR (MUST RDNSS AND MUST DHCPv6¹)
2) MUST DHCPv4, MAY² RDNSS, MAY² DHCPv6¹

In either case, RDNSS and DHCPv6¹ have the same "MTI level".

Note that this is DHCPv6 fanboyism on my part, I don't particularly
care which tool gets the job done. I would not mind at all if RDNSS got
implemented in ~all hosts, and IFF that actually happens I'd be happy
support a -bis that removed any requirement for DHCPv6. (PIO-X vs
DHCPv6-PD, same thing.)

But that's not (yet) the world we're living in, and IMHO the output of
the IPv6 Operations working group needs to reflect current operational
realities, not wishful thinking about how the world will look five or
ten years from now.

[1] Not considering stateful IA_* stuff
[2] Or SHOULD

Tore

---

From: Philip Homburg <[email-masked]>
Date: Fri, 07 Apr 2017 11:54:27 +0200

>Having a DHCPv6 client implemented on the client doesn't mean it has to 
>use it for every single option it supports. Maybe use it but only for 
>things that haven't been provisioned in another way. How about:
>
>3: Clients MAY (SHOULD?) choose not to request options over DHCPv6 that 
>they already got through other mechanisms (i.e. RA or statically 
>configured)

On thing DHCP can do and RDNSS basically can't is to have per host
configuration. If I want to point my laptop to a test dns resolver cluster
then I can do that with DHCP without impacting anyone else. And if I do
that using DHCP I can take my laptop elsewhere and it will just work.
No need to mess around with any config on the host. Just a change a line in the
DHCP server config.

Of course, this feature will be killed of we specify that RDNSS has a
higher priority.

---

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

> RDNSS (I agree with you on that, for what it's worth).

The reason I called this thread was for hosts, not routers.

> a MUST for RDNSS too. You can't have it both ways.

I think you're misunderstanding my position. There are two arguments here.
The way I see it, a must for DHCPv6 is harmful because DHCPv6 is
technically inferior to RDNSS and thus would lead to regressions in
functionality (for which I have provided examples). A MUST for RDNSS is not
harmful in this way. Therefore, a MUST for RDNSS is a good idea because a)
it's the more capable protocol, and b) it provides a guarantee of
interoperability once old OSes have aged out.

I don't think there's a contradiction there, it's just that you and I have
different goals. You want everything to work everywhere, as soon as
possible, without IPv4, and are willing to accept suboptimal outcomes in
some parts of the network (like the regressions I provided examples of),
even if that would lead to a worse outcome in the long term. That means you
want DHCPv6, because you need Windows to work.

I want to the best outcome in the long term and am willing to wait for it.
That means I don't want DHCPv6, because for as long as IPv4 is around it's
not a necessity.

> care which tool gets the job done.

I can see your point of view. But please do consider the effects on the
long-term flexibility of host configuration in the Internet of encouraging
a protocol (DHCPv6) that is both a) technically inferior to the alternative
and b) familiar to many network operators, some of whom will choose it
because it is familiar or easier and not because it is better. I don't want
us all to be running DHCPv6 20 years from now, because it's suboptimal. I
want us all to be running RDNSS, because it's better.

Like I said, I wouldn't strongly oppose saying that enterprise-class
routers MUST implement DHCPv6. If you're running BGP, VRRP, and DHCPv6
failover, you don't ever need to change anything, so the additional
benefits of RDNSS won't help much.

---

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

> No need to mess around with any config on the host. Just a change a line

That's really not a good reason to require support for DHCPv6 DNS servers.
It's trivial to do what you want by pointing all your hosts at a set of DNS
forwarders and configuring them to talk to different upstreams depending on
who is asking.

It's also much better: you can change things on the fly without waiting for
the host to ask again, and you can even do useful things like send 1% of
host X's DNS queries to the test cluster for canarying purposes.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 07 Apr 2017 13:05:36 +0200

>forwarders and configuring them to talk to different upstreams depending on

Wow, working around the limitations of RA by making changes to a production 
DNS cluster. 

And of course, none of those hosts would ever use privacy extensions.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Apr 2017 13:26:23 +0200

Le 07/04/2017 à 09:09, Ola Thoresen a écrit :
>>  case where a device is sometimes a host only, and sometimes​ both
>> a host and a router (sourcing/sinking packets for phone UI apps =
>> host, forwarding packets for Wifi attached devices = router)
>>
>
> We need to stop pretending there is a sharp distinction between a
> router and a host.  My mobile phone can be both, my laptop can be
> both - it runs several VMs and some of these are even nested VMs,
> Any device participating in a mesh network of some sort needs to
> route packets one way or another... What we need to be able to
> separate is the _role_ some _process_ on a device have at the
> moment.
>
> This means that a lot of devices that in a legacy world are "host
> only" might start running code that turns them into routers.

I agree.  In this particular case a 'tethered' smartphone is a router.
It should include DHCPv6 PD Requesting Router, MAY send RAs, may not
send RS, forward==1, and others.

No longer is that just Host development.

> And _that_ code probably needs to support both being a DHCPv6 client
> AND server, as it might need to accommodate PD.   Whether the OS
> itself should have all that code included by default will probably
> depend on the vendor or provider.

Yes.  Moreover, neither the vendor nor the provider should oppose 
politically the download of a DHCPv6-PD app from an Android (or other) 
store.

> In an ideal world, that means that installing e.g. VMWare, KVM and
> such should depend on both a dhcpv6-server and client being
> installed (or bundled) on the host. And when I turn on tethering on
> my phone, it should probably also enable a dhcpv6-client to get a
> prefix, and a dhcpv6-server to be able to serve clients behind it
> with prefixes, should they ask for a IA-PD.

Sounds reasonable.

> some software on the device changes its role to a "router".

I also agree.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Apr 2017 13:28:14 +0200

Le 07/04/2017 à 12:14, Lorenzo Colitti a écrit :
> On Fri, Apr 7, 2017 at 5:52 PM, Tore Anderson <[email-masked]
> <mailto:[email-masked]>> wrote:
>

But a tethered smartphone is a Router.

And you cited earlier a tethering argument in this thread.

Alex

> I think you're misunderstanding my position. There are two arguments
> here. The way I see it, a must for DHCPv6 is harmful because DHCPv6 is
> functionality (for which I have provided examples). A MUST for RDNSS is
> not harmful in this way. Therefore, a MUST for RDNSS is a good idea
> because a) it's the more capable protocol, and b) it provides a
> guarantee of interoperability once old OSes have aged out.
>
> I don't think there's a contradiction there, it's just that you and I
> have different goals. You want everything to work everywhere, as soon as
> even if that would lead to a worse outcome in the long term. That means
> you want DHCPv6, because you need Windows to work.
>
> I want to the best outcome in the long term and am willing to wait for
> it. That means I don't want DHCPv6, because for as long as IPv4 is
> around it's not a necessity.
>
>
> long-term flexibility of host configuration in the Internet of
> encouraging a protocol (DHCPv6) that is both a) technically inferior to
> the alternative and b) familiar to many network operators, some of whom
> will choose it because it is familiar or easier and not because it is
> better. I don't want us all to be running DHCPv6 20 years from now,
> because it's suboptimal. I want us all to be running RDNSS, because it's
> better.
>

---

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

On 04/06/2017 06:37 PM, Lorenzo Colitti wrote:
> On Fri, Apr 7, 2017 at 2:21 AM, Bernie Volz (volz) <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > Please don't tell me that the client needs to react to the RA with
>     the new DNS servers by starting DHCP to request DNS servers. :-)____
> 
>     __ __
> 
>     The client would react to the RA having new prefix information –
>     such as that the old prefix was deprecated.
> 
> 
> Can you cite an implementation that does this, or even a specification
> that recommends or requires it?
> 
> distribute DNS information and the only way to know that that
> information needs to be refreshed is to listen for an RA" is absurd,

I kind of agree with this part -- but that's the design of DHCPv6/SLAAC.
e.g., you're supposed to listen to RAs before querying DHCPv6 servers.

Thanks,

---

From: Simon Hobson <[email-masked]>
Date: Fri, 7 Apr 2017 12:43:40 +0100

Lorenzo Colitti <[email-masked]> wrote:

> I don't want us all to be running DHCPv6 20 years from now, because it's suboptimal. I want us all to be running RDNSS, because it's better.

In a subset of situations.
Does RDNSS provide NTP servers ? No. Does RDNSS provide per-host config ? No. Does RDNSS allow custom options* ? No.
So as I see it, you have a "all networks are very basic" PoV where IP+router+DNS == complete config. Many of us take a view that this triplet is only a bare minimum and we actually need other options for things to actually work.

I'm not against RDNSS becoming MTI. But, with a vociferous subsection apparently against DHCP which is clearly vastly superior in terms of what it can configure, I see the end result being that everyone implements RA+RDNSS and then it's impossible to get anything resembling a consensus to even keep DHCP.

* Example, the brand of wireless AP I use most at work supports a customer option to provide it with a provisioning server - allowing "plug and connect" installation where the Ap automatically appears in the controller ready to be adopted. With DHCP, trivial, with RAs ?
Typically VoIP phones use DHCP to get key information - such as their identity and the server they need to register with.

> Like I said, I wouldn't strongly oppose saying that enterprise-class routers MUST implement DHCPv6. If you're running BGP, VRRP, and DHCPv6 failover, you don't ever need to change anything, so the additional benefits of RDNSS won't help much.

Don't need any of BGP, VRRP, Failover to be able to provide stable operations.

In the "handset as a mobile hotspot" scenario, it's perfectly feasible to hand out the link-local address of the WiFi interface to WiFi clients to use as a DNS resolver. IIRC someone mentioned earlier that the mobile networks expect tethering phones to run a cache locally to reduce network traffic. So under what circumstances would that LL address change - losing the cell signal and getting it back wouldn't do it.

PS - I wasn't going to reply just to mention it, but early "privacy concerns" were given as a reason not to us DHCP. Sorry - but for someone from Google, given their business model, to raise privacy concerns is "interesting".

---

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

On 04/06/2017 06:14 PM, Lorenzo Colitti wrote:
> Many of the operators who are advocating for DHCPv6 here say that
> everyone uses anycast DNS anyway, and that their DNS servers have not
> changed for 15 years. That's great in an enterprise network that uses
> BGP, but the number of such networks is dwarfed by the number of home
> networks that *don't* use anycast DNS and *do* get renumbered. Saying
> that all those routers MUST implement DHCPv6, and degrade the ability of
> those networks to renumber like this, is fundamentally broken.

Implement != use.

Nobody said that you have to use DHCPv6 in replacement of RDNSS, or even
that you should send DNS information both via RDNSS and DHCPv6.

The discussion has been about supporting both RDNSS and DHCPv6, such
that an operator can make his own decision regarding whether to do RDNSS
only, stateless DHCPv6 only, or RDNSS + DHCPv6.

>     RFC 8106 came out of 6man (https://datatracker.ietf.org/doc/rfc8106/
>     <https://datatracker.ietf.org/doc/rfc8106/>). I might suspect that
>     6man would consider a draft updating it to reverse its
>     recommendation that DHCPv6 be preferred over RDNSS, although that is
>     for its chairs to say. I think you have presented some very relevant
>     arguments to support the viewpoint.
> 
> Changing 8106 won't avoid breakage to existing implementations. If we
> add this MUST, then deploying a router that follows this MUST will break
> the ability to renumber of existing clients. This is not good
> operational practice and we should not do it.

Kind of off-topic here but: did you argue against the preference of
DHCPv6-conveyed DNS info over that conveyed in RDNSS options while
RFC8106 (or its antecessor, RFC6106) were being pursued?

Thanks,

---

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

On 04/06/2017 05:51 PM, Lorenzo Colitti wrote:
> On Fri, Apr 7, 2017 at 1:48 AM, Tore Anderson <[email-masked]

Users and operators will be busted by the game being played by a group
of vendors.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Apr 2017 05:41:09 -0700

I see a lot of people talking and not hearing here. I don't have a real
suggestion to make other than that the idea that you are going to convince
any handset maker to change what they are doing based on this document is
not realistic. So if your path to win depends on this, you are wasting your
and the working group's time.

On Apr 7, 2017 04:48, "Fernando Gont" <[email-masked]> wrote:

> provision

---

From: Philip Homburg <[email-masked]>
Date: Fri, 07 Apr 2017 14:48:09 +0200

>and the working group's time.

If it has no impact, they let's just publish node requirements that all
nodes SHOULD support both RDNSS and all types of DHCP (stateful for IA_NA,
stateless for just DNS, etc).

Any vendor that doesn't like it can just do their own thing. We don't have
any police or black helicopters.

I think having a MUST or a SHOULD in a BCP has huge impact. That's why
there is so much opposition to writing that down.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Apr 2017 05:49:55 -0700

I don't think there is a lot of Odin to writing that down for rdnss. The
problem is that there is a large contingent who want a pony before they'll
agree to it.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 07 Apr 2017 14:54:15 +0200

>problem is that there is a large contingent who want a pony before they'll

The 'pony' is simply that all nodes SHOULD support the relevant bits of 
DHCP.

You already said that in your opinion vendors will ignore that anyhow. So
this is more of thumb-sized animated gif that features a pony. Who could
object to that?

And in return you get your RDNSS support. Sounds like a small price to pay.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Apr 2017 05:59:41 -0700

I'm cool with SHOULD for DHCP relay on routers. But I hear some people
insisting on MUST, and on hosts, and suggesting that we should require DHCP
servers in routers, which is too​ much.  Take a small victory: don't insist
on the pony.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 07 Apr 2017 15:18:18 +0200

In your letter dated Fri, 7 Apr 2017 05:59:41 -0700 you wrote:
>servers in routers, which is too=E2=80=8B much.  Take a small victory: don'=
>t insist
>on the pony.

I'm fine with discussing just router requirements and leaving hosts to 
node requirements.

I'd say that for routers, a MUST for RDNSS should be paired with a MUST for
DHCP relay and a SHOULD for DHCP stateless server.

I'm not aware of routers that do not have the resources for a DHCP relay. I.e.,
constrained devices tend to be hosts. If someone has a contrained device
that is a router, then a SHOULD for DHCP relay makes sense.

I have not heard any technical objection to a DHCP stateless server that is
off by default. 

Likewise, if you have a configuration mechanism for RDNSS then the same
can be used for DHCP stateless. If the stateless DHCP server is off by default
it cannot do any harm.

But I'm sure that if rough concensus can be declared that at least DHCP relay
is at least a SHOULD, then we should be able to sort out other details.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Apr 2017 15:22:14 +0200

> e.g., you're supposed to listen to RAs before querying DHCPv6 servers.

That order in itself may be intuitive for some, but less intuitive for 
others myself included.

One needs time before having anything else, and that comes with DHCP.

Alex

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 7 Apr 2017 13:30:58 +0000

> insisting on MUST, and on hosts, and suggesting that we should require 
> DHCP servers in routers, which is too much.  Take a small victory: don't 
> insist on the pony.

Now I'm confused again about which doc we're talking about.
Regarding all nodes....
RFC 6434 for all IPv6 nodes already says: 
"all hosts SHOULD implement address  configuration via DHCPv6"
" If a host implementation supports
   applications or other protocols that require configuration that is
   only available via DHCP, hosts SHOULD implement DHCP."

So since nodes already have a SHOULD for DHCPv6 address and other configuration info, and there is strong opposition to making it a MUST, what more does the node doc need to say about DHCPv6 in order to achieve the above-requested pony?

RFC 6434 also says:
" Implementations SHOULD implement the DNS RA option [RFC6106]."
There is a  proposal to make this a MUST. Since DHCPv6 is already a SHOULD, does that mean the pony ransom is met?

Regarding routers...
We have CE Routers with DHCPv6/RDNSS requirements described in RFC 7084. As an employee of an ISP who is impacted by, whose mass market customers are impacted by, and who procures such CE routers, I'm saying leave my CE routers alone. I'm not asking for additional operational help from v6ops. The CE routers my company procures that have built in DSL or G.fast modems will not be implementing DHCPv6 Relay unless my company says so. [It does have DHCPv6 server, because support for IA_PD for "cascaded" routers is necessary for a good user experience.] It's not up to IETF and I'm not asking IETF's opinion or "help" with this.
There are devices that support "tethering". The suppliers of those are not requesting additional IETF advice. The wireless operators those devices connect (on the WAN) to are not requesting additional advice. The consumers using the tethering function aren't complaining about anything being broken. So leave them alone.
We have enterprise operators asking for v6ops help in supplying what they need to deploy IPv6. Actually, we have them asking for what they want (max flexibility and choice, with others incurring the cost of supplying that), and not just what they need. But we should focus on what they need.
There are enterprise operators who are asking for help. V6ops is in a position to help them, but should restrict this help to assisting them with requirements for routers that they procure and that are under their control. V6ops has adopted a draft to supply such assistance (draft-ali-ipv6rtr-reqs). I have seen no arguments against having this document say that enterprise routers MUST implement DHCPv6 (stateful) server *and* DHCPv6 Relay. So, good, that pony can be delivered (with MUST and not just SHOULD). And since many enterprise operators say they want to allow all mass market devices to attach, this doc needs to say MUST implement RDNSS (in the RA), so enterprise routers will meet the needs of these operators.

Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 7 Apr 2017 13:36:10 +0000

> I'm not aware of routers that do not have the resources for a DHCP relay.
> I.e., constrained devices tend to be hosts. If someone has a contrained
> device that is a router, then a SHOULD for DHCP relay makes sense.
> 
> I have not heard any technical objection to a DHCP stateless server that is off
> by default.
> 

For enterprise routers (newly adopted draft-ali-ipv6rtr-reqs), yes. But leave my CE routers out of it. I'm not adding DHCPv6 Relay to my routers with built-in DSL or G.fast modems. The access network expects DHCPv6 messages to come from the 802.1x-authenticated device. Not through it.
And leave tethering routers out of it, too. 3GPP wireless providers aren't asking for relayed DHCPv6 messages to be coming into the 3GPP wireless network.
Focus on the enterprise routers. Those ar the operators asking for v6ops help.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Apr 2017 06:45:58 -0700

> DHCP relay and a SHOULD for DHCP stateless server.

If you haven't heard a technical objection to a SHOULD for a stateless DHCP server, you didn't read my message where I asked what the language would be that would specify it, and gave a list of questions that would need to be answered.   You can't just say "routers SHOULD implement stateless DHCP."

You also haven't answered Lorenzo's question about how Android is supposed to do this when there isn't going to be a way to turn it on in the UI, and when there is literally never going to be a DHCP server to which the DHCP relay could relay.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 07 Apr 2017 15:58:19 +0200

>    If you haven't heard a technical objection to a SHOULD for a
>    stateless DHCP server, you didn't read my message where I asked
>    what the language would be that would specify it, and gave a
>    list of questions that would need to be answered.   You can't
>    just say "routers SHOULD implement stateless DHCP."

If you tell me all the details you are going to write down in your
specification for RDNSS then I'll just copy them can replace RDNSS with
stateless DHCP DNS option.

So, could you please give me the requirements for RDNSS?

>    You also haven't answered Lorenzo's question about how Android
>    is supposed to do this when there isn't going to be a way to
>    turn it on in the UI, and when there is literally never going
>    to be a DHCP server to which the DHCP relay could relay.

I don't know about all Android devices, so I'll just refer to my phone:

- There are 3 toggles to switch on or off USB, Wifi and Bluetooth tethering
- In Wifi tethering, there is
  - an input field for the SSID,
  - a drop down menu for security
  - a password field is you select PSK
  - a check box show the password

Note that in wifi configuration, there are an insane number of options
to configure 802.1X but also options to statically configure DNS resolvers.

You are now going to tell me that  with all these options, there is no space
for an option the enable DHCPv6 functionality when configuring a hotspot?

---

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

Yes, and he'd be right. In all probability, the people who make this sort
of decision will (rightly) conclude that only a vanishingly small
percentage of users will even have ever heard of DHCPv6, and will probably
say something like, "Why do users need a setting for something they've
never heard of? Is the setting necessary for things to work? Can we make
things work the way the user wants without the setting?"

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Apr 2017 02:16:52 +1200

> Focus on the enterprise routers. Those ar the operators asking for v6ops help.

More generally, qualify each requirement by the class of scenarios that it
applies to. It's very clear from this "discussion" that one size does not
fit all.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Apr 2017 16:13:22 +0200

> have some conditions, perhaps they are incomplete).

Well, what example of knowledge about network change does the client 
need in order to stop issuing Solicits?

I am asking because it is not normal that my Windows client continues to 
issue Solicits forever after having obtained a Server 3 months ago.

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 7 Apr 2017 14:44:02 +0000

> I am asking because it is not normal that my Windows client continues to issue Solicits forever after having obtained a Server 3 months ago.

Ideally, device should be using the M&O bits to determine whether DHCPv6 is supposed to run or not.

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Friday, April 07, 2017 10:13 AM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Making RDNSS a MUST?, hum v2

> have some conditions, perhaps they are incomplete).

Well, what example of knowledge about network change does the client need in order to stop issuing Solicits?

I am asking because it is not normal that my Windows client continues to issue Solicits forever after having obtained a Server 3 months ago.

Alex

>
> - Bernie
>
> -----Original Message----- From: v6ops [mailto:[email-masked]] 
> On Behalf Of Alexandre Petrescu Sent:

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Apr 2017 07:50:33 -0700

> So since nodes already have a SHOULD for DHCPv6 address and other configuration info, and there is strong opposition to making it a MUST, what more does the node doc need to say about DHCPv6 in ord…

Sorry, the pony is "MUST", not "SHOULD".

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Apr 2017 16:51:44 +0200

Le 07/04/2017 à 15:36, STARK, BARBARA H a écrit :
[...]
> Focus on the enterprise routers. Those ar the operators asking for

In an IPv4-only Enterprise network I have not seen DNS-in-RA, because
there were no RAs.

But until full IPv6 arrives, the computers already chatter IPv6.

In addition to ICMPv6 messaging (NS, NA, RS, MLD) and DHCPv6 Solicit,
there is also large UDPv6 traffic made of mDNS, LLMNR, SSDP NOTIFY, and
WS-Discovery.

So, similarly to contemplating DNS in RA, one may wonder whether to put
in RS/RA any one of these name-related activities implemented by the
above protocols:
- reverse resolution of servers of well-known services
- direct resolution like IN A web proxy auto-discovery protocol (wpad)
- WebServices Discovery
- even some things about 'googlecast'.

In same vein, similarly to contemplating RA eliminating DHCP, one may
wonder whether DNS-in-RA will make disappear these protocols (mDNS,
LLMNR, SSDP NOTIFY, WS-Discovery) from Enterprise networks.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Apr 2017 07:53:38 -0700

> for an option the enable DHCPv6 functionality when configuring a hotspot?

No, there's no way to explain it.   And what exactly is it that you are going to type in?   The IP address of the DHCP server the relay is supposed to forward to?

The WPA stuff is pretty hairy, but it's actually required to get on the network.   A DHCP relay in a phone not only isn't required, but won't work.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Apr 2017 07:54:43 -0700

> stateless DHCP DNS option.

But that's just it, Phillip.   RDNSS is _way_ simpler than DHCP.   You're already doing ND.   So it really is just one line for RDNSS.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 07 Apr 2017 17:05:49 +0200

In your letter dated Fri, 7 Apr 2017 07:53:38 -0700 you wrote:
>No, there's no way to explain it.   And what exactly is it that you are 
>going to type in?   The IP address of the DHCP server the relay is 
>supposed to forward to?

For a tethering, the most useful is a stateless DHCP server that serves
DNS and other options. 

In some cases, a DHCP relay can also be useful, so a dialog box that allows
either a hostname or an IPv6 literal would be required.

Note that for tethering having both a stateful DHCP server and a DHCP relay
present but default disabled would be best.

(Only now I realise that RFC 3315, Section 20 requires a DHCPv6 relay 
to default to the All_DHCP_Servers multicast address. Obviously, that doesn't
make any sense. I'm not even aware in what context it would make sense.)

---

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

>> So since nodes already have a SHOULD for DHCPv6 address and other 
>> configuration info, and there is strong opposition to making it a MUST, 
>> what more does the node doc need to say about DHCPv6 in order to 
>> achieve the above-requested pony?

> Sorry, the pony is "MUST", not "SHOULD".

Foul! You deleted the preceding context, which was specifically in reply to Philip Homburg saying:
" The 'pony' is simply that all nodes SHOULD support the relevant bits of DHCP."
I realize that other people want different ponies. I was just trying to see if Philip's pony was still outstanding wrt node requirements. 
Barbara

---

From: Philip Homburg <[email-masked]>
Date: Fri, 07 Apr 2017 17:24:15 +0200

> Foul! You deleted the preceding context, which was specifically in
> reply to Philip Homburg saying:  " The 'pony' is simply that all
> nodes SHOULD support the relevant bits of DHCP." I realize that
> other people want different ponies. I was just trying to see if
> Philip's pony was still outstanding wrt node requirements.

My pony is that wherever we require something related to RA/SLAAC/RDNSS 
we require a similar thing from DHCP.

Note similar. I'm not saying a MUST has to be paired with a MUST. In many 
cases a SHOULD is perfectly fine. 

Also note that my pony allows for exceptions for technical contraints. No
need for low power devices to implement both. No need to relay DHCP
requests to a multicast address on a 3GPP link if the link specification says
that that should not be done.

---

From: Tore Anderson <[email-masked]>
Date: Fri, 7 Apr 2017 18:50:46 +0200

* Lorenzo Colitti

> The reason I called this thread was for hosts, not routers.

You asked for both, actually:

https://mailarchive.ietf.org/arch/msg/v6ops/5JOK6RRzjNgSSMJBmBKPFrHluxY

To be clear, I do support both. Having RDNSS in all (new) hosts and all
(new) routers would indeed be an improvement, regardless of what (if
anything) we say about stateless DHCPv6 at the same time.

> functionality (for which I have provided examples). A MUST for RDNSS
> is not harmful in this way. Therefore, a MUST for RDNSS is a good
> idea because a) it's the more capable protocol, and b) it provides a

Having DHCPv6 service in the network can only possibly be harmful in
this manner only if the hosts actually decide to make use of it.

For example, Android hosts don't do DHCPv6, period. Regardless of what
the network offers. Thus the Android users will be totally insulated
from any of the perceived "DHCPv6 harm" or regressions.

> have different goals. You want everything to work everywhere, as soon
> as possible, without IPv4, and are willing to accept suboptimal
> outcomes in some parts of the network (like the regressions I
> provided examples of), even if that would lead to a worse outcome in
> the long term. That means you want DHCPv6, because you need Windows
> to work.

Indeed, I do think having current Windows hosts being completely unable
to make use of an IPv6-only network is a much worse outcome, than having
the same hosts being able to use the network while lacking a mechanism to
easily change the assigned DNS server address on the fly.

But having this today does not preclude working towards an RDNSS-only
world long term, see below.

> I want to the best outcome in the long term and am willing to wait
> for it. That means I don't want DHCPv6, because for as long as IPv4
> is around it's not a necessity.
[...]
> I can see your point of view. But please do consider the effects on
> the long-term flexibility of host configuration in the Internet of
> encouraging a protocol (DHCPv6) that is both a) technically inferior
> to the alternative and b) familiar to many network operators, some of
> whom will choose it because it is familiar or easier and not because
> it is better. I don't want us all to be running DHCPv6 20 years from
> now, because it's suboptimal. I want us all to be running RDNSS,
> because it's better.

Acknowledging that stateless DHCPv6 is a necessity for pure IPv6
networks today does not preclude us from working towards eventually
changing that:

Android could behave like today, getting DNS servers from RDNSS only.
This makes providing RDNSS a necessity for IPv6-only network operators,
and insulates Android users from any possible "DHCPv6 harm".

The Apple folks on this list have stated a preference for RDNSS, too,
so although their nodes also support DHCPv6, perhaps they could be
persuaded to give RDNSS information preference above DHCPv6 (assuming
that's not already the case), to prevent the "DHCPv6 harm". For
example, not bothering with acquiring/using DNS servers from DHCPv6 if
a RDNSS option was present in the RA(s) received. Or perhaps even
remove the stateless DHCPv6 client functionality entirely.

Then you'd only need Microsoft to follow suit to reach critical mass.
Who knows what they're planning... (I have noticed you've been dropping
some hints that you might be better informed than the rest of us about
this, but that doesn't really help us make any more informed decisions.)

Only at this point, and after most of the current install base has been
updated/replaced accordingly and RDNSS support has become ubiquitous,
would it make sense to reconsider the new operational reality and state
that having stateless DHCPv6 in the network for DNS server signaling
has become entirely optional/redundant.

Tore

---

From: james woodyatt <[email-masked]>
Date: Fri, 7 Apr 2017 13:16:45 -0700

On Apr 7, 2017, at 00:04, Lorenzo Colitti <[email-masked]> wrote:
> That would disrupt all communications between clients on the hotspot and make users unhappy.

Not to mention an additional problem: hosts do a lot of potentially undesirable things after a link-down event, e.g. roam to another SSID, switch to their own cellular interface, etc. Some of those things end up charging users money when they happen.

---

From: Ross Chandler <[email-masked]>
Date: Fri, 7 Apr 2017 21:46:30 +0100

> On 7 Apr 2017, at 17:50, Tore Anderson <[email-masked]> wrote:
> 

Tried that using Google DNS in DHCPv6 and it looks like they put them all in the list. 
Perhaps there’s a cmdline tool for seeing the state of Happy Eyeballs of DNS server addresses. 
I have seen macOS not use name servers that are listed as Reachable here when they don’t respond to DNS queries.

$ scutil --dns
DNS configuration
 
resolver #1
  search domain[0] : home
  nameserver[0] : 2001:4860:4860::8888
  nameserver[1] : 2001:4860:4860::8844
  nameserver[2] : fe80::1%en0
  nameserver[3] : 192.168.1.254
  nameserver[4] : 192.168.1.254
  if_index : 5 (en0)
  flags    : Request A records, Request AAAA records
  reach    : Reachable

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Apr 2017 07:10:21 +1000

In message <CAKD1Yr2fvOkrPsWkNh=-_w_nrw-QtC=[email-masked]>, Lorenzo Colitti writes:
> --001a1134ee386b1ca2054c8e4ecf
> Content-Type: text/plain; charset=UTF-8
> 

So, I'm not allowed to test host in IPv6 only mode when tethering!
Good to know.  Hosts are NOT REQUIRED to turn on IPv4.

I actully do tests like this occasionally.  I turn off IPv4.  I see
what is reachable in a pure IPv6 only environment.

Google isn't reachable.  There are no IPv6 servers for google.com.

Your job is to provide equipement that provides a working IPv6
network regardless of how the host is configured.  You are not doing
that.

---

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

> Good to know.  Hosts are NOT REQUIRED to turn on IPv4.

What do you mean? You can certainly configure your tethered host as
IPv6-only. The host can get its DNS servers through RDNSS or static
configuration. Like I said, I think adding support for DHCPv6 here would
make things worse, not better, because it would provide broken connectivity
to clients that are capable of both when the upstream prefix changes.

> Google isn't reachable.  There are no IPv6 servers for google.com.

Unfortunately, every time we've looked at the data, the conclusion has been
that it would cause unwarranted user impact. IIRC the most recent blocker
was a major US ISP whose clients would experience breakage if even just one
NS record was dual-stacked. It's not an infrastructure problem: the servers
have supported IPv6 for years, and some zones like google.fi do have IPv6
NS records.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 08 Apr 2017 23:30:13 +0200

>But that's just it, Phillip.   RDNSS is _way_ simpler than DHCP.   
>You're already doing ND.   So it really is just one line for RDNSS.

That does not compute.

The hard part is not writing a simple stateless DHCP server that can
insert a DNS option.

But if you think that is really complex:

A router MUST/SHOULD contain a 'stateless' DHCPv6 server that supports the
DHCPv6 DNS configuration options.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 8 Apr 2017 19:27:54 -0400

> DHCPv6 DNS configuration options.

Did you not read my earlier message where I explained why this wasn't as simple as what you've written?

---

From: Philip Homburg <[email-masked]>
Date: Sun, 09 Apr 2017 10:35:42 +0200

>simple as what you've written?

I stopped reading when I realized that whose questions could or would have
to be answered for RDNSS as well.

(Of course there are some DHCP specific issues. If you include both a
DHCP server and a relay agent you have have knob to select which one
to use. Big deal)

---

From: Ted Lemon <[email-masked]>
Date: Sun, 9 Apr 2017 09:03:43 -0400

> to be answered for RDNSS as well.

No they wouldn't, because RDNSS isn't stateful and you aren't adding a protocol, since you're already doing RA.   But I suppose I'm just wasting electrons typing this.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 10 Apr 2017 03:39:02 -0700

> Okay, so can't clients just do a mDNS request to find a local resolver?

Because what we really need here is a third auto one mechanism... NOT

> higher-layer parameters like RDNSS and DNSSL.  It causes real

Nobody is suggesting you have to use it. Just that we want to pressure router and host developers to make it available in the toolbox for operators to choose.

> service and the distributor of the configuration.

This sounds like a perfectly valid reason to choose DHCP in the circumstances where it applies, but in cases where they are the same team, there is real benefit to having RDNSS and DNSSL as an option so as not to have to maintain a DHCP server.

>  If a DNS server

The word "anycast" comes to mind.

> With DHCP, the DNS server can and often is co-located with the DHCP

I think occasionally would be a more accurate statement than "often", but be that as it may, it's not always the case and it's just as often that the router provides a local DNS resolver or proxy service meaning that there's at least as good a case for fate sharing on the router as on the DHCP server.

This is why I am arguing for mandatory implementation and let the operator choose the features that work best in their particular environment. Unfortunately, if we don't require implementation, then the operator has only the choices made available to him by the vendors in question where there may not necessarily exist a compatible subset across all vendors in his environment.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 10 Apr 2017 03:51:59 -0700

> On Apr 5, 2017, at 14:24, Simon Hobson <[email-masked]> wrote:
> 
Meh

> One thing that slightly concerns me is all this determination to put decisions into the device, rather than the network. In effect, fundamental decisions are made by <any old device> which may well…

This is inherent in peer to peer networking. Unless you have a way to reject a host that is statically configured with information that is valid for the local network it is attached to, you inherently trust the operator of the host (if not the host itself) to make those decisions, whether you intend to or not.

> That's a good question. Not even private DNS zones answers that one - a host wouldn't know which interface it needed to use until it knows the IP address of the destination and look it up in the ro…

The short answer is that it isn't necessarily a link-specific parameter, but if you want to have a zeroconf host, then you have to have some way for it to learn something about DNS in its environment. Since all of the configuration information mechanisms currently available are link-parameter focused, it seems that is the hammer we have.

I think there is an extremely valid argument that creating yet another type of hammer is _NOT_ a useful alternative here. We have perfectly functional ways to solve this using the two existing hammers (RDNSS/DHCP6). The biggest problem we have at this point is that neither one is required so implementations are sketchy in terms of compatibility and operator choice.

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Apr 2017 15:06:28 +0200 (CEST)

On Sat, 8 Apr 2017, Lorenzo Colitti wrote:

> Unfortunately, every time we've looked at the data, the conclusion has 
> been that it would cause unwarranted user impact. IIRC the most recent 
> blocker was a major US ISP whose clients would experience breakage if 
> even just one NS record was dual-stacked. It's not an infrastructure 
> problem: the servers have supported IPv6 for years, and some zones like 
> google.fi do have IPv6 NS records.

I'd be very interested in understanding the reason for the failure you 
describe.