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

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 05:13:25 -0300

Folks,

Based on a recent discussion regarding the problem of conveying DNS
information in IPv6 networks, we have submitted this short I-D, in the
hopes of getting the aforementioned problem solved.

Your feedback will be appreciated.

Thanks!
Fernando (and co-autors)

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-host-configuration-00.txt
Date: Mon, 27 Feb 2017 23:51:03 -0800
From: [email-masked]
To: Fernando Gont <[email-masked]>, Gert Doering
<[email-masked]>, Madelen Garcia Corbo <[email-masked]>,
Madelen Corbo <[email-masked]>, Guillermo Gont
<[email-masked]>

A new version of I-D, draft-gont-v6ops-host-configuration-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-v6ops-host-configuration
Revision:	00
Title:		On the Dynamic/Automatic Configuration of IPv6 Hosts
Document date:	2017-02-27
Group:		Individual Submission
Pages:		6
URL:
https://www.ietf.org/internet-drafts/draft-gont-v6ops-host-configuration-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-v6ops-host-configuration/
Htmlized:
https://tools.ietf.org/html/draft-gont-v6ops-host-configuration-00

Abstract:
   IPv6 has two different mechanisms for dynamic/automatic host
   configuration: SLAAC and DHCPv6.  These two mechanisms allow for the
   configuration of IPv6 addresses and a number of network parameters.
   While there is overlap in the parameters that can be configured via
   these two protocols, different implementations support only subsets
   of such parameters with either mechanism, or have no support for
   DHCPv6 at all.  This document analyzes a problem that arises from
   this situation, and mandates that all host implementations support
   RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6
   functionality in RFC 3315.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Sander Steffann <[email-masked]>
Date: Tue, 28 Feb 2017 11:13:34 +0100

Hi Fernando,

> Your feedback will be appreciated.

Good starting point for this discussion.

Thanks!
Sander

---

From: Erik Kline <[email-masked]>
Date: Tue, 28 Feb 2017 19:18:41 +0900

I oppose sneaking DHCPv6 as a MUST in this document:

   IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106],
   and the stateless DHCPv6 mechanism specified in [RFC3315].

No.

On 28 February 2017 at 17:13, Fernando Gont <[email-masked]> wrote:

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 07:27:53 -0300

Hello, Erik,

>    and the stateless DHCPv6 mechanism specified in [RFC3315].

May I ask the basis on which you opposed?

P.S.: Please not that we're not required the IA_NA part, but just
stateles part -- i.e., so that DHCPv6 can be employed to convey
additional configuration information (*not* addresses).

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

---

From: Erik Kline <[email-masked]>
Date: Tue, 28 Feb 2017 19:28:57 +0900

Because DHCPv6 of any form is not a host requirement (or at least not last
I checked).

---

From: [email-masked]
Date: Tue, 28 Feb 2017 11:33:49 +0100

Fernando,

Why wouldn't these changes go in the IPv6 node requirements document?

Ole

> On 28 Feb 2017, at 09:13, Fernando Gont <[email-masked]> wrote:
> 
> Folks,
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 28 Feb 2017 11:39:18 +0100

+1

I think the IPv6 node requirements is the right document to update with this.

For the router requirements part, the requirements in this document are already being required by RFC7048 and also in the –bis draft.

https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-01

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 28 de febrero de 2017, 11:33
Para: Fernando Gont <[email-masked]>
CC: IPv6 Operations <[email-masked]>
Asunto: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt)

    Fernando,

    Ole

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

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 07:42:32 -0300

Well, that's part of the reason for writing the I-D :-)

RDNSS is not part of router requirements, and we're requiring it on the
router side.

i.e., we want IPv6 networks to be able to provide DNS info in whatver
way they please, and for IPv6 hosts to be able to get such info.

Nowadays, yu generally can configure DNS info in DHCPv6, but hosts do
not even implement the stateless DHCPv6 part.

And there are networks in which folks want to provide DNS info with
RDNSS, but routers don't support it.

That's bad.

The current workaround is that folks end up relying on the DNS info
conveyed via DHCPv4. But that is not only bad, but also inadequate since
IPv4 is supposed to go away (eventually).

Thanks,
Fernando

On 02/28/2017 07:28 AM, Erik Kline wrote:
> Because DHCPv6 of any form is not a host requirement (or at least not
> last I checked).
> 
> On 28 February 2017 at 19:27, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hello, Erik,
> 
>     e-mail: [email-masked] <mailto:[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 07:46:15 -0300

> Why wouldn't these changes go in the IPv6 node requirements document?

I guess they could. But for timeliness sake, it's probably better to
tackle this problem in a very short and "to the point" document.

A possible rev of the node reqs is going to take waaaay longer to get done.

Thanks,

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 28 Feb 2017 11:53:12 +0100

I think today LANs must be dual-stack, if you want to avoid all kind or problems, so if the IPv6 node requirements take a bit extra time to update, should not be a problem, because you can use DNS with IPv4 on a dual-stack LAN.

That said, the RFC7084 states:
L-11:  The IPv6 CE router MUST support providing DNS information in
          the Router Advertisement Recursive DNS Server (RDNSS) and DNS
          Search List options.  Both options are specified in [RFC6106].

And of course, a router is a node, so:

   G-1:  An IPv6 CE router is an IPv6 node according to the IPv6 Node
         Requirements specification [RFC6434].

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Fernando Gont <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 28 de febrero de 2017, 11:42
Para: Erik Kline <[email-masked]>
CC: IPv6 Operations <[email-masked]>
Asunto: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt)

    

    
    That's bad.

    Thanks,
    Fernando

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 07:53:19 -0300

> I think the IPv6 node requirements is the right document to update with this.

Eventually it can be taken up by that document. Based on the number of
changes that are probably going to be applied to a bis of such RFC, that
one is not going to get done very timely, though.

Besides, we hope that this being an operations wg, the discussion can be
more pragmatic than religious.

> https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-01

That's one specific type of router.

Thanks,

---

From: [email-masked]
Date: Tue, 28 Feb 2017 11:56:27 +0100

Fernando,

> tackle this problem in a very short and "to the point" document.

In my not particularly humbler opinion we don't need yet another RPF style RFC.

> A possible rev of the node reqs is going to take waaaay longer to get done.

The revision of the node reqs is currently underway.
https://tools.ietf.org/html/draft-clw-rfc6434-bis-00

Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 08:04:48 -0300

On 02/28/2017 07:53 AM, JORDI PALET MARTINEZ wrote:
> I think today LANs must be dual-stack, if you want to avoid all kind
> or problems,

Actually, I've seen/read a lot of bragging about IPv6-only nets.
Including IPv6-only mobiles.

> so if the IPv6 node requirements take a bit extra time
> to update, should not be a problem, because you can use DNS with IPv4
> on a dual-stack LAN.

If an IETF IPv6 group's solution to an IPv6 problem is to rely on IPv4,
I'm afraid we'll have a hard time to be taken seriously by the folks
that we expect to deploy v6 (and by others, too).

Cheers,

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 28 Feb 2017 12:13:00 +0100

Yes, but the “only-IPv6” is the WAN link.

The LANs (and the apps) in the cellular network are dual-stack, by means of 464XLAT. If you don’t keep dual-stack “inside” the cellular device or LANs in a home/enterprise environment, many old applications stop working.

I agree that this is the target at the end, but we should not force it, because we don’t have the power to pay for the cost of all the users in the world to “upgrade” their apps and devices. I wish we could do it! I’m trying to be very pragmatic.

Regards,
Jordi

-----Mensaje original-----
De: Fernando Gont <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 28 de febrero de 2017, 12:04
Para: <[email-masked]>, IPv6 Operations <[email-masked]>
Asunto: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt)

    
    
    Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 08:14:59 -0300

> In my not particularly humbler opinion we don't need yet another RPF style RFC.

I wished we didn't, but the problem needs to get solved.

> https://tools.ietf.org/html/draft-clw-rfc6434-bis-00

<http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/rfc/rfc6434.txt&url2=https://tools.ietf.org/id/draft-clw-rfc6434-bis-00.txt>

It's great that this is going to happen, but it's gonna take ages.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 08:20:58 -0300

> Yes, but the “only-IPv6” is the WAN link.

See section "Testing has its challenges" of
<https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/>  -- that
should really be unacceptable for this group.

> I agree that this is the target at the end, but we should not force
> it, because we don’t have the power to pay for the cost of all the
> users in the world to “upgrade” their apps and devices. I wish we
> could do it! I’m trying to be very pragmatic.

We certainly should not force ipv6-only. That said, it should be
possible for folks to do it without having to deal with this kind of mess.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Feb 2017 12:23:44 +0100

>that we expect to deploy v6 (and by others, too).

For the node requirements document, I think it would be nice if we could add
something like 'hosts that implement DNS (stub) resolver functionality SHOULD
try to obtain a list of DNS resolvers using DHCPv6 if the O bit is set in
a Router Advertisement.'

For the people who want to run IPv6 only, it would be nice if they would
publish a BCP how their preferred solution handles DNSSEC local validation 
for IPv4 addresses.

My preferred solution for an IPv6-only backbone is that customer edge
routers (or in general any router that connects ordinary hosts) offers
dual stack in one form or another.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 28 Feb 2017 12:30:23 +0100

Just to be clear, I’m for what the document proposes, but not the way to do it, because is not realistic.

If you do IPv6-only today in the LAN, the problem you have is not the DNS, is not being able to access even local resources in your home or enterprise network. I agree is a target, but it can be aligned, in terms of time, with the update of the node requirements doc.

As said, it will be wonderful to throw away all the IPv4-only cameras, smart-TVs, etc, but is not going to happen, so suggesting to users to use IPv6-only in their LANs, is a very bad and unrealistic advice, and even if it will be very nice, we should target for that in 2-3 years from now (and probably will take even longer).

I prefer less documents even if they take a bit extra time (at least in this case), but more complete and talking more issues at the same time. In general I would agree on doing a short and quick document (for any urgent issue that the IETF needs to resolve) if it can be done in a matter of a couple of months because the world has a “real” problem and all the vendors will provide updates right now, etc., but I don’t think this is the case.

Regards,
Jordi

-----Mensaje original-----
De: Fernando Gont <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 28 de febrero de 2017, 12:20
Para: <[email-masked]>, IPv6 Operations <[email-masked]>
Asunto: Re: [v6ops] New I-D: SLAAC and DHCPv6 (Fwd: New Version Notification for draft-gont-v6ops-host-configuration-00.txt)

    

    Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 08:47:17 -0300

On 02/28/2017 08:30 AM, JORDI PALET MARTINEZ wrote:
> I prefer less documents even if they take a bit extra time (at least
> in this case), but more complete and talking more issues at the same
> time. In general I would agree on doing a short and quick document
> (for any urgent issue that the IETF needs to resolve) if it can be
> done in a matter of a couple of months because the world has a “real”
> problem and all the vendors will provide updates right now, etc., but
> I don’t think this is the case.

I'm not arguing in favor of IPv6-only. I'm saying that the current
situation wrt what is described in our I-D is really bad.

The quicker this is done, the sooner folks have a document to throw at
vendors to get this support implemented.

If we wait 2-3 years to get a rev of the node reqs rfc, *that* is when
folks will be able to *start to* ask vendors to get this support
implemented.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Feb 2017 23:06:53 +1100

> publish a BCP how their preferred solution handles DNSSEC local validation 

What issue to you see that needs a BCP because I can't see one.

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 Feb 2017 23:26:47 +1100

On 28 Feb. 2017 21:29, "Erik Kline" <[email-masked]> wrote:

So how do hosts get configured with more than DNS addresses and IPv6
addresses?

I'm not particularly fond of setting my devices real time clocks manually,
and in b dune environments, getting time from external NTP sources is going
to be unacceptable.

How can hosts be automatically configured with local time zone Information?

What about the many other useful parameters that can be configured with
DHCPv6 options?

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2

What alternative method is available and implementations commonly exist to
solve these sorts of problems if stateless DHCPv6 is not the solution?

Regards,
Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Feb 2017 21:32:51 +0900

> IPv4 is supposed to go away (eventually).

I would suggest:

   - When IPv4 goes away, replace DHCPv4 with stateless DHCPv6.
   - Until then, use RDNSS.

Stateless DHCPv6 is worse than RDNSS in many ways. Most importantly, it's
not suited to mobile nodes and unmanaged networks because:

   1. It's impossible to communicate quickly to hosts when something has
   changed, you have to wait for the hosts to ask again.
   2. Even if you crank the lifetimes to the minimum level, it's impossible
   to change anything more quickly than 10 minutes. See RFC 4242 section 3.1.
   3. On links where transmitting is expensive, such as wifi, it's more
   expensive to transmit a packet than to passively receive a multicast RA.

I don't see why we should require hosts to implement stateless DHCPv6. If
anything, we should require that they support RDNSS.

It's much easier to implement RDNSS than stateless DHCPv6 since all IPv6
nodes are required to support SLAAC and the amount of extra code to
implement RDNSS once you have a working SLAAC implementation is near zero.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Feb 2017 21:39:18 +0900

> should really be unacceptable for this group.

The thing that struck me the most about it is that an enterprise-class
router was able to send RAs but did not have support to send RDNSS options.
That's a completely trivial addition to the code. It's good that their
vendor built it.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Feb 2017 13:41:54 +0100

>What issue to you see that needs a BCP because I can't see one.

There seems to be a lot of thinking along the lines of 'we provide NAT64 and
DNS64 and that's it'. And then maybe some hand waving about hosts doing
464xlat or everybody fixing their code to not use IPv4 literals.

Note that we are talking about host requirements. Every setup where the CPE
does DS-Lite or MAP-E/MAP-T, etc. doesn't require host changes.

So if IPv6-only means no connection all to the IPv4 world, then it's fine.
But IPv6-only seems to be used in many contexts to imply NAT64.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 09:45:17 -0300

On 02/28/2017 09:32 AM, Lorenzo Colitti wrote:
> On Tue, Feb 28, 2017 at 7:42 PM, Fernando Gont <[email-masked]
>   * When IPv4 goes away, replace DHCPv4 with stateless DHCPv6.

Problem benig that not all host implementations support DHCPv6.

>   * Until then, use RDNSS.

Problem being that not all host implementations support RDNSS.

> Stateless DHCPv6 is worse than RDNSS in many ways.

Are you suggesting that we provide guidance on this topic? -- If so,
that'd be fine to me. -- So far, the current version of the doc just
aims at having  both options on the table. But I'd be fine with
providing guidance.

> Most importantly,
> it's not suited to mobile nodes and unmanaged networks because:
> 
>  2. Even if you crank the lifetimes to the minimum level, it's
>     impossible to change anything more quickly than 10 minutes. See RFC
>     4242 section 3.1.
> I don't see why we should require hosts to implement stateless DHCPv6.

1) so that for networks in which they want to convey DNS info in DHCPv6,
they can. Besides, DHCPv6 is isefull for all sorts of other information.

> If anything, we should require that they support RDNSS.

That was the intent (I was assuming the SHOULD in node reqs, but maybe
we should clarify this, and probably even raise the requirement to MUST)

> implement RDNSS once you have a working SLAAC implementation is near zero.

The intent is that nodes support both options. Hence, no matter what the
network employs to convey DNS info, the host is able to learn it.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 09:47:52 -0300

On 02/28/2017 09:39 AM, Lorenzo Colitti wrote:
> On Tue, Feb 28, 2017 at 8:20 PM, Fernando Gont <[email-masked]
>     <https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/
>     <https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/>>  -- that
> router was able to send RAs but did not have support to send RDNSS
> options. That's a completely trivial addition to the code. It's good
> that their vendor built it.

ast time I checked, their vendor *didn't* built it. Other folks have
reported that, when asking router vendors about RDNSS support, they
responded "we don't implement it, and we don't have any plans to do so".

That's why our doc requires router suppor for RDNSS, such that if that's
your preferred choice for conveying DNS info, you have the necessary
support in your router.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Feb 2017 14:42:07 +0100

> Because DHCPv6 of any form is not a host requirement (or at least not

I just checked and DHCPv6 is there by default on my windows office 
computer... hope not breaking something...

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Feb 2017 22:45:53 +0900

> Problem being that not all host implementations support RDNSS.

Actually, no problem. All implementations support DHCPv4, so for as long as
you run DHCPv4 with RDNSS things work. Then, when you replace DHCPv4 with
DHCPv6, all implementations support either DHCPv6 or RDNSS and things still
work.

> aims at having  both options on the table. But I'd be fine with

Personally I'm fine with providing guidance that all implementations should
support RDNSS, but a) I doubt we'll reach consensus, and b) I don't think
it will matter even if we do.

> they can.

"Hosts should do something so that networks can do what they want"? Is that
going to be sufficient motivation? The incentives don't seem to align very
well.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Feb 2017 22:46:38 +0900

On Tue, Feb 28, 2017 at 9:47 PM, Fernando Gont <[email-masked]>
wrote:

> ast time I checked, their vendor *didn't* built it.

They did build it. The article says "we are currently testing new code from
the router vendor which supports RDNSS".

---

From: Enno Rey <[email-masked]>
Date: Tue, 28 Feb 2017 15:06:02 +0100

Hi,

On Tue, Feb 28, 2017 at 02:42:07PM +0100, Alexandre Petrescu wrote:
> 
> 
> Le 28/02/2017 ? 11:28, Erik Kline a ?crit :

well, looking at https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/ it might actually be that the combination of DHCPv6 being enabled by default on Win systems and its current behavior leads to unexpected behavior in some networks...

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: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Feb 2017 15:26:40 +0100

> Including IPv6-only mobiles.

I would not call that bragging, and I understand the pride of people 
doing IPv6-only networks.  I share that.

However, I would be careful with statements that claim some smartphone 
devices do IPv6-only on an IPv6-only cellular network.  Just type 
ifconfing and route on them and IPv4 addresses show up.

> that we expect to deploy v6 (and by others, too).

I agree with you.

But let me show you otherwise too.

It depends how this IPv6-DNS-Server -in-RA,  or -in-DHCPv4, or 
-in-DHCPv6 is done; let me explain.

On an office network I am familiar with typing ipconfig /all showed me 
to my great surprise an IPv6 Address for the DNS Server.  I have no idea 
where it comes from: is it from DHCPv4?  Is it self-derived from an IPv4 
address?  After some digging I realize it comes from the IETF meeting! 
I only go there some every 4 months, but it got on my PC forever.  Is it 
normal?  Certainly not - it is a full error and IETF should stop 
configuring such an IPv6 address on my computer for more than the 
duration of the IETF meeting :-)  I dont care whether it is with RA or 
with DHCPv6, but must be conditioned by lifetime.

Also, another office network I am familiar with has no IPv6 support, but 
it has many Hosts that speak much IPv6 ("chatter") even though the 
routers dont forward to Internet.  These protocols are: ICMPv6, DHCPv6, 
MDNS, LLMNR, SSDP, HTTP, TCP.  Wireshark shows them.  They come from 
Macs, PCs and linuces.  To the IPv6 deployer this is a very encouraging 
sign - s/he doesnt have do anything and IPv6 is there :-)  But from 
other standpoints (e.g. security), this is far from normal, because we 
want this office network to be IPv4 only, at this time.   How can we get 
rid of these IPv6 messages? (remark this is an inverse problem to that 
of deploying IPv6).

Among these IPv6 protocols sitting there by default, using MDNS means 
there is no need for a DNS address (neither from DHCPv6 nor DHCPv4, nor 
from RA).  The DNS requests are sent to a dedicated mcast address, 
hoping someone will reply.  So, even if one wanted to deliver the IPv6 
DNS address to end users, maybe neither DHCPv6 nor DNS are needed, and 
MDNS would be sufficient.

Finally, RFC6106 does not offer a means for the Host to request the 
address of the DNS server, AFAIK (e.g. option in RS called 'request DNS 
address').  Whereas it should be the Host that should be answered, not 
imposed.  As such, it would be good if an RS requested the address of a 
DNS server.  RFC6106 doesnt, AFAIK.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Feb 2017 15:43:56 +0100

> On an office network I am familiar with typing ipconfig /all showed
> me to my great surprise an IPv6 Address for the DNS Server.  I have
> no idea where it comes from: is it from DHCPv4?  Is it self-derived
> from an IPv4 address?  After some digging I realize it comes from
> the IETF meeting!  I only go there some every 4 months, but it got
> on my PC forever.  Is it normal?  Certainly not - it is a full
> error and IETF should stop configuring such an IPv6 address on my
> computer for more than the duration of the IETF meeting :-)  I dont
> care whether it is with RA or with DHCPv6, but must be conditioned
> by lifetime.

If you have a mobile device, then if it moves to a different network it 
should flush (or at least validate) its network parameters.

Otherwise you would force everybody to use insanely short life times. Say
if you walk from the IETF meeting to a restaurant and your PC would still
try to use the addresses and resolvers it got at the meeting network.

> Also, another office network I am familiar with has no IPv6 support,
> but it has many Hosts that speak much IPv6 ("chatter") even though
> the routers dont forward to Internet.  These protocols are: ICMPv6,
> DHCPv6, MDNS, LLMNR, SSDP, HTTP, TCP.  Wireshark shows them.  They
> come from Macs, PCs and linuces.  To the IPv6 deployer this is a
> very encouraging sign - s/he doesnt have do anything and IPv6 is
> there :-)  But from other standpoints (e.g. security), this is far
> from normal, because we want this office network to be IPv4 only,
> at this time.   How can we get rid of these IPv6 messages? (remark
> this is an inverse problem to that of deploying IPv6).

Great, so the 'dentist office' scenario is actually working.

If you want to tell your systems that there is no IPv6, then you would have
to invent a DHCPv4 option for that. 

Most people consider it a feature that you can just connect a bunch of hosts
without infrastructure and it just works.

> Finally, RFC6106 does not offer a means for the Host to request
> the address of the DNS server, AFAIK (e.g. option in RS called
> 'request DNS address').  Whereas it should be the Host that should
> be answered, not imposed.  As such, it would be good if an RS
> requested the address of a DNS server.  RFC6106 doesnt, AFAIK.

RS is a Router Solicitation. Let's not abuse it even further. If you
want to solicit DNS information, send a DHCPv6 information request.

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Mar 2017 06:16:09 +1100

Hi,

> Your feedback will be appreciated.

OK!

First thought is that I think a different term than "SLAAC" should be
used, as SLAAC is just an address configuration method/mechanism that
uses RA PIO options (which is all that is described in RFC4862). It
doesn't configure anything else, so for SLAAC, the second part of this
sentence in the abstract isn't correct - "These two mechanisms allow
for the configuration of IPv6 addresses and a number of network
parameters."

What you're really mandating here is host support for and processing
of RA Recursive DNS Options and DNS Search List Options. They're from
the set of options that can be carried in RAs, and RAs are specified
in RFC4861, "Neighbor Discovery in IPv6".

I think I'd also be more specific in the description of the issue. I
read it as being general enough that it is implying that RAs and
DHCPv6 are equal mechanisms for configuring any of hosts' parameters,
where as really there are only two specific overlaps, and the specific
issues that are addressed in this draft exist because of these
specific overlaps:

- interface addresses

- DNS parameters

Inadvertently encouraging this view that RAs and DHCPv6 are equals
will only further encourage more options or capabilities to be
duplicated in either of them, creating more implementation confusion,
and requiring further drafts such as this. The problem will get worse
not better. If we cannot deprecate any of the conflicting methods, in
the least we can try to ensure this problem doesn't happen again.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Feb 2017 20:53:03 +0100

Hi,

> DHCPv6, all implementations support either DHCPv6 or RDNSS and things still

Real people are trying to build v6-only networks today, and run into
massive problems due to the combination of "one major OS vendor refuses 
to do stateless DHCPv6, and one major router vendor refuses to implement
RDNSS".  

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

Well done, folks.

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: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 17:41:21 -0300

Hello, Mark,

On 02/28/2017 04:16 PM, Mark Smith wrote:
> uses RA PIO options (which is all that is described in RFC4862).

SLAAC is more than that. Loo at the plethora of RA options that have
been specified --- including e.g. RIO and RDNSS

> It

Routes, DNS information...

> in RFC4861, "Neighbor Discovery in IPv6".

That said, if you can suggest an alternative title, please do.

> issues that are addressed in this draft exist because of these

We'll try to clarify this. That said, if you have specific suggestions
in that respect, please do let us know.

> the least we can try to ensure this problem doesn't happen again.

We tried to stay away from religious debates. Just note that DNS info
can be configured with both, and that the current state of affairs is a
mess.

Thanks,

---

From: james woodyatt <[email-masked]>
Date: Tue, 28 Feb 2017 12:51:16 -0800

On Feb 28, 2017, at 00:13, Fernando Gont <[email-masked]> wrote:
> 
> This document […mandates…] the stateless DHCPv6 functionality in RFC 3315.

This proposes a requirement for IPv6 host implementations that I have to oppose. My reasoning follows:

p1. Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to receive notifications that previously provided information has become invalid. It’s very important that hosts receive timely notifications when DNS server addresses are not valid anymore, otherwise they must rely on heuristics for detecting the difference between transient and persistent DNS server unavailability. These heuristics come with significant cost to user experience and should therefore be avoided. RDNSS provides this facility, whereas Stateless DHCPv6 does not.

p2. On networks where all the routers are sending RA messages with O flag cleared, I’d prefer that hosts weren’t constantly trying to discover undeployed DHCPv6 servers. On such networks, IPv6 addresses for DNS servers should only be available by manual configuration. This may, in fact, be a perfectly reasonable configuration for transitional dual-stack networks where DNS servers are only available automatically by IPv4 and not IPv6.

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 18:12:07 -0300

Hello, James,

On 02/28/2017 05:51 PM, james woodyatt wrote:
> On Feb 28, 2017, at 00:13, Fernando Gont <[email-masked]
> p1. Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to receive
> notifications that previously provided information has become invalid.
> It’s very important that hosts receive timely notifications when DNS
> server addresses are not valid anymore, otherwise they must rely on
> heuristics for detecting the difference between transient and persistent
> DNS server unavailability.

If your network has such a requirement, use RDNSS rather than SLAAC.

We're not mandating what you must *use*. Actually, we want to allow you
to make that choice. Right now, you can't. Because Google's Android
refuses to implement stateless DHCPv6, and MS Windows and a number of
router vendors refuse to implement RDNSS.

> p2. On networks where all the routers are sending RA messages with O
> flag cleared, I’d prefer that hosts weren’t constantly trying to
> discover undeployed DHCPv6 servers. On such networks, IPv6 addresses for
> DNS servers should only be available by manual configuration. This may,
> in fact, be a perfectly reasonable configuration for transitional
> dual-stack networks where DNS servers are only available automatically
> by IPv4 and not IPv6.

I beg to differ. It seems totally unreasonable to me that folks have to
resort to manual configuration (?!?) because two vendors are playing a
rather silly game for which the folks deploying IPv6 networks pay the price.

    "You each name yourselves king, yet the kingdom bleeds."
          -- George R.R. Martin: A Clash of Kings

Thanks,

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 28 Feb 2017 16:19:11 -0600

> p1. Stateless DHCPv6 [RFC 3315] lacks a mechanism for hosts to receive notifications that previously provided information has become invalid. It’s very important that hosts receive timely notificat…

A robust implementation might still want to rely on heuristics.  Updating 
a RDNSS server list especially with today's sad state of router configuration 
management likely means making configuration changes on every subinterface of 
every router.  So, this is realistically not going to happen except for
environments that have specifically automated this task.  Compare that 
to an environment that forwards all dhcp to a centralized cluster where 
a configuration change will be made in one spot.  I hope that helps
clarify an operational issues with this approach.

> p2. On networks where all the routers are sending RA messages with O flag cleared, I’d prefer that hosts weren’t constantly trying to discover undeployed DHCPv6 servers. 

Agreed.  Plus it chews up air time.

Dale

---

From: james woodyatt <[email-masked]>
Date: Tue, 28 Feb 2017 14:30:10 -0800

Hola Fernando,

On Feb 28, 2017, at 13:12, Fernando Gont <[email-masked]> wrote:
> We're not mandating what you must *use*. […]

That’s a very puzzling statement. Here’s exactly what your draft says would be Best Current Practice:

>>>> 3.  Requirements for IPv6 Hosts
>>>> 
>>>> IPv6 hosts MUST support the SLAAC DNS options specified in [RFC6106], and the stateless DHCPv6 mechanism specified in [RFC3315].

How is it possible to “support” RFC 3315 in a device that will never use it? I really want to know how I’m going to conform with this Best Current Practice in IPv6-capable host devices that my employers sell that never under any circumstances send a DHCPv6 Discover packet.

I was imagining that your MUST here amounts to saying that our IPv6-capable host devices MUST use RFC 3315 to obtain DNS server addresses whenever RA messages do not provide them in RDNSS options. That sounds like you’re mandating what we MUST do.

How am I misunderstanding?

> rather silly game for which the folks deploying IPv6 networks pay the price.

I agree that’s a bad situation, but I disagree that it’s a “silly game” — and I disagree that publishing this draft as Best Current Practice would be helpful. Indeed, I think it would entangle IETF itself in a very serious (and not at all silly) marketplace dispute in which IETF should take care— indeed, I can see how people might think IETF is explicitly chartered— to maintain neutrality.

If a vendor of host equipment refuses to implement RFC 6106, they are telling their customers that their systems are only suitable for use on the IPv6 networks where DHCPv6 is available. I don’t think publishing a BCP declaring such hosts non-conforming will change their minds. Those vendors clearly believe DHCPv6 should be a requirement for their customers despite IETF maintaining its optionality. Making it mandatory would be taking sides with these vendors.

Likewise, if a vendor of host equipment chooses to implement RFC 6106 and refuses to implement RFC 3315, they are telling their customers that their systems are suitable for use everywhere except on networks where hosts are required to implement DHCPv6 despite IETF maintaining that DHCPv6 is purely optional. Those vendors think DHCPv6 should remain optional just as current IETF standards and Best Current Practice explain. Making it mandatory would be taking sides against these vendors.

Shorter james: IETF should not take sides in this marketplace dispute.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Mar 2017 11:30:27 +1300

On 01/03/2017 10:12, Fernando Gont wrote:
...
> router vendors refuse to implement RDNSS.

This is the point. We are supposed to care about interoperbility, and
this is a breakage in interoperability specification, which has led to
breakage in real-world interoperability. Our bad.

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.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 19:45:18 -0300

Hola, James,  ;-)

On 02/28/2017 07:30 PM, james woodyatt wrote:
> Hola Fernando,
> 
> On Feb 28, 2017, at 13:12, Fernando Gont <[email-masked]
>>>>> IPv6 hosts MUST support the SLAAC DNS options specified in
>>>>> [RFC6106], and the stateless DHCPv6 mechanism specified in [RFC3315].
> 
> How is it possible to “support” RFC 3315 in a device that will never use
> it? 

If it's a host, whether you use it or not will depend on the network:
whether it does only SLAAC, stateful DHCPv6, or stateless DHCPv6.

So, in our case, what we want is that, if the network does stateless
DHCPv6, you (host) can do it.

Similarly, we want that if the network coveys DNS information in RDNSS
options, all hosts can learn that info from such options.

And that if you have a router impementation with SLAAC support, that it
is able to send RDNSS options.

We don't say (and don't want to) which of the possible options is the
most desirable. It's up to the network to decide what's the best model
for them. The goal is that, whatever an admin decides, he knows that all
attached systems will be able to learn DNS information.

> I really want to know how I’m going to conform with this Best
> Current Practice in IPv6-capable host devices that my employers sell
> that never under any circumstances send a DHCPv6 Discover packet.

Implement stateless DHCPv6. I you receive an RA with the O bit set,
query the network for config information.

> I was imagining that your MUST here amounts to saying that our
> IPv6-capable host devices MUST use RFC 3315 to obtain DNS server
> addresses whenever RA messages do not provide them in RDNSS options.

What we say is: If the RAs don't provide DNS information, and the O bit
is set, query additional config information via DHCPv6.

> I agree that’s a bad situation, but I disagree that it’s a “silly game”
> — and I disagree that publishing this draft as Best Current Practice
> would be helpful. Indeed, I think it would entangle IETF itself in a
> very serious (and not at all silly) marketplace dispute in which IETF
> should take care— indeed, I can see how people might think IETF is
> explicitly chartered— to maintain neutrality.

If an IPv6 deployment doesn't work 8as in this case), the talk is not
about neutrality, but about broken specs.

> If a vendor of host equipment refuses to implement RFC 6106, they are
> telling their customers that their systems are only suitable for use on
> the IPv6 networks where DHCPv6 is available. I don’t think publishing a
> BCP declaring such hosts non-conforming will change their minds. Those
> vendors clearly believe DHCPv6 should be a requirement for their
> customers despite IETF maintaining its optionality. Making it mandatory
> would be taking sides with these vendors.

RDNSS support is, one way or another, optional, too. It's a SHOULD on
the client side, and it's not even a SHOULD on the router side.

That's how we got to this sad state of affairs.

> Likewise, if a vendor of host equipment chooses to implement RFC 6106
> and refuses to implement RFC 3315, they are telling their customers that
> their systems are suitable for use everywhere except on networks where
> hosts are required to implement DHCPv6 despite IETF maintaining that
> DHCPv6 is purely optional. Those vendors think DHCPv6 should remain
> optional just as current IETF standards and Best Current Practice
> explain. Making it mandatory would be taking sides against these vendors.

We're taking sides with the ops people, because while these two vendors
have their fight, we need to rely on IPv4 for configuring DNS info.
That's really a shame.

Thanks!

Cheers,

---

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

> breakage in real-world interoperability. Our bad.

No.
That's way outside of IETF's role.

An example. I've got an open source implementation I'm working on of an IPv6 router. It does not support RDNSS. Would you think the IETF writing one more non-protocol specification document telling me that I'm stupid, change that?

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

Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 20:19:51 -0300

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

If you accept that there was a failure, and there is a problem, then you
should probably also accept that we should clean up the mess.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Mar 2017 13:28:59 +1300

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

     Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 11:00:34 +0900

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 11:03:44 +0900

On Wed, Mar 1, 2017 at 5:51 AM, james woodyatt <[email-masked]> wrote:
> notifications that previously provided information has become invalid. It’s
> very important that hosts receive timely notifications when DNS server
> addresses are not valid anymore, otherwise they must rely on heuristics for
> detecting the difference between transient and persistent DNS server
> unavailability. These heuristics come with significant cost to user
> experience and should therefore be avoided. RDNSS provides this facility,
> whereas Stateless DHCPv6 does not.
>

+1. It's possible to build non-heuristic solutions to this as well, (e.g.,
always send all queries to all DNS servers), but those cost in terms of
complexity, bandwidth, and battery life.

p2. On networks where all the routers are sending RA messages with O flag
> cleared, I’d prefer that hosts weren’t constantly trying to discover
> undeployed DHCPv6 servers.
>

+1. If nothing else, it's expensive for battery-powered hosts to do this.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 1 Mar 2017 01:07:56 -0300

On 02/28/2017 11:00 PM, Lorenzo Colitti wrote:
> On Wed, Mar 1, 2017 at 4:53 AM, Gert Doering <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> network from supporting both stateless DHCPv6 and RDNSS.

You did check the MS IPv6-only article I posted, right? That's a very
usual case: there's no RDNSS support in routers, and/or the clients
don't support RDNSS and/or the clients do not support DHCPv6.

> problem. Saying "networks should support both stateless DHCPv6 and RDNSS
> so that hosts can choose to implement only one" is another.

Huh? You want your client to be able to connect to any network. If you
have a client that cannot connect to a network because it fails to
implement X, that sucks. Android connecting to an IPv6 network that
employs stateless DHCPv6 is one of such cases.

Besides, you do want to be able to provide rich config info as in IPv4..
whether that's web proxies, or anything else.

Thanks,

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 Feb 2017 20:26:39 -0800

In my opinion having two ways of doing the same thing is generally a bad idea.
The fact that DNS configuration can be conveyed in both DHCPv6 and RA is unfortunate.
Declaring both as a MUST implement will only make this situation worse.
The IETF should either:
1) declare one option better and deprecate the other
2) stay out of this debate
Because of this, I strongly oppose this document.

David

> On Feb 28, 2017, at 20:07, Fernando Gont <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 1 Mar 2017 01:42:57 -0300

> 1) declare one option better and deprecate the other

They are simply different. In the same way that SLAAC is different than
DHCPv6.

> Because of this, I strongly oppose this document.

Oh, so this is like "Oh, yeah, we screwed up... but we're not going to
do anything about it".

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 Feb 2017 20:54:34 -0800

> On Feb 28, 2017, at 20:42, Fernando Gont <[email-masked]> wrote:
> 

More like "Oh, yeah, we screwed up... but we shouldn't make it worse"

Not to mention the fact that making something a MUST implement
will not make vendors implement it if they disagree. You'd be better
off convincing said vendors, and starting by explaining the benefits
of one approach over the other would be more useful than mandating
both. I couldn't find anything in the document explaining how one
option configures my DNS server address better than the other.

David

---

From: Fernando Gont <[email-masked]>
Date: Wed, 1 Mar 2017 02:09:58 -0300

> More like "Oh, yeah, we screwed up... but we shouldn't make it worse"

COuld you please explain how this document would make that worse?

> option configures my DNS server address better than the other.

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.

Thanks,

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 Feb 2017 21:29:08 -0800

> On Feb 28, 2017, at 21:09, Fernando Gont <[email-masked]> wrote:
> 

By perpetuating coexistence of multiple solutions to the same problem.

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

David

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Mar 2017 07:33:20 +0100 (CET)

> The fact that DNS configuration can be conveyed in both DHCPv6 and RA is unfortunate.

https://tools.ietf.org/html/rfc7710

"Captive-Portal Identification Using DHCP or Router Advertisements (RAs)"

I'd say generally here in the IETF, we commonly have more than 2 ways of 
doing the same thing, just look at routing protocols, tunneling protocols 
etc. Yes, having just one way is to be preferred, but it seems we rarely 
reach consensus on what this one thing is.

Personally I think ND and DHCPv6 has different properties which gives them 
separate SWOT analysis bullet points, and it seems different organisations 
value this differently. Some like DHCP because it means the part of the 
organisation that touches routers won't have to get involved when 
something that has to do with host configuration needs to be changed, 
because this is now changed by the DHCP backend people. Others sees this 
as a problem, because they're working the other way around.

What I like about having RA signal what's available on the link, is that 
we don't have DHCP clients asking questions without guidance, which is a 
good thing. See Sunset4. So people asking to get more functionality into 
DHCPv6, do they also see themselves running networks without RAs, thus 
requiring clients to forever ask DHCPv6 questions even if they get no 
answers?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Wed, 1 Mar 2017 02:56:33 -0300

> which one is best for their users?

Because you don't operate networks. And because nobody appointed vendors
to pick for users which networks they are supposed to be able to connect
to. If anything, implement it, and provide a toggle so that your users
can enable/disable features as they please.

If your choice means that there are networks that I cannot connect to,
then for me it represents a very lousy choice on your side.

> think the IETF should pick a side.

I am not. I couldn't care less about what is eventually employed to get
a DNS server address, as long as I get one.