Subject: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Jan 2017 15:37:08 +0000

Folks,

Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, but has made little progress in the last year. Therefore, it become necessary for the chairs to reevaluate whether this draft should continue to be a WG item.

If you have an opinion on this subject, please post it to the mailing list by 1/25/17. Options are:

1) Continue to work on the draft with an eye toward publication in 2017
2) Allow the draft to expire

Silence or limited response will be interpreted as a lack of interest in the draft.

                                            Ron, Lee and Fred

---

From: t.petch <[email-masked]>
Date: Wed, 11 Jan 2017 17:27:54 +0000

---- Original Message -----
From: "Ron Bonica" <[email-masked]>
To: "IPv6 Ops WG" <[email-masked]>
Sent: Wednesday, January 11, 2017 3:37 PM

> Folks,
>
> Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago,
but has made little progress in the last year. Therefore, it become
necessary for the chairs to reevaluate whether this draft should
continue to be a WG item.
> 1) Continue to work on the draft with an eye toward publication in
2017

  1b) Publish it as Historic

Tom Petch

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jan 2017 09:42:55 +1300

This draft describes real issues but the information is a bit out of date.
Can we ask the authors to confirm that things are still the same for current
o/s releases? Then publish quickly so that we can start the *real* discussion:
how to fix?

Regards
   Brian

On 12/01/2017 04:37, Ron Bonica wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> .
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 12 Jan 2017 02:08:07 +0000

Hi Brian,

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, January 12, 2017 4:43 AM
To: Ron Bonica; IPv6 Ops WG
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

This draft describes real issues but the information is a bit out of date.
Can we ask the authors to confirm that things are still the same for current o/s releases? 
[Bing] I think even if the latest OSes have been changed to have the same behavior, the problem is still existing, since some older versions (e.g. Window 7) might last for a long time. 
Anyway, if the WG still think the draft is worth to be published, then no problem for us to do the tests on the latest OSes and update the draft.

Best regards,
Bing

Then publish quickly so that we can start the *real* discussion:
how to fix?

Regards
   Brian

---

From: [email-masked]
Date: Thu, 12 Jan 2017 09:45:08 +0100

> o/s releases? Then publish quickly so that we can start the *real* discussion:

This draft shouldn't be gating any real discussion. If there are solutions please offer them now.

I have read through the draft again. While the draft has some points, these are issues that has been discussed extensively. I struggle to see how this will lead to and "fixes".

I have a suggestion. Given that we have beaten on this particular horse a lot over the last 15 years.
Could we redo this draft into a "Why?" draft in the style of RFC7421?
Explain the issues, explain the design choices and why the mechanisms function as they do, but don't phrase it as a problem that needs to be fixed.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 06:45:17 -0300

> 1) Continue to work on the draft with an eye toward publication in

I'm with option "1)" (publish)

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 06:47:01 -0300

On 01/11/2017 05:42 PM, Brian E Carpenter wrote:
> This draft describes real issues but the information is a bit out of
> date. Can we ask the authors to confirm that things are still the
> same for current o/s releases? Then publish quickly so that we can
> start the *real* discussion: how to fix?

I'd agree with Brian. -- but also please keep the data for the OS
releases/versions listed in the I-D. All of them are useful.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 06:51:36 -0300

Hi, Ole,

On 01/12/2017 05:45 AM, [email-masked] wrote:
>> This draft describes real issues but the information is a bit out
>> of date. Can we ask the authors to confirm that things are still
>> the same for current o/s releases? Then publish quickly so that we
>> can start the *real* discussion: how to fix?
> 

Noting the problem, and providing datapoints is useful, IMO.

> I have read through the draft again. While the draft has some points,
> these are issues that has been discussed extensively. I struggle to
> see how this will lead to and "fixes".
> 
> I have a suggestion. Given that we have beaten on this particular
> horse a lot over the last 15 years. Could we redo this draft into a
> "Why?" draft in the style of RFC7421? Explain the issues, explain the
> design choices and why the mechanisms function as they do, but don't
> phrase it as a problem that needs to be fixed.

The fact that you get different outcomes for different systems, setups,
etc., does not seem nice to me.

As to the why...I wonder if a "well, there's the slaac folks, and the
dhcpv6 folks..." document would be "publishable"..

Cheers,

---

From: Tim Chown <[email-masked]>
Date: Thu, 12 Jan 2017 15:03:08 +0000

Hi,

> On 11 Jan 2017, at 15:37, Ron Bonica <[email-masked]> wrote:
> 
> Folks,
> 

It’s tricky.

I do find myself referring people to this document as a problem statement, from time to time.  In that context, it’s useful. 

But as Ole says, while a number of ambiguities are noted, there are no “fixes” proposed.  

If the document is to be published, should we not make some recommendations?

If the Appendix is to remain, results for current OSes would be useful.

Tim

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Jan 2017 15:52:45 +0000

Hi:

I also wonder if there were some proposed “fixes”, perhaps they could be worked into the 3315bis (as they relate to DHCPv6). Even if we didn’t hit everything, improving things a bit is better than not at all? But this also might not be the best avenue at this time, given where we are with the 3315bis work. And, I certainly don’t want to start a long debate on the M&O bits.

Perhaps if the authors have a list of a few recommendations for what we might incorporate in the 3315bis document, we (coauthors and DHC WG) could review these and if there is sufficient consensus update the document accordingly?

See https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-06. (The coauthors are still working through our backlog of about 300 comments during WGLC – we have done about 75% of them.)

- Bernie

On 1/12/17, 10:03 AM, "v6ops on behalf of Tim Chown" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    It’s tricky.

    

    Tim

---

From: 神明達哉 <[email-masked]>
Date: Thu, 12 Jan 2017 09:54:34 -0800

At Wed, 11 Jan 2017 15:37:08 +0000,

> If you have an opinion on this subject, please post it to the mailing list by 1/25/17. Options are:

Re-reading my own comments on the previous WGLC
https://www.ietf.org/mail-archive/web/v6ops/current/msg24444.html
(it's about the 06 version, but the latest 07 version seems to be
almost identical to 06), I'd vote for

> 1) Continue to work on the draft with an eye toward publication in 2017

*IF* (I guess this is a very big one)

- we limit the scope of the doc to really practical issues.  I gave
  specific suggestions in my previous LC comments.  (I understand
  the definition of "practical" is completely subjective and others
  may have different definitions).
- (assuming we still keep the appendix) we include at least one other
  open source system than Linux (which would most likely be some
  variant of BSD)

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jan 2017 08:31:41 +1300

> etc., does not seem nice to me.

Yes, that *is* the problem. And, while I agree with Ole's points about how
to improve the document by making it more explanatory, I think documenting
the problem properly is necessary before proposing fixes.

> dhcpv6 folks..." document would be "publishable"..

That's a *different* document, and I think the issue there is what Randy
Bush mentioned recently on another list: we don't offer feature-equivalence
between DHCP and DHCPv6, but sites that rely on DHCP operationally want
feature-equivalence, and they are the customers, and customers are always
right.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 16:48:58 -0300

El 12/1/2017 16:31, "Brian E Carpenter" <[email-masked]>
escribió:

> Hi, Ole,

[...]

Agreed.

I.agree here, too. I've talked to at least a few operators and they don't
understand why they can't get a dhcpv6 that does the same job as dhcpv6 --
even less why, in practice, they have to resort to doing dhcpv6 + slaac
(both!)

Cheers,
Fernando

---

From: t.petch <[email-masked]>
Date: Fri, 13 Jan 2017 12:01:06 +0000

----- Original Message -----
From: "Fernando Gont" <[email-masked]>
Sent: Thursday, January 12, 2017 9:47 AM

> releases/versions listed in the I-D. All of them are useful.

I suggested publishing it as Historic because:
- it gives a good description of the behaviour of Windows 7 which has
been replaced in many respects by Windows 10 (much as that release is
disliked) so I cannot see the document as current without coverage of
Windows 10
- I do not see the authors having the energy to do the work on Windows
10 - the impression I got from this list is that their energy started to
flag in 2014.

Tom Petch

---

From: "Liubing (Leo)" <[email-masked]>
Date: Sat, 14 Jan 2017 02:06:24 +0000

Hi Tom,

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of t.petch
Sent: Friday, January 13, 2017 8:01 PM
To: Brian E Carpenter; Ron Bonica; IPv6 Ops WG; Fernando Gont
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

----- Original Message -----
From: "Fernando Gont" <[email-masked]>
Sent: Thursday, January 12, 2017 9:47 AM

I suggested publishing it as Historic because:
- it gives a good description of the behaviour of Windows 7 which has been replaced in many respects by Windows 10 (much as that release is
disliked) so I cannot see the document as current without coverage of Windows 10
- I do not see the authors having the energy to do the work on Windows
10 - the impression I got from this list is that their energy started to flag in 2014.
[Bing] We made an essential update on 05 version (June 2015), then the document was stalled and the last two versions were keep-alive. 
But if the WG would like to move forward it, we'd be glad to update the test of the latest OSes.

Best regards,
Bing

Tom Petch

---

From: "Liubing (Leo)" <[email-masked]>
Date: Sat, 14 Jan 2017 04:16:02 +0000

Hi Bernie,

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, January 12, 2017 11:53 PM
To: Tim Chown; Ron Bonica
Cc: IPv6 Ops WG
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Hi:

[Bing] I think the "fixes" is mostly regarding to ND/SLAAC, since M&O is in RA msg. However, there are two cases described in the draft that might need DHCPv6 to nail down the behavior:
- When there is no RA msg
We saw some Linux just "lazy", where there's no RA, there is no DHCPv6; we also saw some other OS (Window 8.1) "diligent", the DHCPv6 client just started at the beginning regardless of RA msg.
But from practical perspective, "no RA" is invalid according to current standards, since DHCPv6 cannot configure default route. However, considering future development of DHCPv6, maybe it's good to clearly specify that the DHCPv6 client MUST start if there is no RAs for some time (e.g. 30s, or even shorter). 
- When M transition from 1 to 0
We saw Windows 7 immediately releasing the DHCPv6 address; we also saw Linux just ignore the transition. Windows 7's behavior is bad. I think DHCPv6 might need to explicitly abandon this behavior.

Apart from these specific behaviors. One general comment is: which module in the OS is responsible for monitoring the M&O bits? If it is the DHCPv6 module, then we can decide the prescript behaviors in DHC WG, since as the M&O defined in current standard, it is only a "hint". But if it is in some other module in the OS, the DHCPv6 can just do some bottom line like the above mentioned specific behaviors.

Best regards,
Bing

- Bernie

    Hi,

    It’s tricky.

    

    Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Jan 2017 00:17:15 +0900

I'm not a fan of the document in its current form. I think the data on how
various operating systems behave is useful and fits well within the charter
of this working group.

However, I agree with Ole that I don't think there will be any "fixes"
here. I'm not even sure there is a problem to fix. Unspecified behaviour is
unspecified, and as an administrator, if you want predictable behaviour
then you either stick to things that are clearly stated by the standards or
you educate yourself on the behaviour of the various implementations that
you support.

I'm not sure that having two configuration protocols that overlap for IP
addresses and DNS servers is a problem in itself, either. There are lots of
areas where we have multiple solutions. OSPF and ISIS, LLDP and RSVP, etc.
etc.

On Thu, Jan 12, 2017 at 12:37 AM, Ron Bonica <[email-masked]> wrote:

> Folks,
>
> Draft-ietf-v6ops-dhcpv6-slaac-problem was introduced 3.5 years ago, but
> has made little progress in the last year. Therefore, it become necessary
> for the chairs to reevaluate whether this draft should continue to be a WG
> item.
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Jan 2017 19:28:33 -0300

On 01/16/2017 12:17 PM, Lorenzo Colitti wrote:
> I'm not a fan of the document in its current form. I think the data on
> how various operating systems behave is useful and fits well within the
> charter of this working group.
> 
> here. I'm not even sure there is a problem to fix. Unspecified behaviour
> is unspecified, and as an administrator, if you want predictable
> behaviour then you either stick to things that are clearly stated by the
> standards or you educate yourself on the behaviour of the various
> implementations that you support.

Sorry, but: Isn't that the whole point of standardization?

If you're deploying IPv6, you're suppose to support IPv6, not specific
implementations. And if you have to learn about specific
implementations, that seems to me as an indication that we're doing a
por job when it comes to specs.

> addresses and DNS servers is a problem in itself, either.

The main problem is that there is a *partial overlap* when it comes to
functionality, and at times no overlap when it comes to OS support.

Reality is that if you want to support *IPv6*, you have to do *both*
SLAAC and DHCPv6. Otherwise, there's a major OS that you're not
supporting. And that's bad.

> There are lots
> of areas where we have multiple solutions. OSPF and ISIS, LLDP and RSVP,
> etc. etc.

The analogy is not good. You're not required to do both OSPF and ISIS to
get your multi-vendor network working.

Thanks,

---

From: Fred Baker <[email-masked]>
Date: Mon, 16 Jan 2017 16:36:50 -0800

> On Jan 16, 2017, at 2:28 PM, Fernando Gont <[email-masked]> wrote:
> 
> poor job when it comes to specs.

</hats>

The problem is that any real world deployment is not the deployment of a standard, but the deployment of a set of products that claim to implement it. 

To understand the difference, presume that there exist 100 different implementations, of which you select 7 to put into your network. Maybe that's iOS, Android, MacOS, Windows, Cisco, Juniper, and OpenSourceProject#12. Maybe there's someone else, whoever. Now, imagine that they all claim to implement the standard, but implement some specific feature differently and incompatibly, and in the deployed configuration, that feature isn't in use. Maybe they all implement SLAAC, some do DAD and some don't, and some do a retry on DAD - but address allocation is being done using DHCP, so SLAAC isn't ever invoked. Or only some do DHCP, but SLAAC is in use. Or whatever.

The fact that the network works using N-1 features satisfies you as an operator - your network works. You may not even notice the feature difference, or the fact that you use a different feature that does work is your solution for the fact that the given feature doesn't.

The fact that the feature, whatever it was, was implemented differently may be a specification issue. It may also be an issue with the reader of the specification, or the origin of the chipset, or something else. 

But you didn't deploy a specification. You deployed a set of products that claimed conformance to the specification, and demonstrated it to some degree in your testing.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Jan 2017 10:23:23 +0900

> por job when it comes to specs.

Fred answered this very well.

> supporting. And that's bad.

I disagree. Products already have to support multiple protocols at the same
time. If you want to support wifi you might have to support all of WEP, WPA
PSK and WPA enterprise. If you want to offer access to the Internet you
have to support IPv4 and IPv6. And so on.

> get your multi-vendor network working.

That's true only if all your chosen vendors support your chosen protocol.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 Jan 2017 17:50:51 -0800

On 1/16/17 5:23 PM, Lorenzo Colitti wrote:
> On Tue, Jan 17, 2017 at 7:28 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I disagree. Products already have to support multiple protocols at the
> same time. If you want to support wifi you might have to support all of
> WEP, WPA PSK and WPA enterprise. If you want to offer access to the
> Internet you have to support IPv4 and IPv6. And so on.

You might also have to support two bands and 5 modulation schemes in the
interest of backwards compability. Or you  might selectively elide the
ones that are only required for legacy device support or which are so
new that only a limited nuber of devices support them, in favor of a
common subset supported by current modern devices.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 17 Jan 2017 03:13:31 +0000

Hi Dear all,

Thanks for all your comments.

While reading through the mails, my impression is that the WG seems still have some interest of this draft. Although there is still controversy, I think we also have a chance to get consensus.
So, my proposed next step of the draft is:

1) Re-phrase the document to make it more like a report and caution of current divergent behaviors, rather than stating "problems". 
I think most of the texts could be kept, but with a different tone. The divergence analysis and the OSes behaviors are objective; whether it is a "problem" is subjective. In this document, we just keep a neutral position. 
In this sense, I would request to change the draft name as e.g. "draft-ietf-v6ops-dhcpv6-slaac-implementation-divergence"
If in the future we all agree it is "Problem", then we can make a new draft discussing the fixes.

2) Update the test to include the latest versions of main stream OSes, and also include another OpenSource OS other than Linux (e.g. FreeBSD).

I will do step 1) first within this week, and ask the WG for review. If we can get consensus, then we'll do step 2).
Does it sound ok?

Thanks.

Best regards,
Bing

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 00:15:39 -0300

On 01/16/2017 09:36 PM, Fred Baker wrote:
>> If you're deploying IPv6, you're suppose to support IPv6, not
>> specific implementations. And if you have to learn about specific 
>> implementations, that seems to me as an indication that we're doing
>> a poor job when it comes to specs.
> 
> </hats>
> 
> The problem is that any real world deployment is not the deployment
> of a standard, but the deployment of a set of products that claim to
> implement it.

Of course. Now, if product A says it supports IPv6, and Network A says
it supports IPv6, I expect to be able to use product A in Network B.

If both can truly say they support IPv6, but they cannot interoperate
(*), then something is missing in the spec.

(*) in this case, I expect my host to, at the very least, be able to
learn a default route and caching DNS server, and automatically
configure an IPv6 address.

> To understand the difference, presume that there exist 100 different
> implementations, of which you select 7 to put into your network.
> Maybe that's iOS, Android, MacOS, Windows, Cisco, Juniper, and
> OpenSourceProject#12. Maybe there's someone else, whoever. Now,
> imagine that they all claim to implement the standard, but implement
> some specific feature differently and incompatibly, and in the
> deployed configuration, that feature isn't in use.

I expect the spec to specify what are the features that are required to
get "(*)". And if in order to get "(*)" I now need to deploy two
different protocols, that most likely need to be configured in different
places, with different outcomes based on e.g. implementation, I think
that's bad (particularly when it was previously possible to get
essentially the same thing with a single protocol).

This increases complexity & attack surface, etc.

[...]
> The fact that the network works using N-1 features satisfies you as
> an operator - your network works. 

That's the point: If I have to deploy two different protocols because
need both of them to support the three major OSes, I don't think that's
good. And If I actually have to figure that out by myself, that's worse.

Frankly, I cannot quite understand the discussion here, particularly
when this group produced e.g. RFC6540 -- but I might be missing something.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jan 2017 09:04:14 -0500

Fernando, another way to approach the question would be to ask, if there is a single protocol that is required (which there is), and that protocol can provide all the information that a host needs to interoperate on the network, is implementation of another protocol that duplicates some, but not all, of that functionality actually sensible?

IOW, you seem to be focusing on the failure of some IPv6 stacks to implement one protocol, but not on the failure of other IPv6 stacks to fully implement one of the protocols they support.   If your problem is that you want it to be the case that there is a minimum set of functionality that can be deployed on a particular network in order for all hosts to interoperate, then it doesn't matter which of these problems gets solved, as long as one or the other is solved.   And in that case, I would expect to see you arguing for both, hoping to win one.

But I only see you arguing for one solution to this problem, and it is the one that requires hosts to implement two protocols, rather than the one that requires hosts to fully implement one protocol.   Can you say why you prefer the two-protocol solution?

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 11:58:48 -0300

Hi, Ted,

On 01/17/2017 11:04 AM, Ted Lemon wrote:
> Fernando, another way to approach the question would be to ask, if
> there is a single protocol that is required (which there is), and
> that protocol can provide all the information that a host needs to
> interoperate on the network, is implementation of another protocol
> that duplicates some, but not all, of that functionality actually
> sensible?

Phrased that way, the answer is obviously "No".

However,

1) RDNSS was standardized not such a long time ago (should double-check,
but..) after pro-dhcpv6 vendors had already implemented DHCPv6.

2) At this point it is probably too late to answer the question, but:
Not sure it buys much to the guy deploying v6 "just to get more
addresses" to have to learn a whole different way of doing things
(slaac). In that sense, I understand those folks meaning to stick to slaac.

> IOW, you seem to be focusing on the failure of some IPv6 stacks to
> implement one protocol, but not on the failure of other IPv6 stacks
> to fully implement one of the protocols they support.

To make my point clear: I don't care about what's the winner in "slaac
vs. v6", but I'm just concerned about having to deploy both because I
cannot support the two/three major OSes with a single protocol.

> If your
> problem is that you want it to be the case that there is a minimum
> set of functionality that can be deployed on a particular network in
> order for all hosts to interoperate, then it doesn't matter which of
> these problems gets solved, as long as one or the other is solved.

Exactly.

> But I only see you arguing for one solution to this problem, and it
> is the one that requires hosts to implement two protocols, rather
> than the one that requires hosts to fully implement one protocol.
> Can you say why you prefer the two-protocol solution?

I don't. I don't care about what specific protocol I can use, as long as
I can use one to support all my hosts (e.g., having Windows and others
support RDNSS off-the-shelf works for me.. and if there's a way to help
things in that direction (make such support a MUST), I'm game).

That said, I have also heard complaints from quite a few ISPs deploying
IPv6 regarding why they can't just do dhcp, and have to do something
else to essentially get the same thing as in IPv4 (they only wanted
longer addresses, not learn new fancy stuff). And in that sense, their
concerns seem understandable, too. So in that respect, at this point,
rather than fighting over a specific way to configure hosts (with the
current outcome of "you have to do both!"), I'd probably try to make
things easier/simpler for folks deploying v6, give them the two
protocols as fully-working *options*, and let them decide by themselves
whatever works better for them.

Cheers,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jan 2017 10:38:35 -0500

> but..) after pro-dhcpv6 vendors had already implemented DHCPv6.

It's been a little over six years, and there have been quite a few Windows releases since then, so we can I think safely conclude that if a vendor has not implemented it, it's not because they didn't have an opportunity to do so.

> (slaac). In that sense, I understand those folks meaning to stick to slaac.

This may or may not be true, but doesn't seem relevant to the draft being discussed.

> things in that direction (make such support a MUST), I'm game).

Well, right now it's RECOMMENDED in RFC 6434.   I suppose we could update the RFC to say REQUIRED, but it's hard to understand why an implementation would choose to ignore this recommendation if there weren't some specific reason for doing so, so it might be worth asking the vendors that don't implement RDNSS why they have chosen not to.

> whatever works better for them.

Here I do not believe you are talking about RDNSS.   It sounds like you are saying "why can't some nodes simply _not_ implement SLAAC."   This is very far afield for a discussion of this particular document.   If you want to propose such a thing, you might want to start a separate discussion.

---

From: [email-masked]
Date: Tue, 17 Jan 2017 17:03:05 +0100 (CET)

> but..) after pro-dhcpv6 vendors had already implemented DHCPv6.

We recently asked Huawei about RDNSS for their NE40 series routers.
The answer we got was basically "Not implemented, no specific plans to
do so."

DHCPv6 is a must for us.

Steinar Haug, AS2116

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Jan 2017 03:52:43 +1100

> The answer we got was basically "Not implemented, no specific plans to

I don't really understand why there seems to be a belief that DNS is
the only host parameter that needs to have automated configuration,
and therefore RDNSS is the only thing that is needed. Hosts have other
parameters that may need to be set such as NTP source, timezone etc.

RDNSS has other limitations, such as not being able to do or easily do
individual host specific DNS settings, and not being able to have a
centralised parameter source - if you want to change the DNS value
provided by RDNSS by 10000 routers, you have no choice by to change
the configuration of 10000 routers.

DHCPv6 is more capable, flexible and general purpose.

(I'm not making the assertion that if you use DHCPv6 then you must use
it for addresses. That's a choice available, however I would use SLAAC
for addresses and stateless DHCPv6 for the other upper layer host
parameters.)

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Jan 2017 04:33:07 +1100

> concerns seem understandable, too.

I think it is a generational thing.

There is a generation of network engineers who've only known and been
taught IPv4(+NAT). They would like IPv6 to be as close as possible to
IPv4 because that is what they're familiar with. They won't have seen
other layer 3 protocols, and how some of them were easier to operate
and configure because they were developed after IPv4.

(If I think about the operational and usability goals IPv6 should
have, they're mainly set by my IPX and Appletalk experience, not my
IPv4 experience.)

The generation after will learn both IPv4(+NAT) and IPv6. They'll just
accept more than one layer 3 protocol is necessary and that they work
differently, as my generation did when we ran IPv4 as well as IPX,
Appletalk etc. They'll do IPv6 the IPv6 way.

This "IPv4+NAT only" generation will only last for a short period in
the life of IPv6. We should be careful not to hobble IPv6 to suit
their relatively limited world view.

> So in that respect, at this point,

Choice isn't always a good thing, in particular when the choices are
very similar or  appear to be very similar. That can result in choice
paralysis, were it is safer not to make a choice than deal with the
consequences of making a bad or incorrect choice.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 13:05:07 -0300

On 01/17/2017 12:38 PM, Ted Lemon wrote:
>> 1) RDNSS was standardized not such a long time ago (should
>> double-check, but..) after pro-dhcpv6 vendors had already
>> implemented DHCPv6.
> 
> It's been a little over six years, and there have been quite a few
> Windows releases since then, so we can I think safely conclude that
> if a vendor has not implemented it, it's not because they didn't have
> an opportunity to do so.

Agreed.

[....]
>> I don't. I don't care about what specific protocol I can use, as
>> long as I can use one to support all my hosts (e.g., having Windows
>> and others support RDNSS off-the-shelf works for me.. and if
>> there's a way to help things in that direction (make such support a
>> MUST), I'm game).
> 
> Well, right now it's RECOMMENDED in RFC 6434.   I suppose we could
> update the RFC to say REQUIRED, but it's hard to understand why an
> implementation would choose to ignore this recommendation if there
> weren't some specific reason for doing so, so it might be worth
> asking the vendors that don't implement RDNSS why they have chosen
> not to.

"Well, I like dhcpv6 and you like slaac. You don't implement my dhcv6
thing, I will not implement your slaac thing" or some version of it.

>> That said, I have also heard complaints from quite a few ISPs
>> deploying IPv6 regarding why they can't just do dhcp, and have to
>> do something else to essentially get the same thing as in IPv4
>> (they only wanted longer addresses, not learn new fancy stuff). And
>> in that sense, their concerns seem understandable, too. So in that
>> respect, at this point, rather than fighting over a specific way to
>> configure hosts (with the current outcome of "you have to do
>> both!"), I'd probably try to make things easier/simpler for folks
>> deploying v6, give them the two protocols as fully-working
>> *options*, and let them decide by themselves whatever works better
>> for them.
> 
> Here I do not believe you are talking about RDNSS.   It sounds like
> you are saying "why can't some nodes simply _not_ implement SLAAC."

Actually, they were complaining "why we can't just do dhcp(v6) as we do
in IPv4?"

> This is very far afield for a discussion of this particular document.
> If you want to propose such a thing, you might want to start a
> separate discussion.

I wouldn't. I'm more in the camp of doing something to push RDNSS and/or
get fully-working DHCPv6. I guess that for the same religious war we
still don't have a default-route option in dhcpv6, so I guess the easier
option would be to push rdnss (if doable).

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 14:43:50 -0300

> I think it is a generational thing.

I think it's a *human* thing. Humans like familiar things, particularly
when they want to do exactly the same thing they do with what they are
familiar with.

> consequences of making a bad or incorrect choice.

What we currently have is essentially the worst possible outcome: have
to provide duplicate information in two different protocols if you want
to support, say, Android & Windows.

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Tue, 17 Jan 2017 14:07:53 -0800

At Tue, 17 Jan 2017 03:13:31 +0000,

[...]
> I will do step 1) first within this week, and ask the WG for review. If we can get consensus, then we'll do step 2).

Personally, one of the main issues of dhcpv6-slaac-problem is not
about behavior-only vs problem description, but that it talks about
(seemingly) random topics most of which don't seem (to me) to have
practical importance.  Of course, what is important and what is not is
quite subjective, so it's not surprising if some other people consider
most/all of the topics are important.  But my impression from the past
and current discussion of the draft is that it's at least not only me.

In this sense, just focusing on describing the random behaviors does
not sound okay to me.  What I want to see is to have some level of
consensus on what is important and practical and focus on them.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Jan 2017 09:30:02 +1100

>> if a vendor has not implemented it, it's not because they didn't have

So the problem used to justify RDNSS was that a stateless DHCPv6
client was too heavy weight for low powered / embedded devices. That
sounded reasonable at the time, however the more I've since thought
about it, the more I think that justification is false. If a device
doesn't have the resources to implement a stateless DHCPv6 client
(i.e., implement just the parts of the DHCPv6 protocol required to
handle parameters, but not address assignment/IA_* options), then it
probably is too low end to be implementing IPv6. CPU and memory is
always getting increasingly cheaper.

RDNSS was never intended to be an alternative to stateless DHCPv6 for
devices that aren't resource constrained.

I'm now have the opinion that RDNSS really shouldn't exist, and the
resulting confusion between using DHCPv6 or RAs for DNS information
was also predictable and predicted.

More broadly, why do people think DNS settings are the only ones a
host needs? I don't understand that, and, for example, don't enjoy
manually setting clocks on devices, so don't see why devices shouldn't
also be provided with NTP server addresses, timezone addresses, and
possibly many of the other options that DHCPv6 supports.

Android is an interesting case. I'm happy with it using SLAAC for
addresses, however I'd like it to support stateless dhcpv6 so that I
can e.g., supply it with NTP server addresses, timezone information
etc. I think that sort information is being "acquired" from other
sources, such as the mobile network for time/timezone and embedding in
firmware well known services that Google themselves provide e.g., DNS.
A reasonable motivation is that if these services are provided locally
and are performing badly, the end-user would assign blame to
Google/Android rather than the provider of the badly performing
underlying service.

Regards,
Mark.

<snip>

---

From: Sander Steffann <[email-masked]>
Date: Tue, 17 Jan 2017 23:54:28 +0100

Hi,

> Op 17 jan. 2017, om 18:43 heeft Fernando Gont <[email-masked]> het volgende geschreven:
> 

When giving IPv6 training this is always the point where I get strange looks from my students. If there is one thing that gives my enterprise customers the feeling that IPv6 is not ready for production then this is it. I can explain to them that all the protocols that they need for their deployment are available, but the fact that there are multiple ways for "the network" to tell the device which settings to use and different behaviour of devices in response to that (thanks for that research Enno!) astonishes them. This is the reasons I fear the addition of provisioning a default gateway with DHCPv6: even more diverging behaviour between different (versions of) implementations.

I personally don't mind which protocol provides what. I can see different ways to run a network that all make sense but require different tools and protocols. I would actually like something like:
- provide all options in both RA and DHCPv6 (embed non-IA DHCPv6 options in RA?)
- if you want to multicast settings to all devices, use RA
- if you want per-device settings, use DHCPv6
- if an option is provided by both RA and DHCPv6, prefer DHCPv6 (more specific)

This would allow a device to implement handling those options once independent of which protocol provided them, and define behaviour when the options contradict each other. And operating systems that don't implement DHCPv6 can still receive the options in the RA. Want to support exceptions to the settings from the RA: use DHCPv6. In such a situation I wouldn't mind having a DHCPv6 option for the default gateway, maybe some devices need a different gateway. At least it would be clear how to implement it, and no "competing" ways of doing things and religious battles that confuse people. One set of options with two complementing ways to distribute them would be so much nicer.

It's getting late. Maybe I should go to bed and dream about an IPv6 internet without religious battles there ;-)

Cheers!
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jan 2017 11:57:07 +1300

On 18/01/2017 05:52, Mark Smith wrote:
...
> DHCPv6 is more capable, flexible and general purpose.

Indeed. When campus network operators and ISPs tell us unambiguously,
as they do, that they require feature equivalence between DHCP for IPv4
and DHCP for IPv6, we would be incredibly arrogant to ignore them.

> for addresses and stateless DHCPv6 for the other upper layer host

Many campuses want to use DHCPv6 for address assignment, however.
(That doesn't mean banning SLAAC, though apparently some do that too.)

On 18/01/2017 06:33, Mark Smith wrote:
...
> their relatively limited world view.

Agreed, but feature-equivalence for DHCPv6 doesn't do that. The great
thing about SLAAC is that it works very well *without* DHCPv6 in
simple deployments. But unless we extend RAs to supply every parameter
that DHCP can supply, DHCPv6 *will* be used in most large networks.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Jan 2017 10:29:16 +1100

> Many campuses want to use DHCPv6 for address assignment, however.

So I am always interested to know what problem they're trying to solve
then they say that. I expect it is address use/auditability for
security purposes. I then wonder if they've put in place companion
measures to prevent hosts from using addresses configured statically,
or measures to prevent an entirely new prefix being brought up on the
link by hosts via static configuration, that won't be recorded in the
DHCPv6 address database.

> that DHCP can supply,

Agree, that's what we want to avoid.

> DHCPv6 *will* be used in most large networks.
>

What I'm not understanding is a seemingly common belief that DNS is
the only parameter that needs to be configured on general purpose
hosts, therefore only RDNSS is necessary, and therefore all hosts
should support RDNSS.

This is even though RDNSSs functionality is so limited compared to
stateless DHCPv6, that the moment you need to deploy automated
configuration of anything else, you're going to have to deploy (at
least stateless) DHCPv6. If you deploy stateless DHCPv6 in the first
place for DNS, you avoid issues and limitations that RDNSS has, and
you can easily add providing other DHCPv6 supported parameters such as
NTP at a later time.

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Jan 2017 15:41:43 -0800

On Jan 17, 2017, at 3:29 PM, Mark Smith <[email-masked]> wrote:
> then they [want to use DHCPv6 for address assignment]. I expect it is address use/auditability for

Something I have heard proposed, but I don't know the current details of, is to freeze the neighbor cache in a router. Instead of asking the router to send a neighbor solicit when it receives a message for an unknown address, have it drop the message or forward it to a security device. To that end, a host might use IEEE 802.1X to associate a MAC address with an IP address (or two), and let something associated with the 802.1X service configure the router with the neighbor entry, or trigger it to do an NDP lookup.

That has limits, of course; devices can communicate on-link without the router. But the router can filter sessions in various ways.

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Jan 2017 15:41:51 -0800

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Jan 2017 10:51:52 +1100

> It's getting late. Maybe I should go to bed and dream about an IPv6 internet without religious battles there ;-)

So none this is religious, or if people participating are being
religious, then they shouldn't be participating. Engineering is
supposed to be about being objective, and debating and weighing up the
pros and cons of various options. Implementing every option every
where to try to provide everybody with their favourite method
("provide all options in both RA and DHCPv6") just creates complexity,
confusion, more code to write and more things that can break.

I think when a discussion like this gets to this point, it is worth
revisiting the problem or problems being solved.

I think there are two problems to be/being solved:

- providing hosts with specific link layer 3 parameters, meaning
parameters that may be incorrect, irrelevant and unrelated on a
different link, and shouldn't be made available on a different link
(if the values are the same across different links, they are different
instances of the values that happen to be the same value)

- providing hosts with upper layer parameters that are not specific to
and independent of the link the host is currently attached to

RA options, with exception to the RDNSS options, all solve the first
problem, and it is right that a local device attached to the link
provides the parameters for the link. Address assignment is a link
specific subset problem, so providing link layer specific parameters
to suit address generation/assignment on the link is also solving this
problem.

DHCPv6 options, with exception to the IA_NA/IA_TA options, all solve
the second problem, and since they're not link specific, and can be
host specific, it means that regardless of where the host attaches, it
isn't a requirement that the device providing them resides on the same
link as the host, as long as the configuration request messages from
the host can reach the configuration server (which we solve with an
on-link DHCPv6 relay).

DHCPv4 conflated these separate problems, however I think that is a
consequence of the evolution of address and host configuration for
Internet hosts. This conflation is being carried across to IPv6
because of familiarity, even though IPv6 has mostly and in my opinion
correctly treated the two problems as separate ones.

Somewhat related, the SLAAC/IPX method/model using link-layer
addresses as layer 3 host addresses looks to be the original IPv4
model - see RFC796 - "ADDRESS MAPPINGS", "Internet to Local Net
Address Mappings". That fits with solving a link specific layer 3
addressing problem local to the link where the problem exists. We
probably really only ended up with DHCPv4 for address assignment
because IPv4 addresses weren't big enough to carry useful amounts or
the whole of the Ethernet address, unlike the link-layer addresses
described in RFC796. The ARP RFC seems to allude to this:

"However, the 10Mbit Ethernet
requires 48.bit addresses on the physical cable, yet most
protocol addresses are not 48.bits long, nor do they necessarily
have any relationship to the 48.bit Ethernet address of the
hardware.  For example, CHAOS addresses are 16.bits, DOD Internet
addresses are 32.bits, and Xerox PUP addresses are 8.bits."

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 22:35:25 -0300

On 01/17/2017 07:30 PM, Mark Smith wrote:
> client was too heavy weight for low powered / embedded devices. 

Should could the lines of code, spec pages but... ND seems to be on the
same order of complexity, at the very least.

> That

+1

>From that pov, things are getting even worse: wasn't there a proposal do
do kind of DHCPv6-PD with RAs?

> host needs? 

I guess the feeling is not that they are the only ones, but that to
quite an extent, they are kind of as basic as having an IPv6 address.

> can e.g., supply it with NTP server addresses, timezone information

Yes, it fails to implement DHCPv6.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 22:42:11 -0300

Hi, Brian,

+1

> (That doesn't mean banning SLAAC, though apparently some do that too.)

Same thing for DHCPv6. And have a hard time at understanding the current
mess.

> that DHCP can supply, DHCPv6 *will* be used in most large networks.

Feature equivalence would probably be the best option. But at the very
least, I wished we had a default route option for IPv6, and RDNSS in all
ND implementations.

Thus, a large network where DHCPv6 is employed to provide all sorts of
information can get all devices to work. I find it hard to call
"IPv6-enabled" a devices that connects to such network and cannot talk.

Cheers,

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 18 Jan 2017 02:45:38 +0000

Hi Jinmei,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 神明達哉
Sent: Wednesday, January 18, 2017 6:08 AM
To: Liubing (Leo)
Cc: IPv6 Ops WG; [email-masked]
Subject: Re: [v6ops] Possible consensus of dhcpv6-slaac-problem draft

[...]
> I will do step 1) first within this week, and ask the WG for review. If we can get consensus, then we'll do step 2).

Personally, one of the main issues of dhcpv6-slaac-problem is not about behavior-only vs problem description, but that it talks about
(seemingly) random topics most of which don't seem (to me) to have practical importance.  
[Bing] I don't quite understand what you said "random topics" mean. This document is actually focusing on a very specific topic - the ambiguity of the M/O flags, and the divergent behaviors caused by the ambiguity.
We had a (as much as we could did) comprehensive analysis of the ambiguity possibilities from the early versions drafts. And we observed divergence on each of the possibilities. So, personally I don't think the draft is discussing something randomly.

Of course, what is important and what is not is quite subjective, so it's not surprising if some other people consider most/all of the topics are important. 
But my impression from the past and current discussion of the draft is that it's at least not only me.
[Bing] There were several people don't agree the "problems" discussed in this document were "really problems". I understand it is not easy to get consensus.
But I also have an impression that people in general think it's good to record and publish the ambiguity and the divergent behaviors.

In this sense, just focusing on describing the random behaviors does not sound okay to me.  
What I want to see is to have some level of consensus on what is important and practical and focus on them.
[Bing] As you said, what is important and what is not is quite subjective. So why not we just keep the objective fact and let the readers/administrators decide according to their specific situation.

Regards,
Bing

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Jan 2017 13:48:05 +1100

> do kind of DHCPv6-PD with RAs?

I think there was at one stage.

The fundamental motivation to try to use RAs (or more generally, a
single and deployed protocol) for everything is understandable.
However at some point it is trying to use the protocol far beyond what
it was designed for. It's less understandable when there is already a
protocol that can do it and that just needs to be deployed if
necessary. The effort to update and deploy the later version of the
existing protocol is going to be similar if not more than deploying
the existing and available protocol that solves the problem.

> quite an extent, they are kind of as basic as having an IPv6 address.

The conversations I come across tend to seem to be saying RDNSS
instead of saying RDNSS + stateless DHCPv6 if necessary to supply more
parameters. In other words, the view point seems to be RDNSS only,
which is why it seems people are implying that DNS is the only
necessary configuration parameter. (I don't think RDNSS + stateful
DHCPv6 is a good option either - just use stateful DHCPv6 in the first
place and be done with, just that if people said that, then it makes
it clear they understand that host automated configuration involves
more than just DNS.)

> Yes, it fails to implement DHCPv6.

One thing I'm careful to do is to qualify whether I'm talking about
stateless or stateful DHCPv6, because one is a much simpler subset of
the other.

I would like Android to have a stateless DHCPv6 implementation, so
parameters such as DNS, NTP, timezone etc. can be set on it. I don't
really care if it has a stateful DHCPv6 implementation, because I
don't think it is properly solving the tracking/auditing problem
people think it is. If a stateful DHCPv6 implementation doesn't exist,
then people will look for another solution to their tracking/auditing
problem (such as scraping ND cache entries, or using 802.1X to record
a better and more accurate end-user identity that can then be mapped
to a set of arbitrary L2/L3 addresses that may change over time as
Fred mentioned), and that solution will probably more effectively
achieve their tracking/auditing goal.

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jan 2017 22:07:32 -0500

On Jan 17, 2017, at 9:48 PM, Mark Smith <[email-masked]> wrote:
> parameters such as DNS, NTP, timezone etc. can be set on it.

Why would you trust an unauthenticated local network service to configure your phone's NTP server and timezone?

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Jan 2017 14:43:49 +1100

On 18 Jan. 2017 14:07, "Ted Lemon" <[email-masked]> wrote:

Why would you trust an unauthenticated local network service to configure
your phone's NTP server and timezone?

Some networks I would trust to set that, others I wouldn't.

Trusting mobile networks to set that can be an issue; my home town is one
of the two places in the world with a 1/2 hour timezone, and every few
years they seem to send out bad time for a while, usually at around the
daylight savings cut over. When I'm at home I'd like to have my phone use
my NTP server over other sources time sources I don't operate.

Accessing an external service provides them with identity and other
information for the transaction even if it is valid for a relatively short
period of time (e.g. temporary addresses used to access a NTP service on
the Internet). Being able to use a locally operated version of that service
mitigates that.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Jan 2017 16:04:43 +0900

> their relatively limited world view.

Couldn't agree more. I think it falls on those of us who do have a more
expanded world view, and who are more familiar with IPv6, to point out the
advantages brought by that model and to avoid hobbling that model to match
a worldview that evolved to support a protocol with different
characteristics.

> > whatever works better for them.

... except that when you do that, inevitably some percentage of the
population ends up choosing the familiar choice, and there's a risk that
all implementations collapse to the lowest-common denominator.

Example: just yesterday we were talking to colleagues who were implementing
and showcasing an SDN controller for use on client networks. There was a
desire to support both IPv4, dual-stack, and IPv6-only with NAT64.

It turned out that the design of the system did not allow creating a
neighbour cache entry (or ARP cache entry) on the basis of a data packet
sent to a given IP address. The only way that the network could communicate
with a new IP address was if that IP address had previously sent a control
packet - specifically, a DHCPv4 or DHCPv6 request. They decided to do this
in IPv6 based on the observation of DAD packets, but of course, that's not
reliable.

We told them that a router must fundamentally have the ability to learn
ARP/ND cache entries without snooping because that behaviour is specified
by the standards. We also explained that SLAAC allows hosts to create new
addresses at any time, that current hosts do this to create new privacy
addresses, and that this provides many benefits. Those arguments carried no
weight; their response was, "why can't we just use DHCPv6".

In the end, the argument that convinced them to implement ND cache learning
(which, obviously a fundamental part of how ND works) was that Android
would does not support DHCPv6, and they wanted to support Android.

I think we need to recognize the fact that current implementations, even in
IPv4, are based on assertions that are fundamentally coupled to the current
IPv4 way of doing things. Technically, the design was incorrect even in
IPv4, because even in IPv4 the routers are supposed to be able to send ARP
requests for unknown IPv4 addresses. But because IPv4 is virtually only
deployed with DHCP these days, they chose not to support anything else.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Jan 2017 16:16:19 +0900

> DHCPv6 is more capable, flexible and general purpose.

In many ways it actually isn't more capable. In particular,

   - It is very difficult or impossible to change anything. In theory,
   there's reconfigure. In practice, nobody implements that, even when it is
   mandatory. (In the immortal words of Steven Barth, lead OpenWRT developer,
   "home gateways are supposed to MUST" implement reconfigure.) In contrast,
   RAs are fundamentally dynamic.
   - It is very difficult to have multiple sources of information. In
   theory it's possible to get multiple OFFERs and select more than one of
   them, but I think common clients don't implement this.
   - It is impossible to add a new source of information once the client
   has a lease, because there's no push mechanism. Even if reconfigure were
   implemented, which it isn't, only the original server can reconfigure
   because it's the only one that the client trusts. RAs
   - If the server crashes or is unplugged, there is no way to update the
   client because only the server can reconfigure the client.

All these make DHCPv6 a rather bad idea for networks that change without
advance warning, such as home networks.

The only reason we don't have these problems in IPv4 is that in IPv4 we
have NAT (which means the clients never need to change their IP address on
demand) and VRRP. It would be nice not to need NAT, at least.

---

From: [email-masked]
Date: Wed, 18 Jan 2017 08:36:45 +0100 (CET)

>    them, but I think common clients don't implement this.

Having multiple OFFERs is normal if you run DHCPv4 with failover. Yes,
a small percentage of clients have problems. Most of them don't.

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Jan 2017 16:46:55 +0900

> a small percentage of clients have problems. Most of them don't.

The fact that the client gets multiple OFFERs is irrelevant. What matters
is whether it can accept more than one of them. IIRC in DHCPv4, this is not
possible at all, because the client signals acceptance of a particular
address by broadcasting a REQUEST, and that REQUEST implicitly declines all
the other OFFERs.

In DHCPv6 it might be possible, but even if it is, I doubt that common
clients implement it.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 18 Jan 2017 14:10:39 +0000

> So the problem used to justify RDNSS was that a stateless DHCPv6 client was
> too heavy weight for low powered / embedded devices. That sounded
> reasonable at the time, however the more I've since thought about it, the
> more I think that justification is false. If a device doesn't have the resources
> to implement a stateless DHCPv6 client (i.e., implement just the parts of the
> DHCPv6 protocol required to handle parameters, but not address
> assignment/IA_* options), then it probably is too low end to be
> implementing IPv6. CPU and memory is always getting increasingly cheaper.

There is a large movement for very constrained IoT devices to only support IPv6 (no IPv4). 
Barbara

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 Jan 2017 10:30:54 -0800

At Wed, 18 Jan 2017 02:45:38 +0000,

> We had a (as much as we could did) comprehensive analysis of the
> ambiguity possibilities from the early versions drafts. And we
> observed divergence on each of the possibilities. So, personally I
> don't think the draft is discussing something randomly.

I meany by "randomly" that it consists of important and non-important
divergent behaviors.  I thought I specifically explained these in my
latest review comments for the draft.

BTW, I guess trying to be "comprehensive" is actually one major reason
why I cannot be so enthusiastic about the current content of the
draft.  IMO this exact attempt makes the draft look "random".

> But I also have an impression that people in general think it's good to record and publish the ambiguity and the divergent behaviors.

I don't deny some other people might think even just describing
"random" behaviors is a good thing.  I just personally disagree with
that position, since it will result in a much less useful document
after spending a lot of wg energy.  IMO it's worse than not publishing
it at all.

> [Bing] As you said, what is important and what is not is quite subjective. So why not we just keep the objective fact and let the readers/administrators decide according to their specific situation.

Again, I personally don't think it a good idea.  But I'm just one
ordinary wg participant without any vito power or anything.  You don't
necessarily have to convince me if you can reach a wg rough consensus
without my support.

If I were the author, I'd step back and focus on one obviously
"important" point: coexistence of SLAAC and address assignment by
DHCPv6 isn't possible in some cases, and very carefully add other
points if and when we have a greater consensus that they are
operationally important.  But perhaps you'd rather be "comprehensive"
and don't like the idea - in that case, I think we just have to agree
to disagree.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Thu, 19 Jan 2017 06:17:13 +1100

Hi,

> There is a large movement for very constrained IoT devices to only support IPv6 (no IPv4).

I wouldn't have even thought anybody would have been considering IPv4,
as as far as I'm aware, all the work on resource constrained networks
has been done for IPv6 (e.g., ROLL, 6lowpan groups etc.)

The question is that if a host is so resource constrained that it
can't run a stateless DHCPv6 client, is it actually capable of running
a compliant IPv6 stack? I wouldn't think so, so I don't think the
justification for RDNSS is really valid.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jan 2017 13:51:14 +1300

On 19/01/2017 07:30, 神明達哉 wrote:
...
> draft.  IMO this exact attempt makes the draft look "random".

Could this be fixed by separating the issues into "major" and "minor"?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jan 2017 14:01:27 +1300

On 18/01/2017 12:29, Mark Smith wrote:
> security purposes. 

So I understand. If they are using an IPAM* tool that was developed around
DHCP, *not* using DHCPv6 for address management becomes a problem in itself,

*IPAM = IP Address Management

> I then wonder if they've put in place companion

Typically they will pre-register MAC addresses and police accordingly,
because that keeps unauthorised devices off the network, which is the
main goal.

But this *can* be combined with SLAAC (the University of Auckland is a
running example, and I'm sure there are many others), and there are
IPAM tools that play nice with SLAAC. The challenge is sites that
*want* to use DHCPv6 (and are not going to take any notice if the
IETF sulks).

> link by hosts via static configuration, that won't be recorded in the

Well, that would be a problem with SLAAC too, wouldn't it? I'd expect
any such prefix to be blocked by the first router it came to.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jan 2017 14:06:42 +1300

On 18/01/2017 20:16, Lorenzo Colitti wrote:
...
> advance warning, such as home networks

I hope nobody is disputing that. But when enterprise network operators
tell us the DHCPv6 is a rather good idea for their planned and managed
networks, we need to listen, I think.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jan 2017 14:13:25 +1300

On 19/01/2017 08:17, Mark Smith wrote:
...
> justification for RDNSS is really valid.

I don't think that computes. Every kB less matters and every code path
that doesn't consume battery matters. Also, I get the impression that
mDNS is very popular in such nodes, so maybe they don't need RDNSS
at all.

The justification for RDNSS was one level up from IoT: simple home
networks, cafe networks, etc. only need SLAAC and RA, but they do need
a DNS server.

    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 19 Jan 2017 02:50:21 +0000

Hi Jinmei,

> Sent: Thursday, January 19, 2017 2:31 AM
> To: Liubing (Leo)
> practical importance.
> > [Bing] I don't quite understand what you said "random topics" mean. This
> document is actually focusing on a very specific topic - the ambiguity of the
> M/O flags, and the divergent behaviors caused by the ambiguity.
> 
> divergent behaviors.  I thought I specifically explained these in my latest
> review comments for the draft.
> 
> BTW, I guess trying to be "comprehensive" is actually one major reason why I
> cannot be so enthusiastic about the current content of the draft.  IMO this
> exact attempt makes the draft look "random".

[Bing] Ok, I get your point.

> > Of course, what is important and what is not is quite subjective, so it's not
> surprising if some other people consider most/all of the topics are
> important.
> > [Bing] There were several people don't agree the "problems" discussed in
> this document were "really problems". I understand it is not easy to get
> consensus.
> > But I also have an impression that people in general think it's good to
> record and publish the ambiguity and the divergent behaviors.
> 
> I don't deny some other people might think even just describing "random"
> behaviors is a good thing.  I just personally disagree with that position,
> since it will result in a much less useful document after spending a lot of wg
> energy.  IMO it's worse than not publishing it at all.
> 
> > What I want to see is to have some level of consensus on what is
> important and practical and focus on them.
> > [Bing] As you said, what is important and what is not is quite subjective. So
> why not we just keep the objective fact and let the readers/administrators
> decide according to their specific situation.
> 
> Again, I personally don't think it a good idea.  But I'm just one ordinary wg
> participant without any vito power or anything.  You don't necessarily have
> to convince me if you can reach a wg rough consensus without my support.

[Bing] Since you had an explicit position, your opinion may more or less impact the draft. So, if we can get consensus, I think we more or less step towards WG rough consensus.
If we can't, at least we need to eliminate misunderstandings. E.g. I misunderstood your argument about "random".

> If I were the author, I'd step back and focus on one obviously "important"
> point: coexistence of SLAAC and address assignment by
> DHCPv6 isn't possible in some cases, and very carefully add other points if
> and when we have a greater consensus that they are operationally
> important.  But perhaps you'd rather be "comprehensive"
> and don't like the idea - in that case, I think we just have to agree to
> disagree.

[Bing] Thanks for this constructive suggestion. I think the ambiguity analysis needs to be "comprehensive"; but not necessarily the operational divergence.
As Brian suggested in another thread, do you think it may help the draft more readable if we separate the operational divergence into "Major" and "Minor"?

Best regards,
Bing

---

From: Sander Steffann <[email-masked]>
Date: Thu, 19 Jan 2017 10:50:04 +0100

Hi Mark,

> pros and cons of various options.

Thanks, well said.

> Implementing every option every

That's a valid concern. I suggested using the same options for both RA and DHCPv6 exactly for this reason: to keep things simpler. With the current direction things seem to be moving to I'm afraid we're going to end up with different options for DNS, NTP, default gateway etc in both protocols, and that would be really bad.

> the host can reach the configuration server (which we solve with an

That's not always true. For example the NTP server advertised though DHCPv6 might only be reachable from that specific link. Same for DNS servers, AFTR, MAP settings and other options. So there are definitely exceptions.

I love the original model of RA for network stuff and stateless DHCPv6 for everything else. For new people it took some getting used to, but it was a clear conceptual model. But for example the push for RDNSS and DHCPv6 default gateway, DS-Lite and MAP options shows that there is a demand for more diversity in both directions.

So maybe we should take a step back and think about the conceptual model again. That's all I'm suggesting. I think having two different protocols (RA and stateless DHCPv6) that are starting to overlap more and more is a bad thing. Maybe it's time to see if we can define a new conceptual model where we combine the two...

Is there really such a difference between layer-3 settings (RA) and layer-4+ settings (DHCPv6) that we need to keep those protocols separate? Or do we need one set of protocols for layer-3+ with both a multicast-push model (RA) and a unicast-pull model (DHCPv6)? It's a different conceptual model, so it's not something that can/should be changed lightly. On the other hand the layer3/4+ distinction seems to be fading already.

But I think it's really important that we revisit this, and rather sooner than later. I personally am perfectly fine with the original model, but I also see (mostly) enterprises that seem to push for the other model and maybe that isn't so bad and we should embrace that and make it official so we can make it consistent...

Cheers,
Sander

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 19 Jan 2017 07:43:36 -0500

> link by hosts via static configuration, that won't be recorded in the

Yes, we use DHCP Snooping, Dyanamic ARP Inspection, IP Source Guard,
and strict Unicast Reverse Path Filtering to make sure no one can
bypass the address assignments made by the DHCPv4 server.  We probably
would have deployed IPv6 by now if we could solve the address use
auditability challenges.

We've mostly given up on the dual-stack DNS synchronization idea and
will probably accept that the IPv6 address(es) assigned for non-server
hosts will not have any AAAA or PTR records, even though we do provide
A and PTR records for all IPv4 addresses on all hosts.

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 19 Jan 2017 08:28:36 -0500

>    RAs are fundamentally dynamic.

And yet we've been willing to live with that limitation in DHCPv4.  We
set lease times appropriately and know that we have to plan ahead for
any necessary changes by lowering lease times in advance, etc.  There
is also the fact that many devices will do a DHCP transaction upon
link status change, so often that can be used as a way to cause them
to reconfigure.

My understanding is that RAs also have a lifetime field and one would
run into the same type of advance planning requirement there as well.

>    them, but I think common clients don't implement this.

Wait, wouldn't this be a benefit?  The draft under discussion points
out the problems with having overlapping information.

>    client because only the server can reconfigure the client.

So?  If the router (which runs RA) crashes, the client can't even get
out of the subnet.  You can have multiple DHCP servers for redundancy,
just as you can have multiple routers for redundancy.  There is a
failover protocol defined for DHCPv4 and the DHCPv6 one is in
progress.

> advance warning, such as home networks.

Fine, but that doesn't mean we should ignore enterprise networks.

> demand) and VRRP. It would be nice not to need NAT, at least.

My enterprise IPv4 network has never run NAT and we don't have these
problems in IPv4.  We've needed to change IP addressing information on
many occasions and managed to do this with just DHCPv4.  Maybe it is
precisely because we don't run NAT that we are having such a difficult
time accepting the lack of functionality in IPv6.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Jan 2017 23:18:13 +0900

> link status change, so often that can be used as a way to cause them

But you still can't change things in a non-disruptive way at any time. You
have to wait for the hosts to ask again, or disrupt their connectivity. An
example of what you can't do is tell the host that some of its addresses is
now unable to reach the Internet, such as you might want to do if you do
multihoming without BGP and one of the uplinks goes down.

> run into the same type of advance planning requirement there as well.

No, you can update information at any time by sending a new RA.

> Wait, wouldn't this be a benefit?

It only works at all if there is a central configuration authority in the
network. This is not the case in a home network which has uplinks to two
different ISPs.

> The draft under discussion points

Overlapping information is a problem if there are conflicts. If the
information received by the host is the same regardless of the method it
receives it through, the end result is the same.

> out of the subnet.

But you can a new router online can come online and continue to provide
service. You can't do that with DHCP because nothing can change until the
lease expires or there's a disruption.

>   You can have multiple DHCP servers for redundancy,

Actually, the situation is not so much that you *can* have multiple
servers. The situation is that if you want redundancy, you *have to* have
multiple servers that have to talk to each other, because the client will
pick one. Again, that works in a very actively managed network, but not in
a

> Fine, but that doesn't mean we should ignore enterprise networks.

The assertion was that DHCPv6 is a superior protocol. I'm pointing out that
in several ways it's actually not a very good one, and that a lot of us
don't even see those ways because we simply take for granted that a
client-pull model based on fix lease times is the the only way clients
obtain network configuration.

> time accepting the lack of functionality in IPv6.

So you provide end-to-end-connectivity over IPv4? Wow. That practice is
sadly mostly consigned to the past; most networks can't afford it any more.
So consider this: if you want end-to-end, and you want connectivity that's
robust in the face of ISP outages, then you have exactly two choices: 1.
ensure the host's IP address never changes (e.g., by doing BGP
multihoming), or 2. ensure that you can change the host's IP address when
its previous IP address is no longer reachable.

#1 works great if you can afford it, but it doesn't scale because typically
the way we do it is BGP. If you can't do #1, then you need a way to change
hosts's IP addresses without advance notice when something bad happens. You
can't do that via DHCP. If you use RAs, you can simultaneously announce and
use two prefixes, and when one of them stops working, you can deprecate it
immediately.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 19 Jan 2017 16:49:53 +0100

In your letter dated Thu, 19 Jan 2017 10:50:04 +0100 you wrote:
>So maybe we should take a step back and think about the conceptual model 
>again. That's all I'm suggesting. I think having two different protocols 
>(RA and stateless DHCPv6) that are starting to overlap more and more is 
>a bad thing. Maybe it's time to see if we can define a new conceptual 
>model where we combine the two...

The problem I see is that lack of a standards track RFC that basically says
'a host MUST implement support for both SLAAC and statefull DHCPv6'

That's where we went wrong. No idea if we can fix it. 

How a network is configured should upto the local network and system
administrators. Leaving out support for either of SLAAC of DHCPv6 in a host
makes life hard for no reason.

In the past tiny devices had no problem implementing DHCP for IPv4. To the
extend that SLAAC and stateless DHCPv6 require extra code, that's a pity. 
But it is not that much code that it warrants creating the current complexity 
where networks have to support both DHCPv6 and SLAAC.

---

From: Gert Doering <[email-masked]>
Date: Thu, 19 Jan 2017 17:05:14 +0100

Hi,

> makes life hard for no reason.

This brings, what, 50+? mails nicely to the point.

(And for a change, I agree with Philip, though that should maybe read
"SLAAC+RDNSS" up there, given that really everybody supports *SLAAC* today)

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: Chuck Anderson <[email-masked]>
Date: Thu, 19 Jan 2017 11:52:48 -0500

> use two prefixes, and when one of them stops working, you can deprecate it

Okay, so all your arguments above are working under the assumption
that RA-based site multihoming can actually work in the real world.
There are many practical problems with that approach.  Ironically, a
possible solution is identified RFC7157, which requires DHCPv6.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 19 Jan 2017 16:59:22 +0000

While I probably shouldn't send this as it is in the political and not technical space, I frankly am very disappointed in one company that, while trying to promote IPv6 usage, has also worked very hard to limit its use by NOT supporting a protocol developed by the IETF.

I'm also surprised that organizations haven't pushed harder to get that company to implement the standards. I suspect though that is because IPv6 is not yet "critical" for deployment. This provides the company an opportunity to push their agenda (whatever it may be).

I will admit that being DHC WG co-chair, coauthor of the some of the standards, and also a vendor does bias me.

- Bernie

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Jan 2017 02:08:07 +0900

> that RA-based site multihoming can actually work in the real world.

It is the only way to do PA-based multihoming without NAT and BGP.

> possible solution is identified RFC7157, which requires DHCPv6.

Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to go.

---

From: Sander Steffann <[email-masked]>
Date: Thu, 19 Jan 2017 18:24:34 +0100

Hi Lorenzo,

> Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to go.

Thanks for the reference, that's an interesting read that points out where we can improve things to make multihoming using PA addresses without NAT nice to use. And not just in enterprise environments.

Cheers,
Sander

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Jan 2017 02:42:34 +0900

Bernie,

have you read RFC 7934? It lists a number of reasons why it is not
recommended for networks to support only DHCPv6 address assignment via
IA_NA.

I don't think DHCPv6 in itself is a problem. While it does suffer from the
limitations I outlined in my earlier message, it is flexible and extensible
to way more information than RAs can carry. It's also widely supported. But
I really think IA_NA is not appropriate for IPv6 assignment, for the
reasons that the authors and the WG outline in RFC7934.

Unfortunately, for many, decades of operational familiarity and vendor
support with IPv4 networks, where the only way to get an IP address (and
only ever ONE address) was DHCP, make it very hard to think of any other
address assignment mechanism. SLAAC is regularly dismissed as outlandish
and insecure, /64 subnets as wasteful, and the insistence that IPv4 and
IPv6 demand different link-addressing practives as religion. "Why can't we
just use DHCP", as an earlier message put it. Unfortunately the truth is
much more complex than that.

If the Internet is eventually to reap the full benefits of IPv6, then we as
a technical community and as an industry need to give a chance to a new
addressing model where hosts can use as many IPv6 addresses as they need.
Right now, that means SLAAC. The fact of the matter is that it SLAAC's
security properties are not substantially worse than IA_NA, and anyone who
says differently should read RFC 7934 section 9.1, of which I have not yet
seen any rebuttal, convincing or otherwise. And as for /64s being wasteful
- you saw the earlier messages in this conversation that asserted that
prefixes cost money or they are hard to obtain, when in fact the cost is
orders of magnitude lower than one cent, and RIR policies ere extremely
liberal?

It would be extremely easy to simply carry over practices that we have in
IPv4 to IPv6. But because applications are incentivized to add application
complexity in order to work properly on all networks, there is a risk that
we might get stuck there, and never be able to elevate ourselves out of
those practices. If that happens will keep suffering the problems caused by
IP address scarcity even after scarcity is banished. That would be a bad
outcome.

Of course I may be wrong and a one-address-per-host model is the right
choice. But I don't think we can tell at the moment. Over the years,
network administrators that learn about IP (and application developers that
write applications) on dual-stack networks with a mix of SLAAC and DHCPv6
will be able to make better choices between these protocols than we can
today.

Cheers,
Lorenzo

On Fri, Jan 20, 2017 at 1:59 AM, Bernie Volz (volz) <[email-masked]> wrote:

> While I probably shouldn't send this as it is in the political and not
> technical space, I frankly am very disappointed in one company that, while
> trying to promote IPv6 usage, has also worked very hard to limit its use by
> NOT supporting a protocol developed by the IETF.
>
> I'm also surprised that organizations haven't pushed harder to get that
> company to implement the standards. I suspect though that is because IPv6
> is not yet "critical" for deployment. This provides the company an
> opportunity to push their agenda (whatever it may be).
>
> I will admit that being DHC WG co-chair, coauthor of the some of the
> standards, and also a vendor does bias me.
>
> - Bernie
>
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 19 Jan 2017 10:30:44 -0800

At Thu, 19 Jan 2017 02:50:21 +0000,
"Liubing (Leo)" <[email-masked]> wrote:

> As Brian suggested in another thread, do you think it may help the
> draft more readable if we separate the operational divergence into
> "Major" and "Minor"?

Also to respond to Brian's suggestion: the short answer is "no", but I
think I should explain it in a bit more detail.  I don't mind
including "minor" issues per se, and I don't see the need for
separation.  After all what's important/not important or what's
major/minor is subjective, so it would be inevitable to have points
that are minor to some people.  Using the word "major" and "minor", my
main concern with the current version of the draft is that it spends a
quite lot of text for "too minor" issues that the entire discussions
make a distraction (see, for example, the comment on Section 3 item 4
of my previous review:
https://www.ietf.org/mail-archive/web/v6ops/current/msg24444.html).

So my point is rather "excluding 'too minor' points" than clarifying
which is major and which is minor.  I can live with including
relatively minor issues itself, and it's okay to not mark them "minor"
as long as we have the courage of dropping too minor points with the
energy spent for them.

--
JINMEI, Tatuya

---

From: james woodyatt <[email-masked]>
Date: Thu, 19 Jan 2017 10:39:41 -0800

On Jan 19, 2017, at 01:50, Sander Steffann <[email-masked]> wrote:
> On Jan 17, 2017, at 15:51, Mark Smith <[email-masked]> wrote:
>> 
>> Implementing every option every where to try to provide everybody with their favorite method ("provide all options in both RA and DHCPv6") just creates complexity, confusion, more code to write and more things that can break.
> 
> That's a valid concern. I suggested using the same options for both RA and DHCPv6 exactly for this reason: to keep things simpler. With the current direction things seem to be moving to I'm afraid we're going to end up with different options for DNS, NTP, default gateway etc in both protocols, and that would be really bad. […]

Wait… what?

If there is a movement to load more options into RA Messages than those necessary for providing hosts with DNS configuration even when they don’t implement stateful DHCPv6, then I’d like to have words with its leaders. There is no reasonable need for additional service location information pushed in RA Messages beyond the DNS servers and name search parameters because we have DNS-SD for providing network parameters to hosts in general. DHCP may still be necessary for providing some network operators with fine-grained centralized leasing of network parameter configurations of individual specific hosts, but RA Messages are more broadly required on most popular link layers, and they should remain much much simpler to process.

I see that I-D.v6ops-dhcpv6-slaac-problem doesn’t seem confused about this point, so how did we arrive at this point in the discussion?

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jan 2017 14:00:33 -0500

As one of the authors of RFC 3315, I feel I should chime in here to mention some discussion that has transpired since 3315 and related documents were published, which I think has bearing on the question of whether to stuff more options into RAs.

To understand this, it is important to grasp the distinction between information that relates to the local network to which a host has connected, and information that relates to the host, independent of where it may connect.   In DHCPv4, many options fall into the latter category.   Some DHCPv6 options (e.g., the NTP servers option) do as well.

It is a really bad idea for the host to trust the local network to configure things like this.  Do you really want the local Starbucks to provide you with your source of time?   Consequently, DHCP, which is really an infrastructure protocol, is a poor choice for configuring such parameters.   Stuffing those parameters into ND would be compounding the mistake.   Please do not do this.

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Jan 2017 06:43:38 +1100

On 20 January 2017 at 05:39, james woodyatt <[email-masked]> wrote:
> Implementing every option every where to try to provide everybody with their
> favorite method ("provide all options in both RA and DHCPv6") just creates
> complexity, confusion, more code to write and more things that can break.
>
>
> That's a valid concern. I suggested using the same options for both RA and
> DHCPv6 exactly for this reason: to keep things simpler. With the current
> direction things seem to be moving to I'm afraid we're going to end up with
> different options for DNS, NTP, default gateway etc in both protocols, and
> that would be really bad. […]
>
>
> Wait… what?
>
> If there is a movement to load more options into RA Messages than those
> necessary for providing hosts with DNS configuration even when they don’t
> implement stateful DHCPv6, then I’d like to have words with its leaders.
> There is no reasonable need for additional service location information
> pushed in RA Messages beyond the DNS servers and name search parameters
> because we have DNS-SD for providing network parameters to hosts in general.
> DHCP may still be necessary for providing some network operators with
> fine-grained centralized leasing of network parameter configurations of
> individual specific hosts, but RA Messages are more broadly required on most
> popular link layers, and they should remain much much simpler to process.
>
> I see that I-D.v6ops-dhcpv6-slaac-problem doesn’t seem confused about this
> point, so how did we arrive at this point in the discussion?
>

I think it is because I said that:

- RDNSS options were justified by saying low end embedded devices were
too resource constrained to run a (stateless) DHCPv6 client (that
doesn't seem to be in the RFC, however I'm pretty sure that was the
only argument I accepted personally for them at the time)

- I've since changed my mind because CPU and memory is always getting
cheaper, stateless DHCPv6 is quite simple, and we now we have
confusion about whether to deploy RDNSS or stateless DHCPv6, and
issues about universal RDNSS support, which was something I thought
was likely to occur, unless the use case for RDNSS was very clear.

Brian has said RDNSS was aimed less resource constrained environments
such as cafes, homes etc. Unfortunately that doesn't seem to be that
clear, as much larger organisations are seeming to see it as the
general purpose way of deploying DNS parameters (and re-architecthing
their network when some of their equipment doesn't support it - L2VPNs
just to make RDNSS work? ¡Ay, caramba!)

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

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jan 2017 19:57:10 +0000

Hi, we use DHCPv6 IA_PD on Android all the time. It works great, and only requires
a couple of messages on the client side.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Thursday, January 19, 2017 9:43 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Fernando Gont <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Bernie,

have you read RFC 7934? It lists a number of reasons why it is not recommended for networks to support only DHCPv6 address assignment via IA_NA.

I don't think DHCPv6 in itself is a problem. While it does suffer from the limitations I outlined in my earlier message, it is flexible and extensible to way more information than RAs can carry. It's also widely supported. But I really think IA_NA is not appropriate for IPv6 assignment, for the reasons that the authors and the WG outline in RFC7934.

Unfortunately, for many, decades of operational familiarity and vendor support with IPv4 networks, where the only way to get an IP address (and only ever ONE address) was DHCP, make it very hard to think of any other address assignment mechanism. SLAAC is regularly dismissed as outlandish and insecure, /64 subnets as wasteful, and the insistence that IPv4 and IPv6 demand different link-addressing practives as religion. "Why can't we just use DHCP", as an earlier message put it. Unfortunately the truth is much more complex than that.

If the Internet is eventually to reap the full benefits of IPv6, then we as a technical community and as an industry need to give a chance to a new addressing model where hosts can use as many IPv6 addresses as they need. Right now, that means SLAAC. The fact of the matter is that it SLAAC's security properties are not substantially worse than IA_NA, and anyone who says differently should read RFC 7934 section 9.1, of which I have not yet seen any rebuttal, convincing or otherwise. And as for /64s being wasteful - you saw the earlier messages in this conversation that asserted that prefixes cost money or they are hard to obtain, when in fact the cost is orders of magnitude lower than one cent, and RIR policies ere extremely liberal?

It would be extremely easy to simply carry over practices that we have in IPv4 to IPv6. But because applications are incentivized to add application complexity in order to work properly on all networks, there is a risk that we might get stuck there, and never be able to elevate ourselves out of those practices. If that happens will keep suffering the problems caused by IP address scarcity even after scarcity is banished. That would be a bad outcome.

Of course I may be wrong and a one-address-per-host model is the right choice. But I don't think we can tell at the moment. Over the years, network administrators that learn about IP (and application developers that write applications) on dual-stack networks with a mix of SLAAC and DHCPv6 will be able to make better choices between these protocols than we can today.

Cheers,
Lorenzo

On Fri, Jan 20, 2017 at 1:59 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
While I probably shouldn't send this as it is in the political and not technical space, I frankly am very disappointed in one company that, while trying to promote IPv6 usage, has also worked very hard to limit its use by NOT supporting a protocol developed by the IETF.

- Bernie

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 08:57:29 +1300

> Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to go.

Not completely unrelated to that, I think that RFC8028 would largely
remove the dependency of RFC7157 on DHCPv6 (except for a split DNS
scenario, which is unlikely to apply in a non-DHCPv6 network anyway).

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Jan 2017 07:12:34 +1100

> To understand this, it is important to grasp the distinction between information that relates to the local network to which a host has connected, and information that relates to the host, independe…

I'd say many of the DHCPv6 options do - I think only IA_NA and IA_TA
are the only exceptions.

> It is a really bad idea for the host to trust the local network to configure things like this.  Do you really want the local Starbucks to provide you with your source of time?   Consequently, DHCP,…

So what is the alternative?

Hosts have trusted the networks they attach to for more than being
given an address to since at least BOOTP. Trusting the network being
attached to for service parameters seems to be a fundamental and many
decade old assumption, and is the common practice for IPv4 on public
less trusted networks.

Specific to DNS, I think I'd currently trust Starbucks for NTP more
than DNS. My device might have multiple NTP and other time sources, so
the trust of the Starbucks NTP time source can be evaluated. I don't
think DNSSEC is deployed widely enough to be entirely confident that
Starbucks won't be changing DNS resolver responses if it is in their
interests.

Are we moving to a model where the only trust of the local network is
(and only should be) for addressing information? Are we then locked
into the upper services, such as DNS and NTP, that the device vendor
chooses because the device vendor doesn't let us change them?

Regards,
Mark.

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 19 Jan 2017 15:31:26 -0500

> Meh. draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 is the way to go.

Boo.

  "How a host should make good decisions about source address
   selection in a multihomed site is not a solved problem.  We do not
   attempt to solve this problem in this document."

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Jan 2017 07:53:22 +1100

On 19 January 2017 at 20:50, Sander Steffann <[email-masked]> wrote:
> That's a valid concern. I suggested using the same options for both RA and DHCPv6 exactly for this reason: to keep things simpler.

More is never simpler.

If host parameters are duplicated across RAs and DHCPv6, there is no
single source of truth anymore.

The Internet is supposed to be application transparent - application
(and transport) protocols only reside in the hosts, the Internet is
just a dumb packet forwarding network shunting around packets carrying
payloads it doesn't care about. The devices in the network (the packet
forwarding routers) do not have to have their software or hardware
upgraded to support new applications. Applications only reside on/in
hosts.

I think the same transparency model applies and should apply to host
configuration, what I'd call "Internet application configuration
transparency".

"Internet Transparency and Application Configuration"
https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

> With the current direction things seem to be moving to I'm afraid we're going to end up with different options for DNS, NTP, default gateway etc in both protocols, and that would be really bad.
>

I don't think they're critically analysing the operational
consequences of their preferences. While understandable, that's
religion rather than engineering.

> But I think it's really important that we revisit this, and rather sooner than later. I personally am perfectly fine with the original model, but I also see (mostly) enterprises that seem to push f…

The next generation after the "IPv4+NAT" generation won't care.
They'll just accept IPv6 the way it is.

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jan 2017 16:09:22 -0500

> I'd say many of the DHCPv6 options do - I think only IA_NA and IA_TA

Providing the IP address of a recursive resolver isn't so bad, because you have DNSSEC to protect you.

:)

> So what is the alternative?

For NTP, you should probably be using the NTP server your vendor configured, unless you have your own, in which case you should be using that.   For SMTP, you should be using the SMTP server your email provider offers, not the one the network offers.   For print, you should probably be using DNSSD, not DHCP.   Etc.   You should have an authenticated trust relationship with any service you use, so that you can tell if you are being spoofed.

> decade old assumption, and is the common practice for IPv4 on public

I don't know of any non-infrastructure devices that use the DHCP-provided NTP server.

> Starbucks won't be changing DNS resolver responses if it is in their

You should check this assumption.   I suspect you are using a fixed NTP server, not one configured via DHCP.

> chooses because the device vendor doesn't let us change them?

It would be nice to have a host configuration protocol that is homed rather than ad-hoc.   But we don't have that.   As it stands, yes, you either need to trust the vendor config or update it manually.   Unless your device is an infrastructure device, trusting the network is a _really_ bad idea.   Maybe even then.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 19 Jan 2017 21:46:28 +0000

Hi Lorenzo:

I do regret not being more active when RFC 7934 was being drafted as I think there are some things about DHCPv6 that are a bit off.

          It is also technically possible for a client
      to request additional addresses using a different DHCP Unique
      Identifier (DUID), though the DHCPv6 specification implies that
      this is not expected behavior ([RFC3315], Section 9<https://tools.ietf.org/html/rfc3315#section-9>).

The way a client can get many addresses is simply to send in multiple IA_NA (or IA_TA or IA_PD) options with different IAID values. There is no need to change the DUID.

           The maximum number of IPv6 addresses that can be provided

      in a single DHCPv6 packet, given a typical MTU of 1500 bytes or

      smaller, is approximately 30

But a client is free to send many separate transactions (multiple packets). For example, one approach would be to send a new request whenever a new address is needed – this would be an IA_NA (for non-temporary address) with a unique IAID. And, that might be much easier when you have dynamic needs (i.e., device being added over time).

And, each transaction does not need to start with the server discovery process since that has already been done – they can start with a Request (2 message exchange).

Sadly, we may have made things even a bit worse with the introduction of RFC 7550 as this promotes using a single transaction when asking for multiple things (IA_NA + IA_PD is the classic example). But the goal of RFC 7550 was to make the Customer Edge (CE) router (described in RFC7084) model simpler – especially in cases where not both an address and delegated prefix might be available. And, if doesn’t precluded the separate transaction model.

Neither of the statements in the RFC is technically wrong (as changing the DUID is certainly one way to accomplish that goal, and the limit for a single packet is correct). But it just leaves the wrong impression about DHCPv6. We designed it to allow LOTS of addresses per client and be very flexible in how those addresses are “grouped” (i.e., by IA_* type and IAID).

And, yes this is more code and overhead to just having a /64 available and building an address whenever it is needed (that’s a few lines of code to write and execute) – no extra external communication necessary.

-          Bernie

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, January 19, 2017 12:43 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Chuck Anderson <[email-masked]>; Fernando Gont <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem

Bernie,

Cheers,
Lorenzo

- Bernie

---

From: Philip Homburg <[email-masked]>
Date: Fri, 20 Jan 2017 00:29:34 +0100

>Providing the IP address of a recursive resolver isn't so bad, because you hav

I'd say, for the general mobile case, like connecting to the wireless network
at Starbucks, any protocol that doesn't provide both encryption and 
authenticated data is just a security accident waiting to happen.

For DNS, we have authentication, if you do local DNSSEC validation. If
you rely on Google's public DNS resolver to do DNSSEC validation then you
are completely exposed.

To also do encryption, you need something like TLS to your DNS resolver.
(Of course pinning the certificate you accept).

>For NTP, you should probably be using the NTP server your vendor configured, u
>nless you have your own, in which case you should be using that.   For SMTP, y
>ou should be using the SMTP server your email provider offers, not the one the
> network offers.   For print, you should probably be using DNSSD, not DHCP.   
>Etc.   You should have an authenticated trust relationship with any service yo
>u use, so that you can tell if you are being spoofed.

By and large NTP is used without authentication. So it doesn't matter which
NTP server you want to talk to, your wireless connection can spoof the
replies anyhow.

So do you really want to decide whether a certificate is expired or not 
based on time that can be spoofed by your local wifi network?

For SMTP you want a TLS connection to a configured DNS name. So that
can be secured.

I doubt that printing on the go can secured. So print only stuff that
can be made public anyhow.

Where it gets interesting, if you connect using 802.1X to your corporate
wifi, then you really want to trust (and use) what you get from DHCP because
it makes life a lot easier and the firewall may block everything else.

---

From: james woodyatt <[email-masked]>
Date: Thu, 19 Jan 2017 15:50:24 -0800

On Jan 19, 2017, at 11:43, Mark Smith <[email-masked]> wrote:
> 
> […] stateless DHCPv6 is quite simple, and we now we have confusion about whether to deploy RDNSS or stateless DHCPv6 […]

I would argue that's because Stateless DHCPv6 is not a very good idea. I believe its sunset should have begun years ago when DNS-SD was standardized.

Why am I not a fan of Stateless DHCPv6? Because there isn’t a way for the service advertiser to update or delete a service location previously provided to hosts except to let its timer expire. For that, you need to use DNS-SD. I believe there are no good reasons to deploy Stateless DHCPv6 except to support legacy devices that A) have not yet adopted DNS-SD as the standard for service discovery, and B) have not yet adopted RDNSS as the standard for DNS configuration discovery.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jan 2017 19:00:08 -0500

> it makes life a lot easier and the firewall may block everything else.

Perhaps so, but how does your device know to differentiate between this case and other cases?

Also, if it is your personal device that you have brought in to work, do you necessarily want to accept everything that your work DHCP server tells your device?

BTW, I was kidding about DNSSEC.   Right now you don't get any validation, because nothing you're using is signed.   And you should be using ntp with some kind of signing, even if it's shared private key.   Apple doesn't appear to do that, which I guess isn't shocking (that's my test case—I don't know what other software is doing).   But the fact that this isn't being properly secured is not a reason to do something dumb security-wise at the lower layer.   Hopefully at some point this problem will be fixed, and we shouldn't make fixing it harder.

That's the deal with DNSSEC as well—even though it isn't broadly deployed _now_, it will be when it starts to become obvious that it should be.   But the signing infrastructure for DNSSEC allows for the DNS distributed caching system to work and be secured, whereas existing NTP authentication does not, and it's unlikely that that will change.   So distributing DNS resolver info with ND and DHCP doesn't create an additional security exposure; distributing NTP does.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jan 2017 19:02:53 -0500

On Jan 19, 2017, at 6:50 PM, james woodyatt <[email-masked]> wrote:
> Why am I not a fan of Stateless DHCPv6? Because there isn’t a way for the service advertiser to update or delete a service location previously provided to hosts except to let its timer expire. For that, you need to use DNS-SD. 

Hm, you mean with open-ended queries (LLQ)?   Does this really make a difference in practice?   I don't think the plumbing is in place to take advantage of this for the kinds of services that are distributed via stateless DHCP—that's one of the reasons that there's not been a stronger push to support DHCPv6 reconfigure for information requests.

---

From: james woodyatt <[email-masked]>
Date: Thu, 19 Jan 2017 16:22:10 -0800

On Jan 19, 2017, at 16:02, Ted Lemon <[email-masked]> wrote:
> On Jan 19, 2017, at 6:50 PM, james woodyatt <[email-masked] <mailto:[email-masked]>> wrote:
> Hm, you mean with open-ended queries (LLQ)?

It’s called DNS Push Notification now. <https://tools.ietf.org/html/draft-ietf-dnssd-push>

> Does this really make a difference in practice?

Yes, it makes a big difference, as can be seen, in practice, using the widely available implementation described by RFC 6281.

> I don't think the plumbing is in place to take advantage of this for the kinds of services that are distributed via stateless DHCP—that's one of the reasons that there's not been a stronger push to support DHCPv6 reconfigure for information requests.

I smell a logical circle in there: there hasn’t been a stronger push to support DHCPv6 Reconfigure in information requests because the kinds of services that are distributed via Stateless DHCP are not the sort that have the plumbing available to use it, and there hasn’t been a stronger push to make more kinds of services distributed via Stateless DHCP because there isn’t support for DHCPv6 Reconfigure in information requests.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Jan 2017 10:00:56 +0900

>    attempt to solve this problem in this document."

There's no way around that if you want end-to-end without BGP. At the end
of the day, a decision needs to be made on what source address to use for a
packet. The totality of the options, as I see them, is:

   1. You do end-to-end, in which case the host has to choose the right
   source address.
   2. You do NAT and the local network decides the source address for you
   without telling the host.
   3. You do BGP and everyone else on the Internet decides for you.

Ultimately we need to move away from transport protocols that are strongly
bound to the source IP address. For example, QUIC has no such restriction
as it provides a proper layer 4 connection ID.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jan 2017 20:24:40 -0500

> I smell a logical circle in there: there hasn’t been a stronger push to support DHCPv6 Reconfigure in information requests because the kinds of services that are distributed via Stateless DHCP are…

Sure, but I think we both agree that those kinds of services are better served using DNSSD.   The issue is that some small subset of services are probably better configured via ND or DHCP.   E.g., DNS resolver.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Jan 2017 11:34:38 +0900

On Fri, Jan 20, 2017 at 6:46 AM, Bernie Volz (volz) <[email-masked]> wrote:

> I do regret not being more active when RFC 7934 was being drafted as I
> think there are some things about DHCPv6 that are a bit off.
>
>
>
>       this is not expected behavior ([RFC3315], Section 9
> <https://tools.ietf.org/html/rfc3315#section-9>).
>
>
>
> The way a client can get many addresses is simply to send in multiple
> IA_NA (or IA_TA or IA_PD) options with different IAID values. There is no
> need to change the DUID.
>

That's true, but the sentence immediately prior to the one you cite already
says that that DHCPv6 can provide multiple addresses:

   o  Using stateful DHCPv6 address assignment [RFC3315].  Most DHCPv6
      clients only ask for one non-temporary address, but the protocol
      allows requesting multiple temporary and even multiple non-
      temporary addresses, and the server could choose to provide
      multiple addresses.

and the text about changing DUIDs is in addition to that.

> But a client is free to send many separate transactions (multiple
> packets). For example, one approach would be to send a new request whenever
> a new address is needed – this would be an IA_NA (for non-temporary
> address) with a unique IAID. And, that might be much easier when you have
> dynamic needs (i.e., device being added over time).
>
>
True, but see below about the impact of this point on the overall
recommendation.

> Neither of the statements in the RFC is technically wrong (as changing the
> DUID is certainly one way to accomplish that goal, and the limit for a
> single packet is correct). But it just leaves the wrong impression about
> DHCPv6. We designed it to allow LOTS of addresses per client and be very
> flexible in how those addresses are “grouped” (i.e., by IA_* type and IAID).
>

That's true. However, the most important reason why the document recommends
against DHCPv6-only addressing is not related to either of those points,
but due to a fundamental property of DHCPv6 IA_NA: the fact that addressing
via IA_NA requires explicit requests for address space before addresses can
be assigned. This is the applicable text:

   Due to the drawbacks imposed by requiring explicit requests for
   address space (see Section 4), it is RECOMMENDED that the network
   give the host the ability to use new addresses without requiring
   explicit requests.  This can be achieved either by allowing the host
   to form new addresses autonomously (e.g., via SLAAC) or by providing
   the host with a dedicated /64 prefix. The prefix MAY be provided
   using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.

Cheers,
Lorenzo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 15:47:24 +1300

On 20/01/2017 08:43, Mark Smith wrote:
...
> general purpose way of deploying DNS parameters...

Could that possibly be because DHCPv6 doesn't support next-hop router
advertisements, and they know that all hosts need both a DNS server
and a next-hop router? And for most hosts, that's *all* they need
once they have an address.

It isn't the first time in IETF history that a protocol feature has
been used for unexpected purposes.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 15:52:38 +1300

>    1. You do end-to-end, in which case the host has to choose the right

Actually the real point is to choose the right couplet {source_address, next_hop}.
Once again, that's why we did RFC 8028, which includes recommending
Rule 5.5 of RFC6724. It's not a panacea, and we still need RTGWG to do
something, but we are moving along the right path, I think.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Jan 2017 13:11:21 +0900

On Fri, Jan 20, 2017 at 8:50 AM, james woodyatt <[email-masked]> wrote:
>
> I would argue that's because Stateless DHCPv6 is not a very good idea. I
> believe its sunset should have begun years ago when DNS-SD was standardized.
>
> Why am I not a fan of Stateless DHCPv6? Because there isn’t a way for the
> service advertiser to update or delete a service location previously
> provided to hosts except to let its timer expire. For that, you need to use
> DNS-SD.
>

What James said. Personally I think the biggest issue with DHCP is the that
the D in its name is a lie. :-)

DHCP is not really dynamic - it's a timer-based protocol that relies on
client refresh to change anything. For a long time stateless DHCP didn't
have any refresh timer at all. Even now, the minimum refresh time for
stateless DHCPv6 is a (laughably long) 600 seconds, which means that if you
want to change something you need to wait an average of 5 minutes.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 20 Jan 2017 05:46:53 +0100 (CET)

On Thu, 19 Jan 2017, james woodyatt wrote:

> necessary for providing hosts with DNS configuration even when they

In order to make DNSSEC validation work, there might be a need to put NTP 
server in RA as well.

There are other options that have gone into RA lately, that probably 
hasn't been widely noticed. For instance there is a captive portal option 
for RA.

> leaders. There is no reasonable need for additional service location 
> information pushed in RA Messages beyond the DNS servers and name search 
> parameters because we have DNS-SD for providing network parameters to

Errr, DNS-SD? What kind of network parameters are you talking about?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Jan 2017 00:00:20 -0500

On Jan 19, 2017, at 11:46 PM, Mikael Abrahamsson <[email-masked]> wrote:
> In order to make DNSSEC validation work, there might be a need to put NTP server in RA as well.

You must have missed the discussion we had on this very topic earlier today.   This is a problem nobody is trying to solve, because it's already solved a different way.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 20 Jan 2017 16:03:04 +1100

> In order to make DNSSEC validation work, there might be a need to put NTP 

DNSSEC really only needs the clock to be set to roughly the correct
time.  +/- 30 minutes should be fine.  The default setting of the
signing tools all set the signing time into the past.  Clock skew
exists and if you don't allow for it you will be putting out answers
that don't validate.

BIND back dates the signing timestamp by a hour.

You are taking a leap of faith if you just trust a unknown time source
to set your clock.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 20 Jan 2017 06:15:05 +0100 (CET)

> You are taking a leap of faith if you just trust a unknown time source 

Considering the discussion I started in DNSOP 1-2 months back, it seems 
there is no solution to this problem. So everybody just throws up hands in 
air and gives up.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 20 Jan 2017 06:16:26 +0100 (CET)

On Fri, 20 Jan 2017, Ted Lemon wrote:

> You must have missed the discussion we had on this very topic earlier 
> today.  This is a problem nobody is trying to solve, because it's 
> already solved a different way.

>From what I can see it's not solved at all. What solution is it you're 
thinking of?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Jan 2017 00:17:28 -0500

On Jan 20, 2017, at 12:16 AM, Mikael Abrahamsson <[email-masked]> wrote:
> From what I can see it's not solved at all. What solution is it you're thinking of?

No, it's not solved, but adding an NTP option to ND makes it _harder_ to solve, not _easier_.

---

From: [email-masked]
Date: Fri, 20 Jan 2017 08:22:15 +0100 (CET)

> I don't know of any non-infrastructure devices that use the DHCP-provided NTP server.

I performed a small experiment on our residential customers based on
this. Many of these customers are on DSL using bridge based modems (so
for these customers we see the MAC address of their equipment on our
BRAS).

I set up a new NTP server (IP never used for NTP before), and changed
one of the NTP server addresses we hand out through DHCP to this new
address.

Within a few minutes, I started seeing NTP traffic from the DHCP
clients. Checking the OUI of the MAC addresses I see a mix - both
typical "home router" vendors (e.g. Belkin), and also typical host
vendors (e.g. HP).

Thus my conclusion is that there are certainly *some* hosts picking up
NTP servers from DHCP. I couldn't really say anything about how *many*
without further analysis.

Steinar Haug, AS2116

---

From: Philip Homburg <[email-masked]>
Date: Fri, 20 Jan 2017 11:41:48 +0100

>    between this case and other cases?

For 802.1X you need to pin the certificate. So you can just as well add a
flag 'this network is trusted'

>    Also, if it is your personal device that you have brought in to
>    work, do you necessarily want to accept everything that your
>    work DHCP server tells your device?

That's not a technical problem. I have root on my devices. So I can override
network settings as I see fit. There may be devices where the user doesn't
have that option. There is not much we can decide about that here.

>    BTW, I was kidding about DNSSEC.   Right now you don't get any
>    validation, because nothing you're using is signed.   

I don't know  which 'you' you are referring to. I use SSHFP all day.
That works perfectly fine, because it is my servers, my DNS, my patched
version of ssh.

In addition I use the DNSSEC/TLSA Validator plug-in from cz.nic. Funny thing
is, their own website https://www.dnssec-validator.cz/ fails to validate
that the moment.

>    And you
>    should be using ntp with some kind of signing, even if it's
>    shared private key.   Apple doesn't appear to do that, which I
>    guess isn't shocking (that's my test caseI don't know what other
>    software is doing).   

I'm not aware of any secure ntp use at scale. As far as I know ntp security
is hugely problematic. If you have any pointers to large scale use of secure
ntp I'd like to know.

>    the fact that this isn't being properly
>    secured is not a reason to do something dumb security-wise at
>    the lower layer.   Hopefully at some point this problem will be
>    fixed, and we shouldn't make fixing it harder.

Obviously, we first need to figure out how to fix ntp before we can decide on
how to distribute the parameters.

>    That's the deal with DNSSEC as welleven though it isn't broadly
>    deployed _now_, it will be when it starts to become obvious that
>    it should be.   But the signing infrastructure for DNSSEC allows
>    for the DNS distributed caching system to work and be secured,
>    whereas existing NTP authentication does not, and it's unlikely
>    that that will change.   So distributing DNS resolver info with
>    ND and DHCP doesn't create an additional security exposure;
>    distributing NTP does.

For a security point of view, I don't see a big difference between a
starbucks DHCP telling my device to use ntp.starbucks.com and using
pool.ntp.org. Both are equally insecure.

In a practical sense, using pool is proably better than using whatever
was hacked together in a cheap router.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Jan 2017 09:42:11 -0500

> typical "home router" vendors (e.g. Belkin), and also typical host

Interesting—thanks for the hard data!   The HP could be either a printer or a host running Windows—might be interesting to see which by looking at the DHCP lease.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 20 Jan 2017 16:00:00 +0100

Hi James,

> If there is a movement to load more options into RA Messages than those necessary for providing hosts with DNS configuration even when they don’t implement stateful DHCPv6, then I’d like to have wo…

That was based on some comments I read in this thread about DHCPv6 not being able to push changes to the devices the way that RA can, and only being able to change settings when the client sends in a new request (partially because DHCPv6 Reconfigure isn't widely implemented).

> I see that I-D.v6ops-dhcpv6-slaac-problem doesn’t seem confused about this point, so how did we arrive at this point in the discussion?

That was me extrapolating based on what I have seen on this list :)

Cheers,
Sander

---

From: james woodyatt <[email-masked]>
Date: Fri, 20 Jan 2017 11:11:38 -0800

On Jan 19, 2017, at 20:46, Mikael Abrahamsson <[email-masked]> wrote:
>> […] leaders. There is no reasonable need for additional service location information pushed in RA Messages beyond the DNS servers and name search parameters because we have DNS-SD for providing network parameters to
> 

I would have thought it clearly implied in context, but at the risk of pedantry, I’ll be more explicit in the hope of providing more clarity.

I’m talking about the relatively small set of network parameters currently distributed in operational practice by Stateless DHCP, along with the considerably larger set that includes every other network parameter currently distributed in operational practice by DNS-SD. Not to mention all the parameters that could potentially be more easily distributed— to networks in general, rather than individually to each host— by DNS-SD than by DHCP due to its federated namespace and globally distributed name service.

---

From: james woodyatt <[email-masked]>
Date: Fri, 20 Jan 2017 11:14:58 -0800

On Jan 19, 2017, at 20:46, Mikael Abrahamsson <[email-masked]> wrote:
>> If there is a movement to load more options into RA Messages than those necessary for providing hosts with DNS configuration even when they
> 

As noted, I’m skeptical about that one.

> There are other options that have gone into RA lately, that probably hasn't been widely noticed. For instance there is a captive portal option for RA.

It escaped my attention until now. I’m at a loss to understand how that happened. I’m sure there must have been a contentious debate in 6MAN that I completely missed.

---

From: Mark Smith <[email-masked]>
Date: Sat, 21 Jan 2017 07:48:58 +1100

On 21 Jan. 2017 06:15, "james woodyatt" <[email-masked]> wrote:

There are other options that have gone into RA lately, that probably hasn't
been widely noticed. For instance there is a captive portal option for RA.

It escaped my attention until now. I’m at a loss to understand how that
happened. I’m sure there must have been a contentious debate in 6MAN that I
completely missed.

I'm pretty sure I objected to the idea of using RA options for this.

I'm starting to accept that people don't have a problem with upgrading
router firmware every time they need to deploy a new application or
application related feature. I think this is the antithesis of the Internet
payload oblivious dumb network, smart hosts model, however there are
perverse incentives to create or to ignore creation of more operational
work.

Regards,
Mark.

--james woodyatt <[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 21 Jan 2017 04:12:22 +0100 (CET)

On Fri, 20 Jan 2017, james woodyatt wrote:

> I would have thought it clearly implied in context, but at the risk of 
> pedantry, I’ll be more explicit in the hope of providing more clarity.

Please do.

> I’m talking about the relatively small set of network parameters 
> currently distributed in operational practice by Stateless DHCP, along 
> with the considerably larger set that includes every other network 
> parameter currently distributed in operational practice by DNS-SD. Not 
> to mention all the parameters that could potentially be more easily 
> distributed— to networks in general, rather than individually to each 
> host— by DNS-SD than by DHCP due to its federated namespace and globally 
> distributed name service.

I am still left guessing here. DNS-resolver? Search domain? NTP server? 
TFTP server? MTU?

I wasn't even aware that DNS-SD would do these things, that's why I'm 
still trying to figure out what you're saying and what you're proposing. 
It sounded to me that you said that you wanted DNS-SD to handle a lot 
of these tasks?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Jan 2017 22:14:46 -0500

On Jan 20, 2017, at 10:12 PM, Mikael Abrahamsson <[email-masked]> wrote:
> I wasn't even aware that DNS-SD would do these things, that's why I'm still trying to figure out what you're saying and what you're proposing. It sounded to me that you said that you wanted DNS-SD to handle a lot of these tasks?

DNS-SD can't deliver you a resolver, since in its non-mDNS form, it requires you to already know how to contact the resolver.   So no, you can't configure DNS using DNS-SD.

---

From: Gert Doering <[email-masked]>
Date: Sat, 21 Jan 2017 10:02:33 +0100

Hi,

> been used for unexpected purposes.

I wouldn't call that "unexpected" - personally, I thought that was the
point all along: SLAAC with all relevant information, namely "IPv6
address, gateway, DNS servers".

Everything else is nice, but without DNS, you need an extra protocol
to provision those - so in my view, adding RDNSS was fixing a glaring
omission in RA.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Sat, 21 Jan 2017 12:56:53 +0100

>DNS-SD can't deliver you a resolver, since in its non-mDNS form, it 
>requires you to already know how to contact the resolver.   So no, you 
>can't configure DNS using DNS-SD.

I assume you can just do a mDNS lookup for _dns._udp.local.

Of course, if the DNS-SD information is in public DNS, then you can just
as well use any global resolver, like 2001:4860:4860::8888 (I almost
typed 8.8.8.8).

The one thing you can't get is the search domain. Though of course
that could be encoded as a TXT record in the relevant DNS resolver pointed
to by _dns._udp.local.

The one thing that is possible in DHCP and almost impossible in any of the
alternatives (RA, DNS-SD) is configuration that varies per host. Some of
the classical DHCP options, like hostname, root path, boot file
name, are host specific.

It seems that the one thing that was left out of DNS-SD is support for
host specific configuration. I guess it should be easy enough to put in.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 21 Jan 2017 10:57:23 -0500

> I assume you can just do a mDNS lookup for _dns._udp.local.

Only if there is a server listening for such lookups on the local wire.

> as well use any global resolver, like 2001:4860:4860::8888 (I almost

Yes, that definitely won't work in most cases, because as you suggest, the information is not actually public (and may not even be in a fully-functional DNS zone).

> that could be encoded as a TXT record in the relevant DNS resolver pointed

Search domain is an attack surface.   So this would actually be a win.

> the classical DHCP options, like hostname, root path, boot file

ND has host-specific configuration.   But boot service is actually precisely what DHCP is best at.

> host specific configuration. I guess it should be easy enough to put in.

I suspect that it would be impossible without extensions, since the server doesn't have a client identifier to check.   I suppose the client could send an EDNS0 option with an identifier, but it seems silly to go to the trouble when DHCP already solves this problem.

---

From: Sander Steffann <[email-masked]>
Date: Sat, 21 Jan 2017 17:36:48 +0100

Hi,

> I suspect that it would be impossible without extensions, since the server doesn't have a client identifier to check.   I suppose the client could send an EDNS0 option with an identifier, but it se…

I'm getting confused... There seem to be too many different configuration mechanisms to keep a coherent model in my mind. What is supposed to go where? We have RA for layer-3 options and DNS, for a bare minimum network configuration. Then we have DHCPv6 both stateless (layer-4+ IPv6, and some layer-3 IPv4 stuff like DS-Lite and MAP) stateful (with additional layer-3 IPv6 options). And then we have DNS-SD with even more options.

All of these also have different push and pull models.

I give a lot of IPv6 training, and I'm struggling with how to explain to my IPv6-newbie students how this all fits together... It all comes back to the problem for most network admins that IPv6 provides a lot of cool features, but the number of possible combinations is so large that they don't know what to do anymore. The learning curve for understanding all the options and protocols and possible combination is getting so steep that it's becoming a barrier to less experienced network admins...

I hope someone can give me a clear picture of what the intended architecture behind all these protocols is.

Cheers,
Sander

---

From: Philip Homburg <[email-masked]>
Date: Sat, 21 Jan 2017 20:43:18 +0100

>> Of course, if the DNS-SD information is in public DNS, then you can =
>just
>Yes, that definitely won't work in most cases, because as you suggest, 
>the information is not actually public (and may not even be in a 
>fully-functional DNS zone).

I wonder how this is supposed to work (I have no experience with DNS-SD).

Suppose a laptop is set to use 8.8.8.8 because in some locations the advertised
DNS resolver is weird.

Would that break DNS-SD in other locations. And if so, would the user figure
out why it doesn't work?

>ND has host-specific configuration.   

How does that work? One of the reasons to have a default router in DHCPv6
is to give some hosts a different default router.

As far as I know there are no specifications on how to send unique RAs to
individual hosts. Technically you can send RAs using unicast. But there 
doesn't seem to be the equivalent of a DUID in an RS.

>> host specific configuration. I guess it should be easy enough to put =
>in.
>
>I suspect that it would be impossible without extensions, since the 
>server doesn't have a client identifier to check.   I suppose the client 
>could send an EDNS0 option with an identifier, but it seems silly to go 
>to the trouble when DHCP already solves this problem.

What i was thinking of as a simple extension is before looking up
<service>.<domain> look for <service>.<duid>.<domain>.

Using the same DUID as in DHCP should make it easy to mix and match. This
requires no server side changes. But does of course require client side
changes.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 21 Jan 2017 20:56:03 +0100

>I'm getting confused... There seem to be too many different 
>configuration mechanisms to keep a coherent model in my mind. What is 
>supposed to go where? We have RA for layer-3 options and DNS, for a bare 
>minimum network configuration. Then we have DHCPv6 both stateless 
>(layer-4+ IPv6, and some layer-3 IPv4 stuff like DS-Lite and MAP) 
>stateful (with additional layer-3 IPv6 options). And then we have DNS-SD 
>with even more options.

It seems that after the age of too many almost but not quite similar
transition technologies, we are now entering the age of configuration 
technologies.

For Homenet, there is HNCP as well.

---

From: joel jaeggli <[email-masked]>
Date: Sat, 21 Jan 2017 13:13:46 -0800

> For Homenet, there is HNCP as well. 
this isn't really that different then the way things were in the ancien
regime . Back in 1995 or so bootp and dhcp (and slaac) were never (and
are not now) expressive enough to provide anything other than the barest
device configuration. so the first thing you do once you've got a
network configuration, is you tftp a config, contact an ldap server, or
otherwise engage some upper layer device management (standardized or
not) to get the rest of your network or device communication. the
profusion of ways and places this can be done points to a lack of a
clear winner in the marketplace.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 22 Jan 2017 01:49:19 +0100 (CET)

On Fri, 20 Jan 2017, james woodyatt wrote:

> happened. I’m sure there must have been a contentious debate in 6MAN 
> that I completely missed.

No. I brought it up in 6man after I discovered it and asked for procedural 
change, I don't know what the chairs decided to do after that.

There was a question in 6man regarding this option, chairs interpreted the 
comments as no opposition, so 6man left it without comment (as far as I 
can tell).

So it's easier (or at least was) to create new RA options in other working 
groups than it is to do it in 6man.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Jan 2017 04:56:14 -0300

On 01/21/2017 09:49 PM, Mikael Abrahamsson wrote:
> 
> There was a question in 6man regarding this option, chairs interpreted
> the comments as no opposition, so 6man left it without comment (as far
> as I can tell).
> 
> So it's easier (or at least was) to create new RA options in other
> working groups than it is to do it in 6man.

Isn't 6man where that's supposed to happen? :-)

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jan 2017 08:30:48 +1300

> Isn't 6man where that's supposed to happen? :-)

Seriously, no. That isn't written down anywhere. RFC4861 refers to RFC4443
which just requires IETF RFC publication. It's not really possible to specify
a particular WG in the IANA Considerations, because WGs may be closed.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Jan 2017 14:38:25 -0800

> Only if there is a server listening for such lookups on the local wire.

This is, in fact, what I first proposed to do in the dark days before we had RDNSS in the event hosts found themselves on IPv6-only links where DHCPv6 was not available. That, and a well-known anycast address for use in the event that mDNS-SD fails. That proposal was not well received, as I recall.

People were— rightly, I think— concerned that discovering the uDNS resolving server by mDNS-SD could entail saddening security considerations, and standardizing a single well-known anycast address for uDNS servers seemed perverse (before 2001:4860:4860::8888 showed up as a de facto convention), so that’s why I believe the old expired RDNSS draft was pulled out of mothballs. Meanwhile, the appearance of mDNS filters in layer-2 switching fabric convinced me that we were going to need help from the network infrastructure getting uDNS bootstrapped.

So that’s why I’m here, and I’m not still banging on using mDNS to bootstrap uDNS.

>> that could be encoded as a TXT record in the relevant DNS resolver pointed

See RFC 6763, section 11, Discovery of Browsing and Registration Domains (Domain Enumeration).

> ND has host-specific configuration.   But boot service is actually precisely what DHCP is best at.

I’ve been arguing for a long time that the perception of the need for this is misplaced. We need to build to an architecture where host configurations need not be individually customized dynamically by a central network service *DURING* the network attachment process. It should suffice to configure a host sufficiently to acquire general access to the network, then *AFTER* it is attached and its interface addresses assigned, for its hosted applications to acquire individualized configurations from the network to access local and global services properly.

> I suspect that it would be impossible without extensions, since the server doesn't have a client identifier to check.   I suppose the client could send an EDNS0 option with an identifier, but it se…

This is, indeed, what it seems to me that everyone who wants to keep stateful DHCP around says is the principle reason they need it.

I see no reason to give them for this another thing entirely while they actively protest that they don’t want another thing at all. Let them keep stateful DHCP for meeting their need to be fastidious. I agree they need something for this, and DHCP is the thing they already have. The rest of us can proceed with building to an architecture where hosts do not actually require individual service layer configurations to be applied before the network layer host attachment process can even be completed, and thus do not need DHCP clients at all, even to interoperate in the most authoritarian of service access environments. Those people will eventually come along and see the way forward. No need to hurry them.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jan 2017 18:06:52 -0500

> I see no reason to give them for this another thing entirely while they actively protest that they don’t want another thing at all. Let them keep stateful DHCP for meeting their need to be fastidio…

Yup.

---

From: Nathalie Trenaman <[email-masked]>
Date: Tue, 24 Jan 2017 10:23:20 +0100

Hi,

> I hope someone can give me a clear picture of what the intended architecture behind all these protocols is.

+1 from another puzzled/concerned IPv6 trainer. I’m trying to keep track, but it keeps getting more complex, to a point where I see people new to IPv6 tune out and give up. 

Cheers,
Nathalie Trenaman

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 Jan 2017 11:20:40 +0100

> I see no reason to give them for this another thing entirely while
> they actively protest that they dont want another thing at all.
> Let them keep stateful DHCP for meeting their need to be fastidious.
> I agree they need something for this, and DHCP is the thing they
> already have. The rest of us can proceed with building to an
> architecture where hosts do not actually require individual service
> layer configurations to be applied before the network layer host
> attachment process can even be completed, and thus do not need DHCP
> clients at all, even to interoperate in the most authoritarian of
> service access environments. Those people will eventually come
> along and see the way forward. No need to hurry them.

Looking at IPv6 as IPv4 with longer addresses and not as let's change random
things and hope that it will make IPv6 better...

I never felt the need for DNS-SD. I can understand the motivation but in
practice DHCPv4 just works. It is very easy to debug. There is one protocol
to watch, one exchange. If something is wrong it shows up in the DHCP
exchange.

I certainly appreciate DNS-SD from a protocol point of view. Way nicer and
more general than DHCP.

So if DNS-SD were a proper super set of stateless DHCPv6 than it would be
obvious to move to a future where RAs and DHCPv6 provide address assignment
and DNS-SD would provide configuration.

However the way you describe it, you need DHCPv6 at least for host specific 
configuration unless all hosts implement a new configuration protocol.
Which would bring the total number to 4 (RA, DHCPv6, DNS-SD, and an
undisclosed per host configuration protocol).

In that world, it makes way more sense, both for host operating systems and
network operators to completely ignore DNS-SD and stick to RA and DHCPv6.
(And publish an RFC that makes implementing both RA and DHCPv6, including 
IA_NA mandatory)

---

From: james woodyatt <[email-masked]>
Date: Tue, 24 Jan 2017 14:50:42 -0800

> undisclosed per host configuration protocol).

That’s not my position. My position is that, ideally, you shouldn’t need to provide host-specific configuration before completing the network attachment process during which valid interface addresses are assigned.

In shorter terms, you should need neither DHCPv6 nor a similar protocol.

You should be able to complete the network attachment process entirely with ICMPv6 Neighbor and Router Discovery interactions. If hosted applications, including certain high-level operating system services, require individual configuration parameters customized for each instance on the network, then those application instances should not use DHCP as their configuration protocol. That’s my ideal world. I realize the actual world has to be considerably messier for political and economic reasons.

> (And publish an RFC that makes implementing both RA and DHCPv6, including 

Disagree. Every technical argument I’ve seen put forward to explain the architectural need for IA_NA is unconvincing to me. Only the political and economic arguments have ever been persuasive for me. For that reason, I’d strongly oppose making IA_NA a mandatory capability of IPv6 hosts.

---

From: Erik Kline <[email-masked]>
Date: Wed, 25 Jan 2017 09:35:08 +0900

>
> Disagree. Every technical argument I’ve seen put forward to explain the
> architectural need for IA_NA is unconvincing to me. Only the political and
> economic arguments have ever been persuasive for me. For that reason, I’d
> strongly oppose making IA_NA a mandatory capability of IPv6 hosts.
>

Agreed.

---

From: Fred Baker <[email-masked]>
Date: Thu, 26 Jan 2017 10:45:30 -0800

> Disagree. Every technical argument I’ve seen put forward to explain the architectural need for IA_NA is unconvincing to me. Only the political and economic arguments have ever been persuasive for m…

I would guess that we're discussing the difference between technical requirements and market requirements. Technically, the requirement is that an implementation provide a way in which the host can attach to the network, and in which it can derive the remaining information it needs to do its job. Depending on the market, I can see SLAAC and DHCPv6 as each meeting the viewpoints of operators. I'd be interested to know the target operational market for DNS-SD: who is asking for the capability? 

Personally, while listing capabilities that we think should go into various kinds of equipment is interesting, I tend to think of it as highly political. If a person is politically inclined in the DHCP direction (pick a reason), SLAAC seems pretty optional. If a person is politically inclined toward SLAAC, DHCP seems irrelevant. The reason they both exist is because each has a market, a set of operational environments in which it is viewed as a technical requirement.

If anything, I might suggest identifying and discussing the requirements of various markets. If an implementor - a vendor, an open source developer, or whatever - wants to deploy in a given market, that would give them the requirements of that market.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Jan 2017 08:11:57 +1300

On 27/01/2017 07:45, Fred Baker wrote:
...
> If a person is politically inclined in the DHCP direction (pick a reason), SLAAC seems pretty optional. If a person is politically inclined toward SLAAC, DHCP seems irrelevant. The reason they both exist is because each has a market, a set of operational environments in which it is viewed as a technical requirement.

So, surely *our* job is to ensure that the various standards are mutually
consistent, and complete enough to support both inclinations. I view the
value of the draft in question (draft-ietf-v6ops-dhcpv6-slaac-problem if
everyone's forgotten) being to identify inconsistencies. The question of
completeness also needs to be analysed.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Thu, 26 Jan 2017 11:16:34 -0800

> On Jan 26, 2017, at 11:11 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Pretty much.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Jan 2017 14:29:16 -0500

On Jan 26, 2017, at 1:45 PM, Fred Baker <[email-masked]> wrote:
> I'd be interested to know the target operational market for DNS-SD: who is asking for the capability? 

There was a petition from EDUCAUSE.

But more broadly, any environment in which we want to be able to plug a printer into the network and then print on it from hosts without typing in a manual configuration somewhere.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 27 Jan 2017 11:52:58 +0100

In your letter dated Fri, 27 Jan 2017 08:11:57 +1300 you wrote:
>I view the

I'd say a network operator SHOULD make sure information in RA and DHCPv6 is
consistent. Hosts are allowed to use an unspecified selection algorithm do
decide what to use if there are inconsistencies.

This should be the starting point. If there is a clear operational need
why RA and DHCP have to be inconsistent. Then we should document that need
and how hosts should respond.

By and large trying to enumerate every possible way RA and DHCP can be 
inconsistent doesn't strike me as very productive.

And for some things, like renumbering from RA to DHCP, try not to shoot
yourself in the foot.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Jan 2017 18:17:51 -0300

[....]
> 
> Personally, while listing capabilities that we think should go into
> various kinds of equipment is interesting, I tend to think of it as
> highly political. If a person is politically inclined in the DHCP
> direction (pick a reason), SLAAC seems pretty optional. If a person
> is politically inclined toward SLAAC, DHCP seems irrelevant. The
> reason they both exist is because each has a market, a set of
> operational environments in which it is viewed as a technical
> requirement.

Unfortunately, one way or another, both are mandatory in practice, since
you need the *two* of them to be able to support the most popular
devices. And that's really bad.

> If anything, I might suggest identifying and discussing the
> requirements of various markets. If an implementor - a vendor, an
> open source developer, or whatever - wants to deploy in a given
> market, that would give them the requirements of that market. 

Requirements: do both DHCPv6 and SLAAC. because in practice non of them
can be employed to provide the most basic info (and address, a default
route, and a caching DNS server), bacause of religious wars on which
major vendors think they know better than the others.

Cheers,

---

From: Ted Lemon <[email-masked]>
Date: Sun, 29 Jan 2017 20:39:10 -0500

> devices. And that's really bad.

Because...?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Jan 2017 03:06:48 -0300

On 01/29/2017 10:39 PM, Ted Lemon wrote:
> On Jan 29, 2017, at 4:17 PM, Fernando Gont <[email-masked]

Because it essentially implies:

* Configuring stuff twice at two different places (prone to error,
conflicting information, etc.) -- talk about complexity

* Unnecessarily increasing the attack surface: two protocols, two pieces
of code -- not to mention protecting both, if you happen to care.

* It becomes harder to troubleshoot stuff (what host is it? does it
support slaac, dhcpv6, or both?... and all the inconsistent results
being discussed in the slaac-problem I-D).

(And, maybe less important, a "wt_?" moment for everyone that happens to
be learning about or deploying IPv6, and happens to figure or come
across any of the above three bullets)

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 Jan 2017 19:36:23 +0100

>of code -- not to mention protecting both, if you happen to care.

I'm not sure this is correct.

At the moment you always need RA. Of course, if somebody just goes ahead
and does a default router option in DHCPv6, RA could go away, but that is
not the case at the moment.

Unless we duplicate lots of DHCP options in RA, you probably need DHCP
as well, for example to specify NTP servers.

So realistically, every environment should run both RA and DHCP.

Ideally, all hosts should support getting address both using SLAAC and
using IA_NA, so hosts have to deal with the attack surface as well.

Migrating to just RA will at some point replicate statefull DHCPv6 in RA,
so that's certainly not ideal.

Getting rid of RA is realively easy (that how IPv4 works) but will not be
popular.

So the dual attack surface seems something we just have to live with.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Feb 2017 08:23:05 +1300

On 01/02/2017 07:36, Philip Homburg wrote:
...
> So realistically, every environment should run both RA and DHCP[v6].

It seems to me that there are plenty of running proofs that this
is not true.

    Brian

---

From: Chuck Anderson <[email-masked]>
Date: Tue, 31 Jan 2017 14:26:29 -0500

> It seems to me that there are plenty of running proofs that this

It seems impossible to have an IPv6-only environment that supports
general usage devices (BYOD) where this CAN'T be true.