Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt)

From: [email-masked]
Date: Wed, 1 Mar 2017 09:15:56 +0100

Brian,

[...]

>>> There's another closely related breakage, which is the absence of
>>> default router signalling in DHCPv6. That means that even if a site
>>> must use DHCPv6 for configuring stuff that RAs cannot configure, they
>>> must also use RAs for configuring stuff that DHCPv6 cannot configure.
>>> 
>>> Something like bad systems design.
>> 
>> It's a failure of the IETF to have specified two ways of doing the same thing. And now you are proposing that we should do even more of that?
> 
> In the sense that two incomplete solutions are worse than two complete solutions,
> yes. I think the real goal is that a wide-enough set of functions should be
> covered by both solutions, and to my mind that should include both DNS servers
> and default routers.

They are only incomplete if you redesign how they are supposed to work after the fact.
They are complementary, and there are very good reasons for that.

An off-link DHCP server advertising a default router address wouldn't even have IP reachability to the default router address. It has no effective way of updating a host's default router nor deal with default router failure. Fate sharing etc. We've been through these arguments so many times I don't see any purpose in rehashing all of them.

Let's not make the problem worse.

In the principle of fate sharing, it is clear that the node offering the service is the node advertising the service, and that it is directly discovered by the host that consumes it. That's not the case for how deal with DNS recursive resolver configuration today. Why do we assume that the local network should even provide DNS configuration?

Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Mar 2017 19:57:41 +1100

On 1 Mar. 2017 16:29, "David Schinazi" <[email-masked]> wrote:

> On Feb 28, 2017, at 21:09, Fernando Gont <[email-masked]> wrote:
>
> COuld you please explain how this document would make that worse?

By perpetuating coexistence of multiple solutions to the same problem.

> This document is not about picking a winner in this religious battle.
> Operators should evaluate what works better for them.
>
> What we want is for them to be able to make that choice, because
> nowadays, they simple can't.

It sounds like your document is designed to allow operators to pick
what works best for them, by forcing mobile device manufacturers
to implement both. Why don't device manufacturers get to pick
which one is best for their users?

Sounds like you're fighting another religious battle, and I don't
think the IETF should pick a side.

If the IETF care about IPv6 adoption, then we need to do something.

That might sound overly dramatic. I don't think it is. Humans are involved.

The problem is when there are two or more choices, that appear to be equal
or near equal, then not making a choice becomes the least risky option,
compared to the risk of making the wrong choice. Future wrong choice
consequences are possibly worse than the current and future no choice
consequences.

What this resolves to in the current situation:

(a) choose RA DNS options, with the risk that everybody else chooses DHCPv6
DNS

(b) choose DHCPv6 DNS, with the risk that everybody else chooses RA DNS

(c) don't deploy IPv6 until the popular DNS configuration option becomes
clear.

(c) is the safest option, and the result is less IPv6 deployment.

My specific preference would be to get rid of RA DNS options and DHCPv6 IA
options, so there is only one solution to these problems, and no need to be
forced to make a possibly wrong choice.

I doubt that is going to happen. The next best thing is what is in this
draft. Make hosts, increasingly BYO, interoperable with whatever the
network operator or system administrato has chosen (and we should recognise
and accommodate their boldness, because we've forced them to be bold, and
they have been, because they didn't choose (c)).

Regards,
Mark.

David

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 18:01:56 +0900

On Wed, Mar 1, 2017 at 5:57 PM, Mark Smith <[email-masked]> wrote:

> (a) choose RA DNS options, with the risk that everybody else chooses
> DHCPv6 DNS
>

Can you explain why you didn't list:

(d) support both? That's what millions of home routers do today.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Mar 2017 10:37:49 +0100

Le 01/03/2017 à 09:15, [email-masked] a écrit :
> Brian,
>
> [...]
>
>>>> There's another closely related breakage, which is the absence
>>>> of default router signalling in DHCPv6. That means that even if
>>>> a site must use DHCPv6 for configuring stuff that RAs cannot
>>>> configure, they must also use RAs for configuring stuff that
>>>> DHCPv6 cannot configure.
>>>>
>>> It's a failure of the IETF to have specified two ways of doing
>>> the same thing. And now you are proposing that we should do even
>>> more of that?
>>
>> In the sense that two incomplete solutions are worse than two
>> complete solutions, yes. I think the real goal is that a
>> wide-enough set of functions should be covered by both solutions,
>> and to my mind that should include both DNS servers and default
>> routers.
>
> They are only incomplete if you redesign how they are supposed to
> work after the fact. They are complementary, and there are very good
> reasons for that.
>
> An off-link DHCP server advertising a default router address
> wouldn't even have IP reachability to the default router address. It
> has no effective way of updating a host's default router nor deal
> with default router failure. Fate sharing etc. We've been through
> these arguments so many times I don't see any purpose in rehashing
> all of them.

These fate sharing arguments may be pure speculation in IPv6 with
respect to default routes. Whereas in IPv4 very large networks are
operated with this lack of supposedly fate sharing need (distribute
default routes by a centralised DHCP server) in IPv6 there is no
experience with large office networks that are IPv6-only, so we cant say
how real this fate sharing need is.

Let me give examples answering these two questions:

Fate sharing applied between which components?  And how about survivability?

We want the Host to share the fate of the Router (not of a remote DHCP
Server): if that Router lives then the Host lives too.

But we also want survivability: it's not because the Router dies that
the Host must die too.

Also, we dont want the fate of the Router to be shared with the DHCP Server.

Survivability of DHCP Servers is ensured by load-balancing with VRRP
between DHCP Servers.

And we dont have survivability between Routers with respect to the
default routes: there can be a potentially long lapse of time between
the old default route being deleted upon death of the old default router.

We dont know which default route a Host must choose when two routers
send default routes simultaneously.

> In the principle of fate sharing, it is clear that the node offering
> the service is the node advertising the service, and that it is
> directly discovered by the host that consumes it. That's not the
> case for how deal with DNS recursive resolver configuration today.

By this principle, mDNS would not respect fate sharing either, right?
In mDNS a request to convert name to address is sent out in the wild
(multicast) and we dont know who replies, whether it is on the same DNS
domain, or not.

> Why do we assume that the local network should even provide DNS
> configuration?

Because of security.  The time of convenient using of someone else's DNS
server is long past, I think.

But I wonder whether you meant 'local subnet' or 'local network'?  I
guess not all local subnets will provide DNS servers.

I also guess, if I understand it correctly, mDNS has a role to play here
- supposedly it does not need RA nor DHCP.  It's simply a 3rd way of
doing it.

Alex

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

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Mar 2017 21:25:15 +1100

On 1 Mar. 2017 20:02, "Lorenzo Colitti" <[email-masked]> wrote:

Enterprise routers don't, going by the Microsoft article.

https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/

Which should adapt to which? The hosts adapt to the network or the network
adapt to the hosts?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 19:31:26 +0900

On 1 Mar 2017 7:25 pm, "Mark Smith" <[email-masked]> wrote:

If you read the Microsoft blog post you'll see that when it was written
they were already testing vendor code that had RDNSS support.

---

From: Eismann Dominik <[email-masked]>
Date: Wed, 1 Mar 2017 11:08:53 +0000

[Wieland]<http://www.wieland-electric.com/de/wieplan>

[Twitter]<http://wie.li/twitter> [Facebook] <http://wie.li/facebook>  [Youtube] <http://wie.li/youtube>
Wieland Electric GmbH
Sitz: Brennerstrasse 10-14, D-96052 Bamberg
Geschaeftsfuehrer: Dr. Oliver Eitrich, Dr. Ulrich Schaarschmidt
Registergericht: AG Bamberg HRB 105

Der Inhalt dieser Mail enthaelt moeglicherweise vertrauliche Informationen und ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Wenn Sie nicht der richtige Adressat sind, teilen Sie dem Absender bitten den Erhalt der Mail mit und loeschen Sie die Mail.

The content of this mail may contain confidential information and is intended solely for the designated addressee. If you are not the intended addressee, then please inform the sender the receipt of this mail and delete the E-Mail.

If you read the Microsoft blog post you'll see that when it was written they were already testing vendor code that had RDNSS support.

Pleae bear in mind that not everyone of us is as big as Microsoft who can convince his router vendors to implement new features to suite its needs. Having an RFC to point to would at least help a little with these vendors. Since probably neither RDNSS nor DHCPv6 will win the battle over which one is better, the pragmatic decision for such an RFC can only be to mandate both.

---
Kind Regards,

Dominik Eismann

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 01 Mar 2017 14:34:01 +0000

[email-masked] wrote:
> An off-link DHCP server advertising a default router address wouldn't
> even have IP reachability to the default router address. It has no
> effective way of updating a host's default router nor deal with
> default router failure. Fate sharing etc. We've been through these
> arguments so many times I don't see any purpose in rehashing all of
> them.

Please can we move past this particular canard?  It is still as much of
a straw man argument as it was when it was first suggested 15-20 years
ago.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Wed, 01 Mar 2017 15:47:18 +0100

>a straw man argument as it was when it was first suggested 15-20 years

Indeed. If this were such a big problem, somebody would have tried to 
resurrect IPv4 Router Advertisement ICMPs (RFC 1256).

Surprisingly, the only time the inability to update default routers is
mentioned, is when somebody tries to prevent that feature from getting added
to ICMPv6.

---

From: [email-masked]
Date: Wed, 1 Mar 2017 16:00:41 +0100

Nick,

> a straw man argument as it was when it was first suggested 15-20 years

No.

Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Mar 2017 10:36:56 -0500

On Mar 1, 2017, at 5:25 AM, Mark Smith <[email-masked]> wrote:
> Which should adapt to which? The hosts adapt to the network or the network adapt to the hosts?

Obviously the network should support a diversity of hosts.

That doesn't help much, does it?   I think it is actually correct, but I haven't said why, and I think Fernando could quite legitimately demand that I do so.   But I can make the same demand of him.   So in order to try to decide which sort of advice to give, we should really try to figure out what it is that we care about.

One advice to give is that hosts and routers should support both methods.   This is obviously the most general advice, but only works if everybody follows it.

Another advice would be that routers should support both methods.   This has the virtue of making the set of things that need to be updated relatively small, but getting new firmware out of router vendors with new features in it isn't always easy, so I can see why an ops person would resist that solution.   Nevertheless, we are thinking long term, so putting this in the router requirements document long term would work as well as any of the other options we might consider.

The other virtue of this approach is that it puts the responsibility for making it happen in the hands of people who are notionally capable of taking responsibility for it: network operators.   In principle, network operators can tell whether or not their infrastructure conforms.   This cannot be assuemd to be true of end users.

The third advice would be to require that hosts support both methods.   This has the virtue of not pissing off network operators.   That's no small thing if we really believe that network operators are going to continue resisting the deployment of IPv6 until we stop pissing them off.   However, that's a pretty thin excuse for making the decision this way, and I think that's why there's pushback.   If this really feels like the right thing to do, it might be worth exploring why it is that it feels that way and stating the reasons explicitly.   I don't think "to mollify operators" is a very good reason.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Mar 2017 00:51:09 +0900

> resurrect IPv4 Router Advertisement ICMPs (RFC 1256).

IPv4 is a different problem. In IPv4, DHCP works fine because you never
*need* to change anything, since you have NAT and VRRP.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 01 Mar 2017 17:09:40 +0100

>*need* to change anything, since you have NAT and VRRP.

I have no idea how NAT is somehow better for default routers when IPv6
has link local. In any case, VRRP also works for IPv6. 

So maybe you can be more specific how IPv6 routers are less stable than IPv4?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 1 Mar 2017 18:54:08 +0000

I guess I'll play and add my two cents.
For CE ("average" user, mass market) routers, RFC 7084 makes support of RDNSS *and* DHCPv6 stateless or stateful server to the LAN a MUST. As has been pointed out, CE routers with IPv6 seem to be meeting these requirements just fine. If all IPv6-capable CE routers are able to do this, then so are enterprise routers. To suggest that because some enterprise router manufacturers still haven't implemented RDNSS, they shouldn't or can't be expected to do so, is wrong. 

This is working just fine in the world of mass market.

Along come the enterprise networks. 

If an enterprise wants to insist on only DHCPv6 (for IPv6 address and/or DNS server addresses), then they will only be allowing connection by hosts that support DHCPv6. 
If an enterprise wants to insist on only RDNSS and SLAAC, then they will only be allowing connections by hosts that support these.
If an enterprise has a router that doesn't do RDNSS, but they want RDNSS, then they need to demand it. Apparently, Microsoft did, and got it.
The enterprise controls the purchase of the enterprise router. Therefore, they have the ability to influence it. The enterprise who controls what attaches to that router can dictate requirements for attaching hosts. The enterprise who does not control what attaches, has no ability to control what attaches.
The enterprise who wants to let anything attach MUST support RDNSS and stateless-or-stateful DHCPv6. Just like CE routers. That is what it is.

What if a host vendor (or host OS vendor) wants to provide hosts to DHCPv6-only enterprises? They implement DHCPv6. 
What if they don't care about such enterprises? Then they don't care. 
Participants at IETF should not attempt to use IETF in an attempt to force uncaring vendors to implement. The marketplace is the bully, not IETF. Either the vendors see demand for the functionality, or they don't.

Let the free market and human nature do their job. The necessary standards exists.
Barbara

---

From: james woodyatt <[email-masked]>
Date: Wed, 1 Mar 2017 10:56:23 -0800

On Mar 1, 2017, at 00:15, [email-masked] wrote:
> 
> Why do we assume that the local network should even provide DNS configuration?

Because the Domain Name System (DNS) is an essential service of the Internet. Allow me to provide a bit of history from memory in the hopes it will explain how this particular assumption came to be established here.

—

Many years ago, when I was implementing the predecessor of RFC 6106, while it was still an Internet Draft, I remember half-heartedly proposing in 6MAN and here in V6OPS that the way host operating systems needing automatic DNS server address configuration should cope with RA messages with the O flag cleared by querying for the SRV record at _dns._udp.local over mDNS.

I was just about to start writing an Internet Draft to that effect when various IETF participants here suggested there could be serious Security Considerations there. (Never mind that DHCPv6 has the same Security Consideration. We sort-of had DHCP Shield for that problem. There was no mDNS Shield yet.)

So I said, “What should I do? The RA message says not to expect any DHCPv6 service here. On the other hand, I have a perfectly sane ad-hoc multicast service discovery protocol already defined to do this in the event there is no DHCPv6 service. I’ve got to implement something.”

And somebody said, “What if we resurrect my old RDNSS draft?”

And other people, including me, said, “Yeah, but is there an RA Guard equivalent of DHCP Shield?”

And the answer to that was, “Well, I guess we could publish that draft too.”

And I said, “Okay, I can live with that."

And so I implemented RDNSS in the router, and I helped get RDNSS implemented in the hosts we cared most about. (I also needed to implement Stateless DHCPv6 service in the router so that another vendor’s hosts would get DNS information too. And that’s why RFC 7084 says to do both.)

—

Here’s really how we got into this mess:

1. we made DNS an essential service of the Internet;

2. then we made DHCPv6 the only way to configure hosts with DNS service automatically;

3. and we made DHCPv6 optional by giving routers a way to say “there is no DHCPv6 here."

When we did that, we set ourselves up for having more than one way to configure hosts with DNS configuration. One using DHCPv6, and another for when DHCPv6 is not available.

I can think of five (5) different IETF published Standards Track protocols that are available for hosts to configure their DNS information automatically: DHCPv6, RDNSS, mDNS-SD, SLP and CoRE-RD. I can think of several more non-standard ones beyond those.

Only one of those standard protocols is one that IPv6 hosts are generally already required to implement: Router Discovery. It’s perfectly okay with me if IETF publishes a BCP that says hosts with DNS clients MUST be capable of processing RDNSS to configure their DNS information automatically. Because they are generally required to process RA messages to configure their IP service automatically. It would be a very low impact requirement.

I am opposed to dealing with this problem by telling host implementers they MUST implement a DHCPv6 client, and they MUST use it even when RA messages are telling them “there is no DHCPv6 here,” for all the reasons I enumerated previously.

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

---

From: Simon Hobson <[email-masked]>
Date: Wed, 1 Mar 2017 19:15:15 +0000

> Let the free market and human nature do their job. The necessary standards exists.

To a point.
To throw my 2d in, there are several "but"s to that.

1 - As a small business (as my employer is) we have no clout with the vendors. For a business the size of Microsoft, to be told "we want this or you don't get our business" s enough to make them listen. If we (wearing my hat as a network admin for a small IT services business) try that, they are probably going to be in "did someone say something ? Nah" because individually we don't matter. In practice we can't even talk to them because most of the big ones won't talk to small businesses directly.

2 - The next one is that for many small businesses, we probably don't know that we need to ask the question until we are trying to figure out why things "aren't working" - and by then the vendor has got their money. The end result is likely to be a significant reinforcement that "IPv6 is just too difficult".

3 - And lastly, unless the standards specifically state that both|all methods "must" be supported, then vendors can continue with the misdirection that they support all required RFCs/protocols - thus leading to inexperienced buyers continuing to buy their stuff - see item 2 !

So I think that if it's determined that for all reasonable combinations of equipment to work that certain types of kit needs to support certain RFCs/protocols - then that needs to be stated as a "must". Without that, vendors are free to do "half a job" and still claim compliance - and others have already ex[pressed what that means in terms of whether you can reasonably expect to plug something in and have it work.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Mar 2017 20:17:47 +0100

> resurrect IPv4 Router Advertisement ICMPs (RFC 1256).

We use IPv4 Router Advertisements in 802.11-OCB settings to facilitate 
handovers in IPv4-only networks.

---

From: [email-masked]
Date: Wed, 1 Mar 2017 20:41:25 +0100

James,

Thanks for the summary. There is also more here:
https://tools.ietf.org/html/draft-ietf-ipngwg-dns-discovery-analysis-00
https://tools.ietf.org/html/rfc4339

The reason I questioned the assumption is because of the information leakage associated with a recursive resolver.
Using the recursive resolver offered by the network, means you entrust the network with every DNS query you make.
Does that make sense for the FreePublicWIFI at the airport, the coffee shop, the home CPE, or the Enterprise?

Apart from running a resolving server on the host and doing DNS over DTLS I'm not sure how to resolve that.

Perhaps the local network must provide a recursive resolver, but the practice of using it for all queries by default is perhaps something we should wean ourselves off.

Ole

> On 1 Mar 2017, at 19:56, james woodyatt <[email-masked]> wrote:
> 
> --james woodyatt <[email-masked]>
> 
> 
>

---

From: Gert Doering <[email-masked]>
Date: Wed, 1 Mar 2017 20:44:18 +0100

Hi,

On Wed, Mar 01, 2017 at 11:00:34AM +0900, Lorenzo Colitti wrote:
> On Wed, Mar 1, 2017 at 4:53 AM, Gert Doering <[email-masked]> wrote:
> 
> > So, they cannot reasonably implement what should have been the default
> > for new deployments years ago, and need to add IPv4 purely because IETF
> > failed to very clearly mandate what router and host OS vendors need to
> > provide, so a network can run v6-only today...
> >
> 
> Why do you say they "cannot" implement it? There is nothing stopping a
> network from supporting both stateless DHCPv6 and RDNSS. Many residential
> gateways do this today, and those often aren't high-margin implementations.
> 
> Saying "hosts must implement both stateless DHCPv6 and RDNSS so that
> networks can choose to implement only one" is one way to solve this
> problem. Saying "networks should support both stateless DHCPv6 and RDNSS so
> that hosts can choose to implement only one" is another.

You are blissfully ignoring the part where I described how we entered
this mess - two major vendors ignoring half the stuff users would expect
to find implemented, one on the host OS side, one on the network device
side.

And you very stubbornly insist that everyone *else* should fix the mess
that this host OS vendor is causing.  Right?

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: Wed, 1 Mar 2017 15:23:38 -0500

> that this host OS vendor is causing.  Right?

Woah, which is it?   Is it the host vendor?   Is it the router vendor?   How did you get from two major vendors ignoring half the stuff the users would expect, and it being solely the host vendor's fault?   Not that I'm interested in whose fault it is—I'm just asking what missing ??? there is in here that led from paragraph 1 to paragraph 2.

---

From: Gert Doering <[email-masked]>
Date: Wed, 1 Mar 2017 21:27:46 +0100

Hi,

On Wed, Mar 01, 2017 at 03:23:38PM -0500, Ted Lemon wrote:
> Woah, which is it?   Is it the host vendor?   Is it the router vendor?   

Both, of course.

> How did you get from two major vendors ignoring half the stuff the users 
> would expect, and it being solely the host vendor's fault?   

That was mostly turning around Lorenzo's argument that there is no problem
in Android if the network can just be made to provide RDNSS.  Which, while
factually true, does not help anyone.

But yeah, let's just rely on DHCPv4 forever.  No problem.

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Wed, 1 Mar 2017 21:36:54 +0100

> factually true, does not help anyone.

If you were to have networks offering the same information both via RA and DHCP, then you're bound to end up in situations where the information passed is out of sync, and you have hosts getting confused. Hosts supporting both on networks supporting both are probably already confused.

Here are two ways we can get out of the bind:

1) Complimentary: Remove redundant options between RA and DHCP. I.e. remove DNS options from DHCP.
2) Competing: Add everything missing in one to the other. And a network MUST only support one of the protocols.

A good part of this is caused by our inability to solve the service discovery problem.

Ole

---

From: Simon Hobson <[email-masked]>
Date: Wed, 1 Mar 2017 20:37:00 +0000

> Apart from running a resolving server on the host and doing DNS over DTLS I'm not sure how to resolve that.

Indeed, and don't forget that the network operator can pretty well see everything we do even without looking at the DNS queries. Sticking just to web, they can see every site we visit simply by sniffing the HTTP[S] packets. Even with SSL they can see that - either there's SNI in cleartext stating the hostname we want, or each site has a separate IP (pre-SNI config).
Though it is true that it's a lot easier to just look at the DNS logs.

> Perhaps the local network must provide a recursive resolver, but the
> practice of using it for all queries by default is perhaps something we should wean ourselves off.

And while it's off-topic for this thread ... got any suggestions ? I think we're stuck with DNS as it stands, I'd put your chances of persuading the whole world to rip it up and replace it as "exceedingly slim" ! Lets face it, SMTP is much more broken as people (or at least, big organisations) seem happy to keep applying more layers of duct-tape to try and cover the cracks.
And as you say, short of running some sort of encrypted tunnel to your own (or a trusted) DNS server, there's not a lot you can do to hide the traffic.
You always have the option of firing up a VPN and stuffing all traffic down that if you are sufficiently paranoid.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 1 Mar 2017 21:08:21 +0000

[email-masked] wrote:

> If you were to have networks offering the same information both via RA and DHCP, then you're bound to end up in situations where the information passed is out of sync, ...

Isn't that just another case of "admins can screw up a network" ? I can put an incorrect address in a DHCP config, and always have been able to, and the client is broken !
That's just part of being a network admin - not putting stupid values in your configs, or at least if you do then have a means of spotting it before the users complain ;-)

---

From: Mark Smith <[email-masked]>
Date: Thu, 2 Mar 2017 08:16:00 +1100

On 1 Mar. 2017 21:31, "Lorenzo Colitti" <[email-masked]> wrote:

Upgrading hosts is much easier than upgrading networks.

Microsoft has the pull to get something added like that and the budget to
upgrade their infrastructure very regularly, so they're not going to face
the issue of equipment that isn't current enough to have new features
added. Organisations whose network budgets are measured in units of 1000s
don't have that influence.

"So, is all this trouble worth it?

Hopefully."

What a sad, sad question and a sad, sad answer, 19 years after the
publication of RFC2460.

---

From: Mark Smith <[email-masked]>
Date: Thu, 2 Mar 2017 08:26:37 +1100

Most people don't know about it. The only methods they've been taught are
static configuration or DHCP.

It's better know as ICMP Router Discovery Protocol (irdp), Cisco routers
support it, and Linux hosts likely have the client  installed - rdisc.

Search for IDRP and you'll find references to using it with Solaris and HA
Linux setups.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Mar 2017 13:55:47 +1300

> That's just part of being a network admin - not putting stupid values in your configs, or at least if you do then have a means of spotting it before the users complain ;-)

True, but in general, having to put the same info in two places is a bad
and error-prone thing. Normally I strongly stand by RFC 1958:
"3.2 If there are several ways of doing the same thing, choose one."
But in this case we are painted into a corner and pragmatism should
prevail, IMNSHO.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Mar 2017 01:52:42 -0300

On 03/01/2017 05:36 PM, [email-masked] wrote:
>>> How did you get from two major vendors ignoring half the stuff
>>> the users would expect, and it being solely the host vendor's
>>> fault?
>> 
>> That was mostly turning around Lorenzo's argument that there is no
>> problem in Android if the network can just be made to provide
>> RDNSS.  Which, while factually true, does not help anyone.
> 
> If you were to have networks offering the same information both via
> RA and DHCP, then you're bound to end up in situations where the
> information passed is out of sync, and you have hosts getting
> confused. 

That's why we aim at:

1) Devices operated by the network admin to support both options, such
that the admin can decide which of the two options works best for her/hoim.

2) Client-side devices to support both options, so that whatever the
admin chose, does work.

> Hosts supporting both on networks supporting both are
> probably already confused.

Nowadays you have the worst case scenario: both client and router/server
implementations supporting only a subset of the aforementioned mechanisms.

So you're likely to get both:

1) out-of-sync info
2) Confused hosts
3) Hosts that just "cannot connect to the network" (they don't get a DNS
server)
4) Quite a lot of WTH ("What The..?!") moments, particularly when we
eventually phase out IPv4, and admins and users find the price that they
have to pay for our lousy job.

> remove DNS options from DHCP. 

Possible, also not doable because of SLAAC "advocates" (for a friendly
term9.

> 2) Competing: Add everything missing in
> one to the other. And a network MUST only support one of the
> protocols.

Our document is a lightweight version of this. We just require support
for DNS-related options and for the corresponding mechanisms in both
network-side and client-side devices, and expect the network admin to
pick one, and have the selected option (whatever it is) to "just work".

> A good part of this is caused by our inability to solve the service

Agreed.

Now, at the very least, we could provide a pragmatic solution for the
DNS info.

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

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 2 Mar 2017 00:50:21 -0500

> But in this case we are painted into a corner and pragmatism should

In that case since my IPAM/DNS/DHCP system is one integrated system, I
should keep the DNS info in the central IPAM server and deliver it via
DHCPv6 rather than configure it in dozens or hundreds of routers all
over the place, all of which would need to be updated when a DNS
server fails.  IPAM vendors don't talk to routers to update their RA
config.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Mar 2017 06:59:26 +0100 (CET)

> Upgrading hosts is much easier than upgrading networks.

I am not sure you wrote this, your quoting looks very weird in my email 
reader... but anyhow, whoever wrote this, I don't agree.

Both are hard to upgrade.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Mar 2017 03:38:04 -0300

Hello, Barbara,

On 03/01/2017 03:54 PM, STARK, BARBARA H wrote:
[....]
> 
> If an enterprise wants to insist on only DHCPv6 (for IPv6 address
> and/or DNS server addresses), then they will only be allowing
> connection by hosts that support DHCPv6. If an enterprise wants to
> insist on only RDNSS and SLAAC, then they will only be allowing
> connections by hosts that support these. If an enterprise has a
> router that doesn't do RDNSS, but they want RDNSS, then they need to
> demand it. Apparently, Microsoft did, and got it.

Folks have already chimmed in on this one: Microsoft probably doesn't
qualify as a regular enterprise.

> The enterprise
> controls the purchase of the enterprise router. Therefore, they have
> the ability to influence it. The enterprise who controls what
> attaches to that router can dictate requirements for attaching hosts.

Not really. IN many BYOD scenarios, this is not actually truth.

> The enterprise who does not control what attaches, has no ability to
> control what attaches. The enterprise who wants to let anything
> attach MUST support RDNSS and stateless-or-stateful DHCPv6. Just like
> CE routers. That is what it is.

And it's a sad state of affairs.

> What if a host vendor (or host OS vendor) wants to provide hosts to
> DHCPv6-only enterprises? They implement DHCPv6. What if they don't
> care about such enterprises? Then they don't care. Participants at
> IETF should not attempt to use IETF in an attempt to force uncaring
> vendors to implement. The marketplace is the bully, not IETF. Either
> the vendors see demand for the functionality, or they don't.
> 
> Let the free market and human nature do their job. The necessary
> standards exists. Barbara

We, as an SDO, are offering two half-baked solutions for automatic
configuration...and that's bad.

What's worse, many of the ops folks that are struggling to deploy v6
have no much of a clue about this sad situation, and thy will eventually
find out the hard way: when they phase v4 out, and find that, for many
nodes, DNS information is now gone.

Thanks,

---

From: Marcus Keane <[email-masked]>
Date: Thu, 2 Mar 2017 08:37:03 +0000

>What a sad, sad question and a sad, sad answer, 19 years after the publication of RFC2460.

Thank you, Mark, for bringing this to my attention. It's actually an editing error, and I will get it corrected. The sentence should read "Hopefully, migrating to IPv6 (dual-stack) is uncontroversial at this stage". This, I'm sure you'll agree, is quite different. 
The question was rhetorical, and the ensuing paragraph sets out some reasons why we think it is "worth it". You should not have the slightest impression that we are ambivalent about our IPv6 efforts.
Hope this helps clear things up.
Marcus

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Mar 2017 09:20:01 -0500

On Mar 2, 2017, at 12:50 AM, Chuck Anderson <[email-masked]> wrote:
> all of which would need to be updated when a DNS
> server fails. 

Does this ever actually happen on your network?   On my network, if the hardware for a DNS server were to fail, it would be immediately replaced, and would have the same IP address as before.

I realize that this is a side issue, but I think it's important to be clear on whether or not the use cases we are talking about are real or concocted.   This one sounds a bit concocted from my perspective, but I'm curious to hear what your actual operational practice is.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 2 Mar 2017 14:47:39 +0000

Ted ... spot on. I find the argument that DNS server addresses change on a frequent basis a silly argument. Sure it may happen but I would guess that it is pretty rare. And for best service:

-          Specify multiple addresses (for multiple servers for high availability)

-          When replacing a server, assure it continues to use the same addresses as before (whether IPv4 or IPv6)

Having to update any configuration information on other devices (whether the routers or DHCP servers and getting that propagated through the network) is probably not desirable and much work than just retaining the previous addresses of the (failed) DNS server.

-          Bernie

From: v6ops [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, March 02, 2017 9:20 AM
To: Chuck Anderson <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt)

On Mar 2, 2017, at 12:50 AM, Chuck Anderson <[email-masked]<mailto:[email-masked]>> wrote:
all of which would need to be updated when a DNS
server fails.

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 02 Mar 2017 09:34:16 -0600

> Having to update any configuration information on other devices (whether the routers or DHCP servers and getting that propagated through the network) is probably not desirable and much work than ju…

That's why I've seen anycast DNS used in large deployments.

Dale

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Mar 2017 00:37:53 +0900

On Thu, Mar 2, 2017 at 11:47 PM, Bernie Volz (volz) <[email-masked]> wrote:

> Ted … spot on. I find the argument that DNS server addresses change on a
> frequent basis a silly argument.
>

Please consider dynamic mesh networks and unmanaged host networks.

Having to update any configuration information on other devices (whether
> the routers or DHCP servers and getting that propagated through the
> network) is probably not desirable and much work than just retaining the
> previous addresses of the (failed) DNS server.
>

How are you going to do that in a home network where the user just tripped
over the power cord of the router in front of the DNS server? That address
is not even routable any more.

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 2 Mar 2017 11:05:26 -0500

> is not even routable any more.

Doesn't matter because DNS and routing are fate-shared in that case.
If the only router is down, it doesn't matter if DNS is down.

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 2 Mar 2017 11:45:42 -0500

> Does this ever actually happen on your network?   On my network, if the hardware for a DNS server were to fail, it would be immediately replaced, and would have the same IP address as before.

No because I used Anycast DNS.

> I realize that this is a side issue, but I think it's important to be clear on whether or not the use cases we are talking about are real or concocted.   This one sounds a bit concocted from my per…

It is concocted.  That was my point.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 02 Mar 2017 21:06:31 +0000

Ted Lemon wrote:
> Does this ever actually happen on your network?   On my network, if the
> hardware for a DNS server were to fail, it would be immediately
> replaced, and would have the same IP address as before.
> 
> I realize that this is a side issue, but I think it's important to be
> clear on whether or not the use cases we are talking about are real or
> concocted.   This one sounds a bit concocted from my perspective, but
> I'm curious to hear what your actual operational practice is.

These alleged use cases are about as realistic as the spherical cow in a
vacuum.  This and its sister argument of "DHCP has no effective way of
updating a host's default router nor deal[ing] with default router
failure" are both restatements of:

    Under what circumstances is it necessary to roll out an
    unexpected mass renumbering of DNS servers / default gateways
    with a guaranteed cut-over time of N seconds, where N is small?

The answer is: very rarely, and if it's that big an issue, RAs almost
certainly won't cut it.

Operators handle problems like this automatically (e.g. anycast dns or a
first-hope redundancy protocol for gateways) or manually and from a
practical point of view, it matters not in the slightest whether the
numeric identifier of these services is delivered by RAs or DHCPv6
because those mechanisms are not used for providing high availability.
Neither scales adequately or provides the desired high availability
characteristics necessary for this purpose.

If guarantees of uptime are important, services operators will use
anycast dns and some form of FHRP for the default gateway, and they
monitor downstream services of both to ensure service continuity.  RAs
add nothing in this situation and they scale terribly badly for HA
because you need to tweak the time intervals down to silly levels to
make it work even sub-par.

Non professional service operators (e.g. Ma, Pa, Grandma, Joe's Tackle &
Bait, or "We Sue You" Legal Services Corp.) get preconfigured devices
which publish dns and default gateway addresses either via dhcp or RAs.
 If there are problems, both DNS server and default gateway failure are
usually symptoms of some other underlying problem, e.g. dead wifi, DSL
dropped, someone jiggled the cable to the workstation, the cleaner
unplugged the server to vacuum around it, etc.  In other words, not
situations where performing a mass renumbering of the default gateway or
the dns server is going to make much of a difference unless there's been
a network design put in place, which, given the nature of what we're
talking about in this situation, is not ever going to have happened.

Operationally, I've never come across a situation where there was a
requirement to change DNS server or default gateway on lots of machines
in a matter of seconds without any prior warning, where it wasn't easier
and simpler to provide alternative service by renumbering another
gateway or dns server.  For sure, DNS server and gateway renumbering
happens, but it's a planned, phased event which requires the usual
balancing act between cost of loss of service and cost of reducing
cutover time, and there is generally no reason that the cutover time
should be measured in seconds.  Hours would usually be great fine, and
days often quite adequate.

If a server or a gateway fails and there's no automatic failover
mechanism in place, it's easier to replace with a device with the same
ip address than add to your woes by attempting a service identifier
renumber at the same time as a service failure.  That would be a stupid
thing to do.

If the network operator is attempting to renumber a network in an
instant, handling it automatically would probably work fine in labs or
other contrived situations, and would almost certainly end in
entertaining levels of fail if attempted on an actual production network.

So with due respect to those people who propose that this is a problem
worth fixing at a protocol level, it isn't in my books, and the solution
it provides is for the most part unfit for purpose.

Note that I'm not denying that there are situations where RAs provides
an elegant solution for providing connectivity assistance tokens. I'm
sure several people involved in operations on this working group deploy
these protocol mechanisms in situations where it's appropriate.

However, if they've done this, I have no doubt that this is the
consequence of applying the right tool for the job rather than
specifying the tool and demanding that the problem comply with the solution.

Overall this argument is a canard and it is frankly an embarrassment to
see it rolled out as a reason for disparaging dhcpv6 on such a regular
basis.

Nick

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Mar 2017 08:20:07 +1100

In message <[email-masked]>, Fernando Gon
> configuration...and that's bad.

No.  We offered a fully baked solution (set O and use DHCPv6) and
later we offered a alternative RDNSS which would work for equipement
that also support it.

In my opinion we should document this state of affairs.

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

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 02 Mar 2017 22:12:44 +0000

Lorenzo Colitti wrote:
> How are you going to do that in a home network where the user just
> tripped over the power cord of the router in front of the DNS server?
> That address is not even routable any more.

This is a difficult situation because you're describing a situation
where a protocol would need to be designed to handle homenets with
automatic monitoring of DNS server queries to provide a feedback
mechanism which could reconfigure the RA on CPE devices if the DNS
servers went offline.  It could do something clever like running a
multicast dns query or bonjour or something to detect new dns servers on
the home network and then feed the result back into a new multicast
group which could signal to the RA router.  We'd need some new line
protocols but yeah, this is definitely feasible assuming Ma & Pa's
homenet is running a multitude of independently provisioned dedicated
DNS servers.  The performance and scalability characteristics could be
pretty good, assuming constant background polling for spare DNS servers
to build up a local cache on the polling server, and with a small amount
of work, we could also build up a preference list based on performance
results.  This is good stuff.  We could get at least 2-3 RFCs out of this.

Ah, I see what you're at: the user should plug the power cable back in!

Oh you!

Nick

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Mar 2017 19:58:16 -0300

On 03/02/2017 06:20 PM, Mark Andrews wrote:
[...]
> later we offered a alternative RDNSS which would work for equipement

Shame on us: stateless DHCPv6 support is required. Hence, setting O to 1
will not necessarily mean hosts will employ DHCPv6 to e.g. configure DNS
information.

> In my opinion we should document this state of affairs.

At the very least, document it. But please see the above: we didn't do
our best job when declaring what must be supported and what need not.

Thanks,

---

From: [email-masked]
Date: Fri, 3 Mar 2017 00:03:50 +0100

Fernando,

> our best job when declaring what must be supported and what need not.

RFC6434 section 7.

You need to do a serious reality check if you think writing yet another document saying exactly the same thing one more time is going to change the world.

Cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Mar 2017 10:16:00 +1100

In message <[email-masked]>, Fernando Gon
> will not necessarily mean hosts will employ DHCPv6 to e.g. configure DNS

We really shouldn't have to treat developers as babies.  We produced
a RFC that provided a solution for anyone that wanted to support
automatic configuration of recursive DNS servers.

If OS developers are too stupid to follow it, that really shouldn't
be our problem.  We can't get around OS developers (host and router)
that say "I don't want to do X" which is basically what this entire
thread boils down to.  I don't want to do both RA and DHCP.  A pox
on router and host vendors that say this.  Stop being babies and grow
up.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Mar 2017 14:12:53 +1300

On 02/03/2017 18:50, Chuck Anderson wrote:
...
> IPAM vendors don't talk to routers to update their RA
> config.

I expect some of them do, but if yours doesn't, and you want
Android devices on your network to be able to do DNS over v6,
you need to fill that gap somehow.

    Brian

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 2 Mar 2017 22:26:23 -0500

> you need to fill that gap somehow.

I'll just do Anycast DNS.  Then it won't matter if I choose to use
DHCPv6 or RA.  My point was that the argument that RA is better
because you can more quickly update the DNS server address during a
DNS server failure was a contrived case that no one would rely on.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Mar 2017 13:14:05 +0900

> results.  This is good stuff.  We could get at least 2-3 RFCs out of this.

Appreciate the irony, but the reality is that most of the problem is solved
by HNCP and DNCP. Said solution is much better than your (presumably
intentionally suboptimal) solution above, but it still relies on being able
to tell the host that something changed.

---

From: [email-masked]
Date: Fri, 3 Mar 2017 08:48:33 +0100

> on router and host vendors that say this.  Stop being babies and grow

Another plausible explanation is that someone is engaging in the game of RFC number collection...

Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 03 Mar 2017 11:43:29 +0100

>RFC6434 section 7.
>
>You need to do a serious reality check if you think writing yet another
>document saying exactly the same thing one more time is going to change
>the world.

Maybe we take ourselves a bit more seriously. RFC 6434 is published as 
Informational. "This document is not an Internet Standards Track
specification; it is published for informational purposes."

So basically we are telling the reader: we don't care if you follow this or
not. Do whatever you like. This not important enough to be a standard or
a BCP.

Now assuming that reader wants to follow this document, we give the following
advice:

Section 7.2.1
"If a host implementation supports applications or other protocols that
"require configuration that is only available via DHCP, hosts SHOULD
"implement DHCP.

Okay, what about DNS resolvers? DNS resolvers are also available from RA.
So obviously, the above text is meant to say that DHCP is obsolete and 
should only be implemented if some piece of information has not been
tranfered to a protocol other than DHCP.

But all of this is still informational, so the SHOULD in 7.3 doesn't
really mean anything.

So maybe if 6434 was actually BCP and would say SHOULD with regard to
DNS from both DHCP and RA then draft-gont-v6ops-host-configuration-00.txt 
would clearly be superfluous.

---

From: Tim Chown <[email-masked]>
Date: Fri, 3 Mar 2017 10:49:42 +0000

Hi,

> On 3 Mar 2017, at 10:43, Philip Homburg <[email-masked]> wrote:
> 
>> RFC6434 section 7.
>> 

There is an RFC6434 update underway. If you have suggestions for that, fire away.

I don’t know at this stage if there will be a proposal to upgrade the revved version to BCP.  There would be an argument for it, given it will be the 3rd version of the original document, with 10+ years of operational experience behind it.

Tim

---

From: Tim Chown <[email-masked]>
Date: Fri, 3 Mar 2017 11:06:40 +0000

> On 3 Mar 2017, at 01:12, Brian E Carpenter <[email-masked]> wrote:
> 

This reminds me that at IETF97 I mentioned that draft-ietf-netmod-routing-cfg-25 did not include the RDNSS option (and other non ‘core’ RA options) in its ietf-ipv6-router-advertisements submodule. I’ve just nudged some potential co-authors on this, at least to get an initial -00 out before Chicago.

Tim

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 03 Mar 2017 11:33:39 +0000

Lorenzo Colitti wrote:
> Appreciate the irony, but the reality is that most of the problem is
> solved by HNCP and DNCP. Said solution is much better than your
> (presumably intentionally suboptimal) solution above, but it still
> relies on being able to tell the host that something changed.

please see what I wrote yesterday on this:

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

Nick

---

From: Philip Homburg <[email-masked]>
Date: Fri, 03 Mar 2017 14:52:26 +0100

> I dont know at this stage if there will be a proposal to upgrade
> the revved version to BCP.  There would be an argument for it,
> given it will be the 3rd version of the original document, with
> 10+ years of operational experience behind it.

In order of preference
1) Make it a BCP.

2) Add text similar to: "If a host contains a (stub) DNS resolver then the
host should try to obtain a list of DNS resolvers from RAs and, if the O
flags is set in an RA, using a DHCPv6 (information) request."

3) Hosts that have enough resources to be able to support both RA and DHCPv6
SHOULD try to configure addresses using RA and DHCPv6 IA_NA (if the M flag 
is set).
(I think a SHOULD should be able to satisfy Lorenzo's use case. Because you
are allowed to violate a SHOULD if there are technical reasons to do so,
we can even make that explicit)

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Mar 2017 11:16:52 -0800

> DNS server failure was a contrived case that no one would rely on.

Except home network gateways, which integrate DNS server, RA server and DHCPv6 server in one host do absolutely rely on this. When the DNS server moves to a new LAN address (which happens when configuration is reset and the router restarted, e.g. when firmware is updated) the RA server can update immediately the hosts on the LAN using the DNS server from the previous configuration, whereas the hosts with stateless DHCPv6 configurations will not recognize the new configuration until the old one expires.

Some of us take the user experience of firmware upgrades to home gateway products seriously.

---

From: Simon Hobson <[email-masked]>
Date: Fri, 3 Mar 2017 19:39:58 +0000

james woodyatt <[email-masked]> wrote:

> Except home network gateways, which integrate DNS server, RA server and DHCPv6 server in one host do absolutely rely on this.

In this case, the DNS server and router are one and the same device - if one goes down, the other does. So it really doesn't matter - when the router comes back up, so will it's DNS server.

> When the DNS server moves to a new LAN address (which happens when configuration is reset and the router restarted, e.g. when firmware is updated) ...

Don't know what sort of devices you are working with, because I'm used to devices that can update their firmware without nuking their config - and I'd be "very unhappy" with a vendor doing that sort of trick.
Even where the config does get nuked, what's the first thing you do after an upgrade ? Perhaps put the config back to what it was ?

---

From: Fernando Gont <[email-masked]>
Date: Fri, 3 Mar 2017 18:55:29 -0300

Hi, Ole,

> You need to do a serious reality check if you think writing yet another document saying exactly the same thing one more time is going to change the world.

May I ask that you read what you "quote" or reference before doing so?

Let's take a look at Section 7 of RFC6434 (that you referenced above):

---- cut here ----
7.2.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315

7.2.1.  Other Configuration Information

   IPv6 nodes use DHCP [RFC3315] to obtain address configuration
   information (see Section 5.9.5) and to obtain additional (non-
   address) configuration.  If a host implementation supports
   applications or other protocols that require configuration that is
   only available via DHCP, hosts SHOULD implement DHCP.  For

[fgont] This is flawed. DNS information is also available 8in theory)
via RDNSS, hence the paragraph above is an invitation to not implement
DHCPv6. Put nther way, what is currently in RFC6434 Section 7 (which you
referenced as the text that we're copying) is actually the root of the
problem, rather than the solution.

   specialized devices on which no such configuration need is present,
   DHCP may not be necessary.

   An IPv6 node can use the subset of DHCP (described in [RFC3736]) to
   obtain other configuration information.

[fgont] I don't even know what "can" means here. Yeah, sure.. they can
use DHCP. What the text should say is that if the O bit is set, nodes
MUST use DHCPv6.

7.2.2.  Use of Router Advertisements in Managed Environments

   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   are expected to determine their default router information and on-
   link prefix information from received Router Advertisements.

7.3.  IPv6 Router Advertisement Options for DNS Configuration - RFC 6106

   Router Advertisements have historically limited options to those that
   are critical to basic IPv6 functioning.  Originally, DNS
   configuration was not included as an RA option, and DHCP was the
   recommended way to obtain DNS configuration information.  Over time,
   the thinking surrounding such an option has evolved.  It is now
   generally recognized that few nodes can function adequately without
   having access to a working DNS resolver.  [RFC5006] was published as
   an Experimental document in 2007, and recently, a revised version was
   placed on the Standards Track [RFC6106].

   Implementations SHOULD implement the DNS RA option [RFC6106].

[fgont] So... this paragraph states "It is now generally recognized that
few nodes can function adequately without having access to a working DNS
resolver"  then make RDNSS support a MUST. It should also be clear that
the above text has a preference for RDNSS, since, based on the reasoning
above, you don't need to implement DHCPv6 if what you need is a DNS
server (such information can be conveyed in RA messages.
---- cut here ----

Besides, the referenced document (RFC6434) is an informational document.
As noted "This document is not an Internet Standards Track
specification; it is published for informational purposes.". So, at the
end of the day, an implementation can completely ignore this document,
and still claim to be compliant with IETF's IPv6 specs.

Please check what you reference before posting. Otherwise, that's not
much of a service to the community. (It may be a service to vendors,
though, that essentially may want to ship products with what they
please, leveraging their market position while still claiming that they
comply with all of our specs).

Thanks,