Subject: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

From: Nick Hilliard <[email-masked]>
Date: Mon, 17 Jul 2017 18:47:03 +0100

draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID.

It has recently been claimed that IETF best current practice is that
DHCPv6 is not recommended due to the recommendations section in
RFC7934/BCP204.

The relevant text was slipped into
draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of
days before the document went into IETF LC.  There was no discussion
about this text change either in the v6ops working group or at IETF
review or IESG level: perhaps the modification appeared innocuous or
maybe it just wasn't not noticed.

Next thing, there's a BCP which is being interpreted as meaning that
DHCPv6 is NOT RECOMMENDED for operational use.  Wow. :-)

This presents a variety of problems, the most serious of which are 1)
that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED"
without extensive discussion or debate about this particular issue at
the relevant working group, and ignores the both the widespread use of
the protocol and its active development at the ietf, and 2) that a
change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole
in the IPv6 host specification.

Job and I believe that this went through by mistake and that if the WG
had noticed the change at the time, consensus would never have been
reached on what is a serious semantic change to IETF lore.

Right now, the most prudent course of action would be to roll back the
change until a proper debate has been had.  We invite WG comments on
this doc.

Nick

[email-masked] wrote:
> A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt
> has been successfully submitted by Nick Hilliard and posted to the
> IETF repository.
> 
> Name:		draft-hilliard-v6ops-host-addr-update
> Revision:	00
> Title:		Update for IPv6 Host Address Availability Recommendations
> Document date:	2017-07-17
> Group:		Individual Submission
> Pages:		4
> URL:            https://www.ietf.org/internet-drafts/draft-hilliard-v6ops-host-addr-update-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/
> Htmlized:       https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hilliard-v6ops-host-addr-update-00
> 
> 
> Abstract:
>    The IPv6 Host Address Availability Recommendations Best Current
>    Practice (RFC 7934), describes why IPv6 hosts should use multiple
>    global addresses when attaching to a network.  This document updates
>    RFC 7934 by removing a recommendation for networks to give the host
>    the ability to use new addresses without requiring explicit requests.
> 
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 20:17:03 +0200

The RFC doesn't say that anywhere in it.   There is no version of the draft
that was published on 2/12/2016.   The -01 version of the draft was
published in March of that year; the final version in July.   Can you
please point out the place in the text where it says what you are saying it
says?

On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard <[email-masked]> wrote:

> > URL:            https://www.ietf.org/internet-
> drafts/draft-hilliard-v6ops-host-addr-update-00.txt
> > Status:         https://datatracker.ietf.org/
> doc/draft-hilliard-v6ops-host-addr-update/
> > Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-hilliard-v6ops-host-addr-update-00
> >
> >
> > Abstract:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Jul 2017 20:23:19 +0200

Nick,

the text you mention was not "slipped in" by mistake, it was the outcome of
WG discussion.

In September 2015 (-01), the text read:

   If the network requires explicit requests
   for address space (e.g., if it requires DHCPv6 to connect), it is
   RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
   via DHCPv6 PD).

Some in the WG felt that it was not correct to single out DHCPv6 PD,
because it was not in wide use. Thus, in February 2016 (-05), the text was
changed to:

   Due to the drawbacks imposed by requiring explicit requests for
   address space (see section 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.

There were dozens or maybe hundreds on emails on this text, so I don't
think the WG was blindsided.

Cheers,
Lorenzo

---

From: Job Snijders <[email-masked]>
Date: Mon, 17 Jul 2017 19:19:34 +0000

Hi Ted,

This contribution made us realize that perhaps a clarification would be
useful: https://www.ietf.org/mail-archive/web/ipv6/current/msg28040.html

Kind regards,

Job

On Mon, 17 Jul 2017 at 20:17, Ted Lemon <[email-masked]> wrote:

> The RFC doesn't say that anywhere in it.   There is no version of the
> draft that was published on 2/12/2016.   The -01 version of the draft was
>> > URL:
>> https://www.ietf.org/internet-drafts/draft-hilliard-v6ops-host-addr-update-00.txt
>> > Status:
>> https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/
>> > Htmlized:
>> https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00
>> > Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-hilliard-v6ops-host-addr-update-00
>> >
>> >
>> > Abstract:

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Jul 2017 21:30:44 +0200

The following is a misreading of the document:

First, networks that require DHCPv6 assignment are explicitly NOT
> RECOMMENDED by current IETF best practices. Specifically, RFC 7934 section
> 8 says "it is RECOMMENDED that the network give the host the ability to use
> new addresses without requiring explicit requests". A DHCPv6-only network
> cannot meet this recommendation, because on a DHCPv6-only network, all
> addresses acquisition requires an explicit request to the network.

What the document actually implies is that individual address assignment
using DHCPv6 is not recommended; instead it is recommended that each host
get a /64.  The only way to do that right now is with DHCPv6 PD.   So the
document is explicitly recommending the use of DHCPv6.

However, if the only DHCP service available is individual address
allocation, then indeed that is not recommended, because it has serious
privacy implications.   And it is not _generally_ recommended that people
operate networks that require DHCPv6 static individual address allocation
(IA_NA) for this same reason.   Using the DHCPv6 privacy profile does
mitigate this concern, but still the best thing to do is just enable SLAAC.

I don't think these views are particularly controversial in the IETF.   I'm
one of the authors of RFC3315, and I agree with this view.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Jul 2017 22:12:19 +0200

Le 17/07/2017 à 21:30, Ted Lemon a écrit :
> RECOMMENDED by current IETF best practices. Specifically, RFC 7934 
> section 8 says "it is RECOMMENDED that the network give the host the 
> ability to use new addresses without requiring explicit requests". A 
> DHCPv6-only network cannot meet this recommendation, because on a 
> DHCPv6-only network, all addresses acquisition requires an explicit 
> request to the network.
> 
> 
> What the document actually implies is that individual address
> assignment using DHCPv6 is not recommended; instead it is recommended
> that each host get a /64.  The only way to do that right now is with
> DHCPv6 PD.

Ted - I would really like to agree with you, but DHCPv6 PD is not the
only way for a host to get a /64.  What the authors had in mind is the
cellular link with RA, or alternatively a WiFi link with
draft-unique-prefix-per-host.  In these two cases the way it works is
that RA advertises a /64 to the Host; because of that, and because it is
a point-to-point link, or because the RA is unicast to the Host, then
that /64 is practically entirely for the Host.

The authors explicitely said that DHCPv6-PD is not the way to send a /64
to the Host.  And I disagree with them.

When that BCP was written I expressed this view several times but to no
avail.

When I see the misunderstanding that BCP created I am tempted to ask to
question its BCP status... It is a huge misudnerstanding, and it
continues to be cited.

> So the document is explicitly recommending the use of DHCPv6.

If it were so, I would agree with it.  But it is not so.

Alex

> allocation, then indeed that is not recommended, because it has
> serious privacy implications.   And it is not _generally_ recommended
> that people operate networks that require DHCPv6 static individual
> address allocation (IA_NA) for this same reason.   Using the DHCPv6
> privacy profile does mitigate this concern, but still the best thing
> to do is just enable SLAAC.
> 
> I don't think these views are particularly controversial in the IETF.
>  I'm one of the authors of RFC3315, and I agree with this view.
> 
> On Mon, Jul 17, 2017 at 9:19 PM, Job Snijders <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Hi Ted,
> 
> This contribution made us realize that perhaps a clarification would 
> be useful: 
> https://www.ietf.org/mail-archive/web/ipv6/current/msg28040.html 
> <https://www.ietf.org/mail-archive/web/ipv6/current/msg28040.html>
> 
> Kind regards,
> 
> Job
> 
> On Mon, 17 Jul 2017 at 20:17, Ted Lemon <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> draft that was published on 2/12/2016.   The -01 version of the draft
> was published in March of that year; the final version in July.   Can
> you please point out the place in the text where it says what you are
> saying it says?
> 
> On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple
> of days before the document went into IETF LC.  There was no 
> discussion about this text change either in the v6ops working group
> or at IETF review or IESG level: perhaps the modification appeared 
> innocuous or maybe it just wasn't not noticed.
> 
> This presents a variety of problems, the most serious of which are
> 1) that a BCP is implying that the use of DHCPv6 was "NOT 
> RECOMMENDED" without extensive discussion or debate about this
> particular issue at the relevant working group, and ignores the both
> the widespread use of the protocol and its active development at the
> ietf, and 2) that a change in the status of DHCPv6 to "NOT
> RECOMMENDED" leaves a huge hole in the IPv6 host specification.
> 
> Job and I believe that this went through by mistake and that if the
> WG had noticed the change at the time, consensus would never have
> been reached on what is a serious semantic change to IETF lore.
> 
> Right now, the most prudent course of action would be to roll back
> the change until a proper debate has been had.  We invite WG comments
> on this doc.
> 
> Nick
> 
> [email-masked] <mailto:[email-masked]> wrote:
>> A new version of I-D,
> draft-hilliard-v6ops-host-addr-update-00.txt
>> Name:         draft-hilliard-v6ops-host-addr-update Revision:
>> 00 Title:                Update for IPv6 Host Address
> Availability Recommendations
>> Document date:        2017-07-17 Group:                Individual
>> Submission Pages:                4 URL:
<https://www.ietf.org/internet-drafts/draft-hilliard-v6ops-host-addr-update-00.txt>
> https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/
<https://datatracker.ietf.org/doc/draft-hilliard-v6ops-host-addr-update/>
> <https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00>
>
>  Htmlized: 
<https://datatracker.ietf.org/doc/html/draft-hilliard-v6ops-host-addr-update-00>
>> 
>> 
>> Abstract: The IPv6 Host Address Availability Recommendations
> Best Current
>> until the htmlized version and diff are available at
> tools.ietf.org <http://tools.ietf.org>.
>> 
>> The IETF Secretariat
>> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ross Chandler <[email-masked]>
Date: Mon, 17 Jul 2017 21:33:48 +0100

> On 17 Jul 2017, at 20:30, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
> What the document actually implies is that individual address assignment using DHCPv6 is not recommended; instead it is recommended that each host get a /64.  The only way to do that right now is with DHCPv6 PD.   So the document is explicitly recommending the use of DHCPv6.

https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 <https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-06>

Section 4 describes a way of assigning a /64 per host using RAs that is already deployed in real networks. No DHCPv6 involved.

https://tools.ietf.org/id/draft-pioxfolks-6man-pio-exclusive-bit-02.txt <https://tools.ietf.org/id/draft-pioxfolks-6man-pio-exclusive-bit-02.txt>

Introduces an eXclusive flag to optimize RA for nodes that are exclusive receivers of all traffic to the prefix. 

> However, if the only DHCP service available is individual address allocation, then indeed that is not recommended, because it has serious privacy implications.   And it is not _generally_ recommended that people operate networks that require DHCPv6 static individual address allocation (IA_NA) for this same reason.   Using the DHCPv6 privacy profile does mitigate this concern, but still the best thing to do is just enable SLAAC.
> 
> I don't think these views are particularly controversial in the IETF.   I'm one of the authors of RFC3315, and I agree with this view.

Given the above two drafts DHCPv6-PD to hosts has an uphill struggle to ever achieve widespread deployment.

Ross

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Jul 2017 22:58:03 +0200

Le 17/07/2017 à 22:33, Ross Chandler a écrit :
>> assignment using DHCPv6 is not recommended; instead it is
>> recommended that each host get a /64.  The only way to do that
>> right now is with DHCPv6 PD.   So the document is explicitly
>> recommending the use of DHCPv6.
> 
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-06
>
>  Section 4 describes a way of assigning a /64 per host using RAs that
> is already deployed in real networks. No DHCPv6 involved.

There is something wrong with that draft: it only allows for 64.  Why?
DHCPv6-PD can delegate other plengths, like 65.

> https://tools.ietf.org/id/draft-pioxfolks-6man-pio-exclusive-bit-02.txt
>
>  Introduces an eXclusive flag to optimize RA for nodes that are
> exclusive receivers of all traffic to the prefix.

This is another way of calling RA "Prefix Delegation".

There are other drafts doing Prefix Delegation with RA, have you
considered them?

>> serious privacy implications.   And it is not _generally_
>> recommended that people operate networks that require DHCPv6 static
>> individual address allocation (IA_NA) for this same reason.   Using
>> the DHCPv6 privacy profile does mitigate this concern, but still
>> the best thing to do is just enable SLAAC.
>> 
>> I don't think these views are particularly controversial in the
>> IETF. I'm one of the authors of RFC3315, and I agree with this
>> view.
> 

I dont think so.

I think DHCPv6-PD should be trialled at IETF WiFi and then we'll see.

Alex

---

From: Ross Chandler <[email-masked]>
Date: Mon, 17 Jul 2017 22:21:13 +0100

> On 17 Jul 2017, at 21:58, Alexandre Petrescu <[email-masked]> wrote:
> 

I agree that is a deficiency.

> This is another way of calling RA “Prefix Delegation".

Fair enough.

> There are other drafts doing Prefix Delegation with RA, have you

No, what are they? The above one caught my eye because of the employer of one of the authors.

>>> uthors of RFC3315, and I agree with this
>>> view.
> I don’t think so.

You’re more optimistic than me then. 

> I think DHCPv6-PD should be trialled at IETF WiFi and then we’ll see.

Yes, it should.

Ross

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 17 Jul 2017 22:33:33 +0100

[v6ops-chairs explicitly cc:'d because there is a serious WG consensus
problem here which has materially affected the outcome of an IETF process]

Lorenzo Colitti wrote:
> the text you mention was not "slipped in" by mistake, it was the outcome
> of WG discussion.

No, it categorically was not.  There was extensive discussion about this
at -04, where it was clear there there there was operator support for
the position that DHCPv6 IA_NA was a viable option which would match the
aims of the draft, for example:

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

+ several others.

Or the posting that sums this whole situation up:

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

As far as I can tell, there were very few people other than you
advocating the position that there was a problem with DHCPv6 IA_NA.

Despite this, you completely ignored the feedback from the working group
about DHCPv6 IA_NA, and changed the wording in -05 to state:

--
   Due to the drawbacks imposed by requiring explicit requests for
   address space (see section Section 4), it is RECOMMENDED that the
   network give the host the ability to use new addresses without
   requiring explicit requests.
---

-05 was introduced to the WG by the following email:

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

There was no mention of the fact that a change was made which
effectively ignored the outcome of the discussion.  12 days later
without any comment about this change, the document went to IETF LC.

You ignored the WG, didn't point it out, and despite extensive previous
objections, unfortunately the WG didn't notice.

The term "blindside" is your choice of phrase.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 17 Jul 2017 22:38:43 +0100

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

+ this url for the diffs

> https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-05

see section 8 - recommendations.

Nick

Ted Lemon wrote:
>      https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00 <https://tools.ietf.org/html/draft-hilliard-v6ops-host-addr-update-00>
>     > Htmlized:

---

From: Erik Kline <[email-masked]>
Date: Tue, 18 Jul 2017 06:55:35 +0900

In Prague 2 years ago this was presented
(https://www.ietf.org/proceedings/93/slides/slides-93-v6ops-7.pdf).

At that time, the minutes record that the "ask[ing...] on the fly
section [wa]s vague":

    https://tools.ietf.org/wg/v6ops/minutes?item=minutes-93-v6ops.html

          Limitations of asking for more on the fly section is vague. Lots of
          things require waiting for something to happen. Lots of cases where
          you know ahead of time you’ll need more than one. Launching a VM will
          require on the fly, but enumerate these cases better.

And the slides from IETF 94 mention this issue and states that the doc
addresses this:

    https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-9.pdf

The topic in general was discussed.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 18 Jul 2017 00:24:40 +0200

On Mon, Jul 17, 2017 at 11:33 PM, Nick Hilliard <[email-masked]> wrote:

> No, it categorically was not.

[...]

> about DHCPv6 IA_NA,

If you read the discussion threads carefully, you'll see that the main
issue being raised in that version of the draft (mostly by Philip and Gert,
as I recall) was not "IA_NA should be used", but "DHCPv6 PD is not the only
way to assign a prefix, and not a widely adopted way". -05 addressed that
issue by de-emphasizing DHCPv6 PD. As I read it, at the time there was
pretty broad agreement at the time that IA_NA was not a good choice both
because it is limited in terms of the number of total addresses that can be
assigned and because it requires that the client send explicit requests,
which has the problems listed in section 4.

> objections, unfortunately the WG didn't notice.

But there was no change on this topic. No version of the draft since -01
ever recommended IA_NA in the recommendations section. You assert that -05
made a change in this area, but there was no substantive change. Here's the
text in question. -04 says:

   If the network requires explicit requests
   for address space (e.g., if it requires DHCPv6 to connect), it is
   RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
   via DHCPv6 PD).  Using DHCPv6 IA_NA or IA_TA to request a sufficient
   number of addresses (e.g. 32) would accommodate current clients but
   sets a limit on the number of addresses available to hosts when they
   attach and would limit the development of future applications.

and -05 says:

   Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
   multiple addresses when the host connects (e.g. the approximately 30
   addresses that can fit into a single packet) would accommodate
   current clients, but sets a limit on the number of addresses
   available to hosts when they attach and would limit the development
   of future applications.

In both cases, the recommendation is that if a network uses DHCPv6 as the
only way to provide address space, it should assign a /64 to every host.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jul 2017 11:57:04 +1200

> DHCPv6 is not recommended due to the recommendations section in

I'm a bit confused. That section says

>> The prefix MAY be provided
>> using DHCPv6 PD, SLAAC with per-device VLANs, or any other means. 
>> 
>> multiple addresses when the host connects (e.g., the approximately 30
>> current clients...

I am rather unclear how that could be understood to mean that DHCPv6
is NOT RECOMMENDED (which is very different from not saying RECOMMENDED).

    Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Jul 2017 10:59:14 +1000

Hi,

I don't remember it being a mistake.

The fundamental intention and theme of the BCP is to ensure that hosts
can have enough addresses for whatever they and their applications
require, to ensure that lack of addresses doesn't become a constraint
hosts and applications have to work around. An on-demand, permission
based model for individual addresses doesn't prevent that constraint.

The alternative is continuing to treat addresses as though they are a
scarce resource and therefore assignment needs to be controlled at an
individual address level.

Fundamentally, we don't want hosts and application developers to have
to ask for permission from the network to innovate, nor have the
network impose artificial constraints on innovation. Artificial
address scarcity is following the traditional telephone network
scarcity model. (See David Isenberg's "Rise of the Stupid Network")

"The IPv6 self-selection addressing model does not necessarily suit
   the deployment requirements for many types of ipv6 networks,
   including enterprise, provider hosting, and various access network
   protocols (e.g.  docsis / gpon / ipoe); "

What are the specific deployment requirements?

If it is the common "address use auditing for security purposes", that
doesn't survive analysis. You can't force a malicious client to use
DHCPv6 for its addressing.

A malicious client can use statically configured addresses from within
one of the link prefixes and the DHCPv6 server won't have any record
of it.

A set of malicious clients can use link-local addresses for traffic
between themselves or bring up a new prefix on the link shared between
themselves via static configuration and the DHCPv6 server won't have
any record of it.

The RFC mentions ND cache contents recording for auditing purposes,
which is going to be much more effective, because it isn't dependent
on the address configuration method (i.e., currently stateful DHCPv6,
SLAAC, static configuration, and would accommodate any future ones if
they come into being.)

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Tue, 18 Jul 2017 00:44:29 -0700

>> has been successfully submitted by Nick Hilliard and posted to the

I have reviewed this document. Its reasoning for proposing an update to RFC 7934 is unsound. One relevant excerpt from §1 Introduction should suffice to explain. The text following the excerpt is premised entirely on the bad reasoning shown below, and it can be ignored accordingly.

>>> […] The recommendations in Section 8 of this document included the text:
>>> 
>>>       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 text could be interpreted as recommending that IPv6 networks
>>>    should not use not DHCPv6 [RFC3736], which provides new addresses in
>>>    response to explicit requests. […]

That would be a gross misinterpretation of the recommendation. The recommendation in RFC 7934 is clearly written and does not need updating to provide more clarity about the implications for usage of DHCPv6. The clear implication of the recommendation is *NOT* that networks SHOULD NOT provide DHCPv6 services. The clear implication of the recommendation is that networks SHOULD NOT require hosts to use DHCPv6 with IA_NA/IA_TA to obtain all their addresses.

>>> 
>>>                                 […] This interpretation is based on the
>>>    fact that a host which uses DHCPv6 IA_NA or IA_TA cannot use new
>>>    addresses without requesting them from a DHCPv6 server on the
>>>    network.

That’s not a fact. In fact. Factually speaking, a host which uses DHCPv6 IA_NA or IA_TA absolutely MAY use new addresses without requesting them from a DHCPv6 server on the networks. On a related note, see how the draft makes another leap of unsound reasoning in §3 Rationale.

>>>                              […] as it formally recommends that new
>>>    addresses should be assigned without explicit requests.  This
>>>    implicitly excludes all address assignment mechanisms, including
>>>    DHCPv6, which are not handled by the host itself.

A network MAY also provide a Prefix Information Option with A=1 for the host to use SLAAC to configure them. There are additional ways for networks to configure hosts with aggregated sets of addresses, e.g. obtaining prefixs with DHCPv6 Prefix Delegation, e.g. resolving prefixes with a Distributed Node Consensus Protocol [RFC 7787], et cetera.

> change until a proper debate has been had.  We invite WG comments on

For a proper debate to commence, the draft should be rewritten so that it’s reasoning about what RFC 7934 actually implies for networks using DHCPv6 is fundamentally sound. I’m not sure what such a draft would say, however, so I can’t comment about what the authors might be hoping to discuss.

--james woodyatt <[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 09:44:50 +0200

Yeah, a couple of reminders here.  First, the text in the RFC is explicitly
recommending the use of IA_PD as the _only_ solution to delegating
prefixes.   Second, this is an RFC, and the document that proposes a way to
delegate prefixes without DHCP is a draft, not an RFC.   That document is
not mentioned in the RFC.   So to suggest that this document says that IETF
consensus is that DHCP is NOT RECOMMENDED is simply incorrect.​

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 18 Jul 2017 09:58:29 +0200

Le 17/07/2017 à 23:21, Ross Chandler a écrit :
>> There is something wrong with that draft: it only allows for 64. 
>> Why? DHCPv6-PD can delegate other plengths, like 65.
> 

draft-kaiser-nd-pd-00 "Prefix Delegation extension to Neighbor Discovery
                        protocol" and the year 2002 drafts it cites like
                        draft-lutchann-ipv6-delegate-option-00.txt and
                        draft-haberman-ipngwg-auto-prefix-02.txt

During these discussions of these draft it was often said that DHCPv6-PD 
is the way to go, so let's go that way.  (this suggestion is independent 
of the 3GPP link discussion).

Alex

> 
>>>> uthors of RFC3315, and I agree with this view.
>>> Given the above two drafts DHCPv6-PD to hosts has an uphill 
>>> struggle to ever achieve widespread deployment.
>> 
>> I don’t think so.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 18 Jul 2017 10:09:49 +0200

Correct, the RFC does not say that DHCPv6 is NOT RECOMMENDED.

It does say that running a network for general purpose hosts that only
provides addresses via DHCPv6 IA_NA or IA_TA is NOT RECOMMENDED. More
precisely: if a network only provides addressing using DHCPv6, then it
should use a DHCPv6 mechanism that provides a /64 to each host. Currently
the only such mechanism is DHCPv6 PD.

Of course, it can use other non-DHCPv6 mechanisms as well, as long as they
either allow forming addresses on demand and/or they provide a /64 to every
device.

On Tue, Jul 18, 2017 at 9:44 AM, Ted Lemon <[email-masked]> wrote:

> Yeah, a couple of reminders here.  First, the text in the RFC is
> explicitly recommending the use of IA_PD as the _only_ solution to
> delegating prefixes.   Second, this is an RFC, and the document that
> proposes a way to delegate prefixes without DHCP is a draft, not an RFC.
> That document is not mentioned in the RFC.   So to suggest that this
> document says that IETF consensus is that DHCP is NOT RECOMMENDED is simply
> incorrect.​
>

---

From: joel jaeggli <[email-masked]>
Date: Tue, 18 Jul 2017 11:50:20 +0200

> DHCPv6-PD can delegate other plengths, like 65.

"a Unique IPv6 prefix (currently a /64 prefix)"

seems like a coordination problem. where it would be best not to
constrain the delegated prefix if it assumes that 64bit iids will be
assigned via slaac then /64 is the lower bound, however it could be
shorter e.g. 60 56 48 etc. so it would seem to be possible to delegate
the appropiate sized prefix for that application.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Jul 2017 13:16:53 +0100

Ted Lemon wrote:
> delegating prefixes.

Which is problematic because there was no consensus that I could see
during the discussion phase of draft-ietf-v6ops-host-addr-availability
that there was widespread use of DHCPv6-PD as a means of satisfying the
aims providing extra addresses for end hosts (as opposed to delegating
them to routers, which is a different issue entirely).  The lack of
consensus was remarked on at the time.  It seems extraordinary that this
also ended up

> Second, this is an RFC, and the document that
> document says that IETF consensus is that DHCP is NOT RECOMMENDED is
> simply incorrect.​

The interpretation of the principal author of BCP206 is diametrically
opposite on this point.

If there are polar opposite views in v6ops on how BCP206 should be
interpreted, this suggests that there is an ambiguity in the document.
If people in v6ops-wg cannot agree on what the document means, what hope
does anyone else have in interpreting it?

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Jul 2017 13:18:21 +0100

Nick Hilliard wrote:
> It seems extraordinary that this also ended up

"It seems extraordinary that this also ended up in the document."

reminder: finish emails before sending.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Jul 2017 13:20:54 +0100

> The topic in general was discussed.

... without consensus in the context of
draft-ietf-v6ops-host-addr-availability, and after the change was made
in section 8 despite a lack of consensus that it was an appropriate
change to make, there was no further discussion.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 14:34:18 +0200

Nick, it's not actually up to you to determine consensus, and you do not
seem to actually be describing a situation where there was a lack of
consensus.   If you feel that there was indeed an error made by the chairs,
who *were* responsible for calling consensus, the right thing to do would
be to appeal to the chairs, and if you are not satisfied by their response,
to appeal to the IESG, and so on.

What you should not do is have an argument about whether or not there was
consensus on the working group mailing list a year after the RFC was
published.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Jul 2017 14:14:52 +0100

Ted Lemon wrote:
> consensus.   If you feel that there was indeed an error made by the
> chairs, who /were/ responsible for calling consensus, the right thing to
> do would be to appeal to the chairs, and if you are not satisfied by
> their response, to appeal to the IESG, and so on.

I'm not attempting to determine consensus, simply expressing an opinion
that there was substantial opposition to the principals behind a
sentence that was inserted into the draft, i.e. querying whether that
consensus existed to start with.  There isn't a problem with querying a
decision.

The difficulty with formally appealing the consensus call is that the
change was inserted into the document in Feb 2016, and there were
several more revisions of the document before it was published as a BCP
some months later, and there were no objections because it wasn't
obvious what it meant at the time.

As an aside, the fact that there is a good deal of disagreement on its
interpretation today makes it clear that that this sentence is open to
vastly different interpretations.

So procedurally, there was not a problem with the consensus process
which means that an appeal to the chairs / IESG / etc would be almost
certain to fail, not least because this happened some time ago.  The
only obvious way to deal with the problem is to bring it back to the
working group with an explicit statement of the semantic problem, which
is what has happened.

It would be useful for the chairs to express an opinion if a different
approach were more appropriate.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 18 Jul 2017 14:59:56 +0100

Lorenzo Colitti wrote:
> issue being raised in that version of the draft (mostly by Philip and
> Gert, as I recall) was not "IA_NA should be used", but "DHCPv6 PD is not
> the only way to assign a prefix, and not a widely adopted way". -05
> addressed that issue by de-emphasizing DHCPv6 PD. As I read it, at the
> time there was pretty broad agreement at the time that IA_NA was not a
> good choice both because it is limited in terms of the number of total
> addresses that can be assigned and because it requires that the client
> send explicit requests, which has the problems listed in section 4.

I don't expect you to agree with the opinions expressed in
draft-hilliard-v6ops-host-addr-update.  To requote Gert:

> I missed that this was intended for BCP, otherwise I would have complained
> earlier.  Haven't seen anyone state that they are deploying DHCPv6-PD to
> hosts except you, so "CP" is really questionable... 
> 
> For an "Lorenzo does not like DHCPv6 IA_NA" draft, Informational sounds 
> about right.

However, there is no basis for you to assert that there was broad
agreement that IA_NA was a bad choice, and less still to codify that
into a statement which, in your opinion, creates an IETF recommendation
not to use DHCPv6 IA_NA.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 16:08:34 +0200

The change was not inserted into the document in February of 2016.  Be that
as it may, my point is that this particular aspect of the discussion is out
of scope: if there was a process failure, appeal is your option.   I agree
that it's not a practical option.

So, independent of that, if you think that the current documented consensus
is a *problem, *then you are absolutely right to want to do a new document.
  If that's what you want, you need to do (at least) two things:

1. Explain, in a way that actually makes sense, what it is that the
document says that is wrong, and why it is wrong.   You haven't done that.

2. Explain what it should say instead.   I would argue that your
explanation either has to say "privacy isn't that important after all" or
else address the privacy issue in a way that is equally satisfactory.  I
don't see any way to do that with IA_NA.   IA_NA by definition puts the
whole privacy thing off on the DHCP server, which may or may not do the
right thing.   The client has no agency.   Using IA_PD or prefix delegation
are both clearly superior solutions to the problem.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 16:09:46 +0200

> Using IA_PD or prefix delegation are both clearly superior solutions to
the problem.

That was meant to be "or SLAAC."

On Tue, Jul 18, 2017 at 4:08 PM, Ted Lemon <[email-masked]> wrote:

> The change was not inserted into the document in February of 2016.  Be
> that as it may, my point is that this particular aspect of the discussion
> is out of scope: if there was a process failure, appeal is your option.   I
> agree that it's not a practical option.
>
> So, independent of that, if you think that the current documented
> consensus is a *problem, *then you are absolutely right to want to do a
> new document.   If that's what you want, you need to do (at least) two
> things:
>

---

From: james woodyatt <[email-masked]>
Date: Tue, 18 Jul 2017 16:41:22 +0200

On Jul 18, 2017, at 15:59, Nick Hilliard <[email-masked]> wrote:
> agreement that IA_NA was a bad choice and less still to codify that

Once again, RFC 7934 does not entail that, and the only people in the working group who are claiming that it does— despite its otherwise clear language— are the authors of I-D.hilliard-v6ops-host-addr-update. There is no recommendation in RFC 7934— explicit or implicit— against the use of DHCPv6 IA_NA in conjunction with other methods for hosts to obtain addresses without making explicit requests to the network.

There is a bullet list in §4 "Problems with Restricting the Number of Addresses per Host” that goes into some detail about some (not all) of the problems with networks where hosts MUST acquire IPv6 interface addresses with explicit requests to the network, e.g. using DHCPv6 with IA_NA or IA_TA. Doing *that* is explicitly NOT RECOMMENDED in §8 “Recommendations” of RFC 7934, and it is a fact that most IPv6 network deployments conform to this best current practice accordingly, and there are many additional well-known problems with diverging from that practice that were not documented in RFC 7934.

It’s not at all clear to me what is the purpose of this draft, but if I understand correctly, then its objective is to propose that IETF Best Current Practice include general purpose Internet networks where general purpose hosts acquire IPv6 interface addresses only by using DHCPv6 IA_NA requests to obtain addresses from a constrained pool one at a time. I have a lot of difficulty seeing how that makes any sense given the clear reasoning provided in RFC 7934 for the recommendation against it.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 18 Jul 2017 16:54:20 +0200

> consensus existed to start with.  There isn't a problem with querying a

There was opposition on an earlier revision, but then the text was amended.
I think it's fair to say that anyone wanting to continue to object had the
opportunity to do so.

> change was inserted into the document in Feb 2016,

There was no substantive change in this area since -01 was published in
September 2015. The recommendation that if a network requires DHCPv6 it
should use DHCPv6 PD to hand out a /64 has been in the draft since then.

> vastly different interpretations.

I think a lot of the disagreement on interpretation is due to the fact that
some in the discussion (including myself) have inappropriately
characterized the RFC as recommending against the *use of DHCPv6 in
general*. It doesn't  - it recommends against *requiring* the use of IA_NA
/ IA_TA in order to use IPv6 on a particular network. I think the confusion
is limited to this thread though; then RFC itself is pretty clear.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 19 Jul 2017 01:23:36 +1000

I have read the draft and re-read rfc7934 and now I'm completely confused.
First of all, I can not see where rfc7934 says that DHCPv6 is not recommended.

I had to use all my imagination and still not sure how the phrase 'it
is RECOMMENDED that the network
give the host the ability to use new addresses without requiring
explicit requests.' can be read as 'DHCPv6 is not recommended'.

Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA
cannot use new addresses without requesting them from a DHCPv6 server
on the network.' does not seem to be accurate.  As this statement
appears to be the key point of your document, I believe it needs to be
 fixed before we can proceed.

The third point:

"The third paragraph notes that DHCPv6 stateful address assignment
   (IA_NA or IA_TA) can be used to provide multiple addresses when the
   host connects to the network, but does not mention that the host can
   issue multiple dhcpv6 requests, thereby allowing arbitrary numbers of
   assignments rather than the stated limit of approximately 30.  As the
   text in this paragraph is incorrect, it too has been removed.
"
If you believe the text is incorrect (or shall I say 'incomplete'?) as
it does not mention multiple requests,
it would probably make sense to see some suggestions on amending the
text, updating it with details re: multiple requests?

I do not think that the second and third paragraphs should be removed
as they contain clarifications on the recommendations provided in the
first paragraph. Removing them would make the document less clear and
would open the door to misrepresentations instead of preventing them.

Last but not least...The first paragraph of the section 3 sounds a bit
like an overstatement..It's not clear from that text how
recommendations provided in the rfc7934 can have such dramatic impact
on the future of DHCPv6.

-- 
SY, Jen Linkova aka Furry

---

From: Scott Morizot <[email-masked]>
Date: Tue, 18 Jul 2017 12:38:08 -0500

Perhaps the actual problem is a limited active participation in the IETF
process by certain groups, such as the large enterprise networks (outside
enterprise networks of large technology companies) sphere? That has always
been my day to day environment and focus whether as an application
developer, network engineer, or from any of the other hats that are dropped
in my lap, including interacting with groups of organizations outside my
own. I confess I read mailing list discussions intermittently and actively
say anything much less frequently than I read. But comments like the below
leave me bemused.

Those sorts of networks are highly constrained. Hosts and developers have
to coordinate even to be allowed on the network. Things that are purchased
and deployed generally have to meet our requirements and lots of things are
eliminated from consideration because they don't. If something has special
requirements, there's a lengthy process designing, testing, and documenting
the changes in the security boundary. Innovation is certainly restricted
and coordinated, even with in house developed applications.

There are lots of processes and tools integrated with DHCP assignment
information. But that's hardly the only data collected, the only layer of
protection, or the only avenue pursued when doing forensic analysis of an
attack. Connection security in one form or another is used. ARP/Neighbor
table information (as well as configuration in general) is collected and
tracked. Log data at every level is collected. There's IDS/IPS and packet
collectors at different key points. There are firewalls at all sorts of
different points from the host up. But no large enterprise is merely
looking for purely malicious traffic. They are also auditing and analyzing
all activity by authorized users. It's a highly inspected, highly
constrained networking environment and always will be.

A lot of those automated processes are tied into DHCP data. It's not that
that's the only source of forensic data, the sole audit point, or the
single point of protection. But a lot of automated tools/processes are
built around that data and that is not going to change quickly. Perhaps
when IPv4 is removed from much of the enterprise, it can be considered,
though there would have to be a compelling reason for enterprises to make
such a change. No such compelling reason currently exists. It will not
happen before then except in very special circumstances on different
networks from most hosts, not on general purpose data networks.

Host developers who want to sell to such enterprises will support DHCPv6
IA_NA address assignment on networks that provide no other alternative.
They already do for the most part because those networks exist today. And
they will continue to exist for a good number of years to come, whatever
the IETF decides to recommend or not recommend. If a host/node developer
has a special use case (as a limited IOT device such as door key card
access devices and alarm sensors very well might) and a large enterprise of
the sort I've described has a need for it, that might be engineered in a
special network of its own. So it's not an absolute that any given
host/node that wants to sell to large enterprises of the sort I've noted
above has to support DHCPv6 IA_NA address assignment. But as a general rule
of thumb? That should probably be the default expectation. It should be
considered, at least.

So I support the idea behind the changes to RFC 7934 proposed in the draft,
however they might be wordsmithed, as it more accurately reflects reality.
The current description may reflect a "best common practice" for general
use data on some networks and in some environments. It is not even vaguely
the common practice elsewhere. And it's unlikely to be anytime soon. If the
purpose of the document is to express what the IETF wished were the common
practice on most networks, that's fine. If its purpose is to express the
actual common practice, the current document falls short.

I have a hard time feeling too strongly about it, though. Host/node
developers often do want to sell to large enterprises, and as such they
typically will meet their specified requirements. I don't expect that to
change whatever the IETF chooses to publish. That's one situation in which
money does usually talk.

Scott

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 19:54:18 +0200

The current document recommends generally against the particular use of
DHCP that you are using, but does not forbid it.   This is the correct
recommendation for most devices on the Internet.   The set of devices that
you use do not fall into that category, so the suggestion is really not at
all applicable to your use case.   This is why the document says what it
says.   It doesn't even say "SHOULD NOT."   It just says "won't have good
privacy characteristics, and therefore is not preferred."

Asking that IETF recommendations, which, again, remember, are aimed at *all
devices on the internet*, instead be tailored to just your use case, is not
reasonable.   The reason that the language reads the way it does is so as
to not exclude your use case.   I don't see how you could possibly justify
language that was any more accommodating of your use case.   As you say,
vendors of the sorts of devices that you use are not going to read that
document and think "oh, I guess I should disable IA_NA support now."

So what exactly would an update accomplish?   Please don't send another
long wall of text.   Just explain how we can balance these two competing
needs better than we currently are doing?

On Tue, Jul 18, 2017 at 7:38 PM, Scott Morizot <[email-masked]> wrote:

> So I support the idea behind the changes to RFC 7934 proposed in the
> draft, however they might be wordsmithed, as it more accurately reflects
> reality. The current description may reflect a "best common practice" for
> general use data on some networks and in some environments. It is not even
> vaguely the common practice elsewhere. And it's unlikely to be anytime
> soon. If the purpose of the document is to express what the IETF wished
> were the common practice on most networks, that's fine. If its purpose is
> to express the actual common practice, the current document falls short.
>

---

From: Scott Morizot <[email-masked]>
Date: Tue, 18 Jul 2017 12:57:34 -0500

On Tue, Jul 18, 2017 at 9:41 AM, james woodyatt <[email-masked]> wrote:

>
> It’s not at all clear to me what is the purpose of this draft, but if I
> understand correctly, then its objective is to propose that IETF Best
> Current Practice include general purpose Internet networks where general
> purpose hosts acquire IPv6 interface addresses only by using DHCPv6 IA_NA
> requests to obtain addresses from a constrained pool one at a time. I have
> a lot of difficulty seeing how that makes any sense given the clear
> reasoning provided in RFC 7934 for the recommendation against it.
>
>
I have no particular problem with that as a recommendation for general
purpose Internet networks if the recommendation is intended to exclude a
significant chunk of the enterprise network world. For a general purpose
network meant to support devices controlled and operated by other parties
from the network operators, it may even be a fine recommendation. (That's
not really my world, so I can't say.)

I think this came up, if I tracked discussions properly (a big if), because
this recommendation for address assignment in general purpose networks was
used as one of the reasons to fight against recommending that node
developers should support DHCPv6 elsewhere. Again, not really a node/client
developer except in the past for some limited in house things, but that
strikes me as bad advice to that group depending on their target user. Of
course, I don't really think such developers are going to rely on an IETF
recommendation to decide which features they need to incorporate anyway. Or
at least not solely. So that's why I don't feel too strongly about it
either way.

I would object more strenuously if someone were actually trying to change
the actual DHCPv6 protocol standard to eliminate IA_NA/IA_TA, but I believe
there would be a chorus of objections to such a move anyway, so I'm not
particularly concerned about that.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 20:12:18 +0200

The way this stuff works is that we (the IETF) make a recommendation based
on what the most common use case is, and make the recommendation open
enough that it covers the less common use cases, or else enumerate expected
use cases and make recommendations specific to each case.   In this case,
the text falls into the first category.   It would be totally inappropriate
to deprecate IA_NA on the basis of this text.   As far as I know, no such
plan is afoot in the DHC working group.   It would also be inappropriate to
make that change in this working group.   :)

On Tue, Jul 18, 2017 at 7:57 PM, Scott Morizot <[email-masked]> wrote:

> I think this came up, if I tracked discussions properly (a big if),
> because this recommendation for address assignment in general purpose
> networks was used as one of the reasons to fight against recommending that
> node developers should support DHCPv6 elsewhere. Again, not really a
> node/client developer except in the past for some limited in house things,
> but that strikes me as bad advice to that group depending on their target
> user. Of course, I don't really think such developers are going to rely on
> an IETF recommendation to decide which features they need to incorporate
> anyway. Or at least not solely. So that's why I don't feel too strongly
> about it either way.
>

---

From: Scott Morizot <[email-masked]>
Date: Tue, 18 Jul 2017 13:14:10 -0500

> needs better than we currently are doing?
As a recommendation for host address assignment on a general purpose
network, it's fine. However, it appears that making DHCPv6 IA_NA/IA_TA NOT
RECOMMENDED for host address assignment in that context is being taken as a
reason by some to recommend against hosts supporting it. I can see the
logic being used. If the IETF recommends against it for networks, it should
recommend against support for it in hosts. But that's not exactly the same
thing. Again, from a practical perspective I don't think it will matter
much either way. But I was simply trying to point out that there are some
pretty large networks out there where the general recommendation really
doesn't apply.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 18 Jul 2017 20:47:23 +0200

I agree that in the past there may have existed a risk of cellular
networks assigning a single IPv6 address (w/o even a plen) to one UE.
So one wanted a recommendation against DHCPv6 single address per End node.

However, I still think this RFC is a mis-written recommendation.

It would have been much simpler to RECOMMEND to allocate multiple
addresses per End node, as many as that End node requires, be them
individual addresses, or addresses aggregated into prefixes, or multiple
prefixes.

But the current recommendation as it stands looks weird.

Le 18/07/2017 à 17:23, Jen Linkova a écrit :
> I have read the draft and re-read rfc7934 and now I'm completely 
> confused. First of all, I can not see where rfc7934 says that DHCPv6 
> is not recommended.

RFC7934:
> In order to avoid the problems described above and preserve the 
> Internet's ability to support new applications that use more than one
> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide
> multiple IPv6 addresses from each prefix to general-purpose hosts.

What makes one think that some network deployment might block the
forming of multiple IPv6 addresses from each prefix?

Or maybe the "from each prefix" is superfluous?

Because I dont think there is any method that provides a prefix yet
restricts the use to just one address in that prefix.

If a Router sends an RA to many Hosts then each of these Hosts may
configure many addresses within it.

If a Router sends an RA unicast to a Host then that Host may configure
many addresses within it.

If an address is delivered by a DHCP Server, then that is an address
without any prefix specified.

If a prefix is delegated by a DHCP Server then a receiving Client may
configure many addresses within that prefix.

> To support future use cases, it is NOT RECOMMENDED to impose a hard 
> limit on the size of the address pool assigned to a host.

What do you mean?  Is that pool a DHCP pool?  What is an example of
someone imposing a hard limit on the size of that pool?

> Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6
>  address per prefix.

I did not see any place where there is such a restriction.  I wonder
what is an example where a Host was limited to only one IPv6 address
formed out of a prefix.

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

This "either or" sounds like exclusive or.  But on cellular networks the
Host is provided a dedicated prefix _and_ forms new addresses autonomously.

This is confusing.

> addresses that can fit into a single packet)

?  is there such a restriction in the DHCP spec?  Is it that DHCP
Ack/Advertise could carry only 30 addresses?

> would accommodate current clients, but it sets a limit on the number 
> of addresses available to hosts when they attach and therefore limits
> the development of future applications.

Yes, it would set a limit _if_ DHCP had such a limit.  Do you think DHCP
has a limit in the number of addresses it could assign in an Ack or
Advertise?

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

Do we have a packet dump showing this?  I am asking because 30 addresses
make for 480bytes...

Jen said:
> is RECOMMENDED that the network give the host the ability to use new
> addresses without requiring explicit requests.' can be read as 
> 'DHCPv6 is not recommended'.

Because SLAAC does not obtain addresses by using Requests.  That's DHCP
who uses Requests to obtain addresses.

That RECOMMENDation is clearly written by someone who has some deep
disapproval of DHCP.

> appears to be the key point of your document, I believe it needs to
> be fixed before we can proceed.

On my side, I can agree.  But that is your discussion.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 21:28:35 +0200

Alexandre, it's a really important recommendation of the document that the
host be allowed to allocate *its own* addresses, rather than having to rely
on the correctness of the DHCP IA_NA implementation.   So the language you
are proposing would completely change that.

On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu <
[email-masked]> wrote:

>> confused. First of all, I can not see where rfc7934 says that DHCPv6 is not
>> recommended.
>>
>
> RFC7934:
>
> To support future use cases, it is NOT RECOMMENDED to impose a hard limit
>> on the size of the address pool assigned to a host.
>>
>
> 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
> would accommodate current clients, but it sets a limit on the number of
>> addresses available to hosts when they attach and therefore limits
>> addresses without requiring explicit requests.' can be read as 'DHCPv6 is
>> not recommended'.
>>
>
> Secondly, the statement 'a host which uses DHCPv6 IA_NA or IA_TA cannot
>> use new addresses without requesting them from a DHCPv6 server

---

From: Ross Chandler <[email-masked]>
Date: Tue, 18 Jul 2017 21:00:52 +0100

> On 18 Jul 2017, at 08:58, Alexandre Petrescu <[email-masked]> wrote:
> 
> During these discussions of these draft it was often said that DHCPv6-PD is the way to go, so let's go that way.  (this suggestion is independent of the 3GPP link discussion).
> 

The “host OS developers” have repeatedly expressed technical objections to DHCPv6.

https://www.ietf.org/mail-archive/web/v6ops/current/msg26201.html <https://www.ietf.org/mail-archive/web/v6ops/current/msg26201.html>
https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html <https://www.ietf.org/mail-archive/web/v6ops/current/msg26068.html>
https://www.ietf.org/mail-archive/web/v6ops/current/msg26170.html <https://www.ietf.org/mail-archive/web/v6ops/current/msg26170.html>

I could ask my fixed residential broadband CPE vendors to support prefix delegation. Their question back would be which OSes support it and can they prioritise other things in the list.
But it doesn’t look like Android, iOS, and possibly also macOS and Windows have any plans to support DHCPv6-PD. There is a draft alternative way of doing it using RAs that appears to have more support from the host OS developers.

Ross

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 18 Jul 2017 22:09:45 +0200

Le 18/07/2017 à 21:28, Ted Lemon a écrit :
> Alexandre, it's a really important recommendation of the document 
> that the host be allowed to allocate /its own/ addresses,

I dont understand how a host can allocate its own addresses.  Or do you
mean IID?

(we are very far from Host deciding an address, suggesting it to the
network, and the network update the routes - but I think you dont mean
that either.)

Alex

> rather than having to rely on the correctness of the DHCP IA_NA 
> implementation.   So the language you are proposing would completely 
> change that.
> 
> On Tue, Jul 18, 2017 at 8:47 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> individual addresses, or addresses aggregated into prefixes, or 
> multiple prefixes.
> 
> If a Router sends an RA unicast to a Host then that Host may 
> This "either or" sounds like exclusive or.  But on cellular networks 
> the Host is provided a dedicated prefix _and_ forms new addresses 
> autonomously.
> 
> This is confusing.
> 
> Yes, it would set a limit _if_ DHCP had such a limit.  Do you think 
> DHCP has a limit in the number of addresses it could assign in an
> Ack or Advertise?
> 
> Do we have a packet dump showing this?  I am asking because 30 
> addresses make for 480bytes...
> 
> Jen said:
> 
> Because SLAAC does not obtain addresses by using Requests.  That's 
> DHCP who uses Requests to obtain addresses.
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Jul 2017 23:01:07 +0200

If a host gets a /64, it can allocate addresses out of it.   If the prefix
allows autoconfiguration, it can allocate its own addresses using SLAAC.

On Tue, Jul 18, 2017 at 10:09 PM, Alexandre Petrescu <
[email-masked]> wrote:

>> Alexandre, it's a really important recommendation of the document that
>> the host be allowed to allocate /its own/ addresses,
>>
>
>> implementation.   So the language you are proposing would completely change
>> that.
>>
>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>> What makes one think that some network deployment might block the forming
>> of multiple IPv6 addresses from each prefix?
>>
>> has a limit in the number of addresses it could assign in an
>> Ack or Advertise?
>>
>> [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/l
>> istinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>>
>>
>>

---

From: Jen Linkova <[email-masked]>
Date: Wed, 19 Jul 2017 08:47:34 +1000

> who uses Requests to obtain addresses.

Let me give you an example.
Imagine that we have apples and oranges. Then I say:
'It is recommended that children are given apples every day'.
Does it mean "giving children oranges is not recommended'? No. False.
However the statement 'giving children oranges (and oranges ONLY) is
not recommended' is true.
See the difference? ;)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Jul 2017 11:33:37 +1200

> explicit requests.' can be read as 'DHCPv6 is not recommended'.

Yes. We still appear to be having an argument based on the idea that
if something is not "RECOMMENDED" it is therefore "NOT RECOMMENDED".
At least, that's the most sense I can make of it.

Nothing in RFC7934 says that any part of DHCPv6 is NOT RECOMMENDED
(or SHOULD NOT be used, which is the same thing). Specifically,
there is no normative statement whatever about IA_NA or IA_TA.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Jul 2017 13:37:06 +1000

On 19 July 2017 at 06:09, Alexandre Petrescu
<[email-masked]> wrote:
>> host be allowed to allocate /its own/ addresses,
>
>

I'm sure that is what Ted fundamentally means, although it extends a
bit beyond choosing just an IID. It also involves how many IIDs to
generate and use with the received prefixes (one for all prefixes, one
per prefix, or even mulitple IIDs per prefix) to create addresses.

>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> In order to avoid the problems described above and preserve the Internet's
>> ability to support new applications that use more than one

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 07:19:18 +0200

Prefix+iid=address. But iid is really a misnomer.

On Jul 19, 2017 5:37 AM, "Mark Smith" <[email-masked]> wrote:

> the
> change
> confused.
> Internet's
> forming
> limit

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 19 Jul 2017 08:11:00 +0200

On 19 Jul 2017 01:33, "Brian E Carpenter" <[email-masked]>
wrote:

But it does make a normative recommendation against their exclusive use.

Specifically, it says it is RECOMMENDED to give hosts the ability to form
new addresses without explicit requests to the network. That recommendation
cannot be met on a network that *only* provides addresses via IA_NA / IA_TA.

So while it makes no normative recommendation about IA_NA / IA_TA
themselves, it does make a normative recommendation against running a
network that uses IA_NA / IA_TA as its only address assignment mechanism.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 08:23:18 +0200

But, to be clear, if you do not follow the RECOMMENDation, you are still in
spec, because it is a RECOMMENDation, not a REQUIREment.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Jul 2017 09:20:55 +0200

Maybe a better recommendation, in no particular order, is to give a Host
DHCP-PD, many-DHCP-Address, and RA with A bit.  Again, in no particular
order and potentially all at the same time.

Le 18/07/2017 à 23:01, Ted Lemon a écrit :
> If a host gets a /64, it can allocate addresses out of it.   If the 
> prefix allows autoconfiguration, it can allocate its own addresses
> using SLAAC.

Alex

> 
> On Tue, Jul 18, 2017 at 10:09 PM, Alexandre Petrescu 
> I dont understand how a host can allocate its own addresses.  Or do
> you mean IID?
> 
> network, and the network update the routes - but I think you dont
> mean that either.)
> 
> Alex
> 
> <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>> wrote:
> 
> networks assigning a single IPv6 address (w/o even a plen) to one
> UE. So one wanted a recommendation against DHCPv6 single address per
> End node.
> 
> Internet's ability to support new applications that use more than
> one IPv6 address, it is RECOMMENDED that IPv6 network deployments 
> provide multiple IPv6 addresses from each prefix to general-purpose
> hosts.
> 
> 
> If a prefix is delegated by a DHCP Server then a receiving Client
> may configure many addresses within that prefix.
> 
> multiple addresses when the host connects (e.g., the approximately
> 30 addresses that can fit into a single packet)
> 
> 
> of addresses available to hosts when they attach and therefore
> limits the development of future applications.
> 
> 
> DHCP has a limit in the number of addresses it could assign in an Ack
> or Advertise?
> 
> 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.
> 
> 
> I had to use all my imagination and still not sure how the phrase
> 'it is RECOMMENDED that the network give the host the ability to use
> new addresses without requiring explicit requests.' can be read as 
> cannot use new addresses without requesting them from a DHCPv6 
> server on the network.' does not seem to be accurate.  As this
> statement appears to be the key point of your document, I believe it
> needs to be fixed before we can proceed.
> 
> 
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/v6ops 
> <https://www.ietf.org/mailman/listinfo/v6ops 
> <https://www.ietf.org/mailman/listinfo/v6ops>>
> 
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 09:24:13 +0200

What would you state as the reason for giving a host all of these?

On Jul 19, 2017 9:20 AM, "Alexandre Petrescu" <[email-masked]>
wrote:

>> [email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>>
>> wrote:
>>
>> one IPv6 address, it is RECOMMENDED that IPv6 network deployments provide
>> I did not see any place where there is such a restriction.  I wonder what
>> is an example where a Host was limited to only one IPv6 address formed out
>> of a prefix.
>>
>> space (see Section 4), it is RECOMMENDED that the network
>> 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.
>>
>>
>> DHCPv6 packet, given a typical MTU of 1500 bytes or smaller,
>> is approximately 30.
>>
>>
>> use new addresses without requesting them from a DHCPv6 server on the
>> network.' does not seem to be accurate.  As this
>> <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/v6ops <
>> https://www.ietf.org/mailman/listinfo/v6ops> <
>> https://www.ietf.org/mailman/listinfo/v6ops <
>> https://www.ietf.org/mailman/listinfo/v6ops>>
>>
>>
>>
>>

---

From: Jen Linkova <[email-masked]>
Date: Wed, 19 Jul 2017 17:39:17 +1000

> At least, that's the most sense I can make of it.

Exactly my impression. I suggest we ask for a tutorial on the formal
logic to be organized on Sunday before IETF100
so we all will be on the same page.
(Unless we make 'almost everything is prohibited and everything not
prohibited is mandatory' an official rule ;))

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Jul 2017 10:07:28 +0200

Le 19/07/2017 à 00:47, Jen Linkova a écrit :
>>> 'it is RECOMMENDED that the network give the host the ability to
>>> use new addresses without requiring explicit requests.' can be
>>> read as 'DHCPv6 is not recommended'.
>> 
>> 
> Let me give you an example. Imagine that we have apples and oranges.
> Then I say: 'It is recommended that children are given apples every
> day'. Does it mean "giving children oranges is not recommended'? No.
> False. However the statement 'giving children oranges (and oranges
> ONLY) is not recommended' is true. See the difference? ;)

Give children 3 apples and oranges a day.

Alex

---

From: Jen Linkova <[email-masked]>
Date: Wed, 19 Jul 2017 18:26:31 +1000

> Give children 3 apples and oranges a day.

Is it a question or a statement? ;) Obviously, the statement 'It is
recommended that children are given apples every day' does not
prohibit giving children 3 apples and oranges (neither it makes it
'not recommended').
(Please note that we are discussing the example above and this example
ONLY, no conclusions about recommended number of IPv6 addresses on
hosts can be made from the statement that it's OK to give children 3
apples'.

However....Let's look at this example...
If the Kids Nutrition Working Group agreed that ''It is recommended
that children are given apples every day', then:
- 'Give children 3 apples and oranges a day' is allowed and does not
conflict with the recommendation.
If the WG also agreed that 'it is NOT RECOMMENDED to impose a hard
limit on how many apples children are allowed to have', then:
- "Give children 3 apples and oranges a day." statement violates the
recommendation if '3' is a hard limit and children are not allowed 4
apples.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Jul 2017 11:04:06 +0200

Ted, about losing face: I agree the RFC does not recommend against DHCP.

> Give children 3 apples and oranges a day.

Let me try to clarify.

I find it to be a better RECOMMENDation to state clearly: please use 
DHCP-PD, multiple-DHCP-Address, RA-with-Abit-set, in arbitrary order, 
and potentially all simultaneously.

This recommendation is better than being silent about which protocol 
should be (or not be) used.

Alex

---

From: Gert Doering <[email-masked]>
Date: Wed, 19 Jul 2017 11:08:35 +0200

Hi,

On Tue, Jul 18, 2017 at 12:44:29AM -0700, james woodyatt wrote:
> That would be a gross misinterpretation of the recommendation.
> The recommendation in RFC 7934 is clearly written and does not need
> updating to provide more clarity about the implications for usage
> of DHCPv6. The clear implication of the recommendation is *NOT*
> that networks SHOULD NOT provide DHCPv6 services. The clear implication
> of the recommendation is that networks SHOULD NOT require hosts to
> use DHCPv6 with IA_NA/IA_TA to obtain all their addresses.

And this is not a "recommendation that networks SHOULD NOT provide DHCPv6
stateful addressing services"?

Which is the point, isn't it?

> That???s not a fact. In fact. Factually speaking, a host which uses 
> DHCPv6 IA_NA or IA_TA absolutely MAY use new addresses without requesting 
> them from a DHCPv6 server on the networks. 

How so, if SLAAC is not active?

I can see the point that Nick is making: this document implicitly recommends
that networks should not use DHCPv6 IA_NA (-only), without explicit WG
consensus that this should be BCP.

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: Lorenzo Colitti <[email-masked]>
Date: Wed, 19 Jul 2017 11:16:33 +0200

> stateful addressing services"?

There is no recommendation that networks SHOULD NOT provide stateful DHCPv6
addressing services.

There is a recommendation that networks SHOULD NOT provide *only* stateful
DHCPv6 addressing services (where "addressing services" currently means
IA_NA / IA_TA, but more in general, means any addressing service that
requires an explicit request to the network in order to obtain an address).

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Jul 2017 11:20:02 +0200

Same reasons as are stated in the current document; and more, related to 
scalable growth at the edges of the network.

Alex

Le 19/07/2017 à 09:24, Ted Lemon a écrit :
> On Jul 19, 2017 9:20 AM, "Alexandre Petrescu" 
>         If a host gets a /64, it can allocate addresses out of it.   If
>         the prefix allows autoconfiguration, it can allocate its own
>         addresses
>         using SLAAC.
> 
> 
>     Alex
> 
> 
>         (we are very far from Host deciding an address, suggesting it to
>         the network, and the network update the routes - but I think you
>         dont
>         mean that either.)
> 
>         Alex
> 
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>>>> wrote:
> 
>         one IPv6 address, it is RECOMMENDED that IPv6 network
>         deployments provide multiple IPv6 addresses from each prefix to
>         general-purpose
>         hosts.
> 
> 
>         If an address is delivered by a DHCP Server, then that is an
>         address without any prefix specified.
> 
>         Particularly, it is NOT RECOMMENDED to limit a host to only one
>         IPv6 address per prefix.
> 
> 
>         I did not see any place where there is such a restriction.  I
>         wonder what is an example where a Host was limited to only one
>         IPv6 address formed out of a prefix.
> 
>         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.
> 
> 
>         new addresses without requiring explicit requests.' can be read
>         as 'DHCPv6 is not recommended'.
> 
> 
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         <https://www.ietf.org/mailman/listinfo/v6ops>>>
> 
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2017 11:36:42 +0200

Let me restate my question then.

Right now the document explicitly does not recommend DHCP IA_NA.   It
doesn't recommend it because it doesn't provide the privacy characteristics
that the other options provide.   Your suggestion essentially says that the
document should recommend it.   So you must have some reason why it should
make this recommendation.   Can you state that reason?

On Wed, Jul 19, 2017 at 11:04 AM, Alexandre Petrescu <
[email-masked]> wrote:

>>> On Wed, Jul 19, 2017 at 4:47 AM, Alexandre Petrescu <
> DHCP-PD, multiple-DHCP-Address, RA-with-Abit-set, in arbitrary order, and
> potentially all simultaneously.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Jul 2017 16:05:46 +0200

DHCPv6 has no more privacy risks than any other method like SLAAC or PPP 
has.

If all a network can provide is DHCPv6-Address then make it multiple, 
because the Node needs more addresses for itself and for other nodes 
behind it.

Even better - provide DHCPv6 PD.

Alex

Le 19/07/2017 à 11:36, Ted Lemon a écrit :
> doesn't recommend it because it doesn't provide the privacy 
> characteristics that the other options provide.   Your suggestion 
> essentially says that the document should recommend it.   So you must 
> have some reason why it should make this recommendation.   Can you state 
> that reason?
> 
> On Wed, Jul 19, 2017 at 11:04 AM, Alexandre Petrescu 
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
> 
>                 Jen said:
> 
> 
>     DHCP-PD, multiple-DHCP-Address, RA-with-Abit-set, in arbitrary
>     order, and potentially all simultaneously.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Jul 2017 13:57:34 +1200

> requires an explicit request to the network in order to obtain an address).

But there *is not* what Gert said: "The clear implication
of the recommendation is that networks SHOULD NOT require hosts to
use DHCPv6 with IA_NA/IA_TA to obtain all their addresses."

Once again, not saying that X is recommended is not the same as
saying X SHOULD NOT** be done. Warning that X has consequences,
as the RFC does, is not the same thing as saying X SHOULD NOT be done.

Formally saying that something that we standardised SHOULD NOT be
done is a major step and one that the IETF takes quite rarely,
when there is a major operational or security issue.

When we do it, the language is pretty explicit, e.g.
https://tools.ietf.org/html/rfc7526#section-5

The language in RFC 7934 is not remotely comparable.

** and of course "SHOULD NOT" only means that
   "there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed"
   [RFC2119]. In other words, even if 7934 did state the "SHOULD NOT",
   it doesn't mean "MUST NOT".

     Brian

---

From: Gert Doering <[email-masked]>
Date: Thu, 20 Jul 2017 08:24:28 +0200

Hi,

> requires an explicit request to the network in order to obtain an address).

Since there is no reason to deploy both IA_NA/IA_TA *and* SLAAC, it
effectively *is*, and no amount of word-weaseling is going to change this.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 20 Jul 2017 08:27:51 +0200

Hi,

> as the RFC does, is not the same thing as saying X SHOULD NOT be done.

If X and Y are mutually exclusive, a document saying "X SHOULD BE DONE"
is effectively implying "Y SHOULD NOT BE DONE".

Right?

(And do not tell me that people would do DHCPv6 IA_NA/IA_TA *and* SLAAC
on the same network - technically you could, but nobody would do that,
given that it voids the reason *why* IA_NA/IA_TA are used: control, DNS,
etc - note I'm not saying "security")

> The language in RFC 7934 is not remotely comparable.

Yeah, it was nicely done.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jul 2017 10:21:03 +0200

> etc - note I'm not saying "security")

That's not true at all. There are (tens of) millions of home networks that
do both IA_NA and SLAAC.

SLAAC addresses provide ample address space and have robust privacy
properties, and IA_NA addresses are can be useful for things like home
servers that need stable addresses and dynamic DNS entries, such as home
servers.

---

From: Gert Doering <[email-masked]>
Date: Thu, 20 Jul 2017 10:30:02 +0200

Hi,

> That's not true at all. There are (tens of) millions of home networks that

That's an interesting statement.  Which products do it that way today,
out of the box?

Those home network CPEs with v6 support I've seen so far do not do 
IA_NA/IA_TA.

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Jul 2017 10:33:38 +0200 (CEST)

> Since there is no reason to deploy both IA_NA/IA_TA *and* SLAAC, it

This is not true. Deploying IA_NA gives you an address you can track and 
connect to the device on if you want to (if this is your device and you 
want to manage it for instance), then the device can use the SLAAC 
addresses for anything it needs more addresses for.

I ran my home like this for a long time, when I had a router that actually 
supported DHCPv6 IA_NA. The one I currently use doesn't.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jul 2017 10:46:09 +0200

> That's an interesting statement.  Which products do it that way today,

It depends on the vendor, of course. AIUI all of Comcast's home routers do
DHCPv6 as well as SLAAC and DHCPv4. IIRC my off-the-shelf d-link home
routers supported IA_NA as well.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Jul 2017 10:49:14 +0200

Le 20/07/2017 à 10:21, Lorenzo Colitti a écrit :
[...]
> properties

Do you mean DHCP-Address(IA_NA) does not have robust privacy properties?
   I think it does - it can deliver multiple addresses to Client, each
from a distinct /64 prefix.  That would be more privacy than SLAAC which
does vary the 64 IID but within same prefix.

Alex

---

From: Tore Anderson <[email-masked]>
Date: Thu, 20 Jul 2017 10:50:09 +0200

* Gert Doering <[email-masked]>

> That's an interesting statement.  Which products do it that way today,

LEDE/OpenWrt/HomeWrt at least.

From what I've heard the DHCPv6 stuff is there mostly to support
automatic host name discovery, but it also has the effect of
facilitating prefixes longer than /64. At least HomeWrt will do that if
there are too few /64s to number all the links in the Homenet. There
are Norwegian ISPs that hand out /62s and /60s to their subscribers, so
this can be a real concern.

That said, for me having the additional DHCPv6-assigned address in
addition to the SLAAC one has been a net negative, since it doesn't
reconfigure along with the link prefix following a PD change (but
nevertheless tends to be preferred for outbound traffic). Maybe this
would have been better if it was a ULA rather than a GUA though, I
don't know.

When it comes to the enterprise data centre networks I operate, on the
other hand, I do absolutely need DHCPv6 for network booting. However I
do not really need it once the system has booted, SLAAC serves my needs
fine then. So I'm actually considering setting up my DHCPv6 server so
that (by default) only the PXE client arch types will get addresses
assigned through DHCPv6.

Tore

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 20 Jul 2017 10:57:14 +0200

I can confirm that.

I’ve tested many CPE products/vendors with IPv6 support (in addition to OpenWRT and LEDE), and they have both enabled by default.

I’ve not collected a “list” of them, but probably the figures that I’ve on the top of my head (and guess most of us) is more than 12-15 different well-known vendors.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Lorenzo Colitti <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 20 de julio de 2017, 10:47
Para: Gert Doering <[email-masked]>
CC: james woodyatt <[email-masked]>, IPv6 Operations <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

    
    It depends on the vendor, of course. AIUI all of Comcast's home routers do DHCPv6 as well as SLAAC and DHCPv4. IIRC my off-the-shelf d-link home routers supported IA_NA as well.

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

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jul 2017 11:07:12 +0200

Alexandre, in order for that to be the case it must be true that the DHCP
server is actively working to arrange for it to be the case that clients
get addresses with good privacy characteristics.   What we are seeing in
the field is that addresses are being allocated out of very small ranges,
with no concern given to privacy.   So as a practical matter, the advice in
the RFC is the correct advice.

It's possible that we could change that, but I don't see the point.   It's
fine that DHCP servers work the way they do, as long as clients can also do
SLAAC.   DHCP simply does not address this use case, nor need it do so.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jul 2017 11:09:48 +0200

> would have been better if it was a ULA rather than a GUA though, I

That's an excellent point.

More in general I'd say that IA_NA is a net loss in *any* network where
addressing can unexpectedly change, such as a tethering hotspot, a small
enterprise, or even a medium enterprise using PA addresses. For exactly
this reason. (In fact - I don't think we even know how to make that sort of
thing at all without NAT.)

I'm sure many will just say that I'm biased, but think about it - if you
can't tell the hosts that something has changed, then how do you deal with
routing and renumbering changes? Even if hosts were to support DHCPv6
reconfigure, which they don't, how do you reconcile that with the assertion
that the value proposition is that DHCPv6 provides centralized management?
How do you do that at scale? Does the DHCPv6 server need to know about all
topology changes so it can issue appropriate RECONFIGUREs? What if the
topology change was such that the global address of the DHCPv6 server is no
longer valid due to renumbering? And so on.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Jul 2017 09:23:03 +0000

>> What if the topology change was such that the global address of the DHCPv6 server is no longer valid due to renumbering?

Address of DHCPv6 server does not matter - it can change. Clients generally never directly address packets to its address. They multicast to fe02::1:2.

Also, 3315bis recommends that clients refresh information via dhcp when a network change occurs (such as new prefixes in an RA appear).

- Bernie (from iPhone)

On Jul 20, 2017, at 11:10 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Jul 20, 2017 at 10:50 AM, Tore Anderson <[email-masked]<mailto:[email-masked]>> wrote:

More in general I'd say that IA_NA is a net loss in *any* network where addressing can unexpectedly change, such as a tethering hotspot, a small enterprise, or even a medium enterprise using PA addresses. For exactly this reason. (In fact - I don't think we even know how to make that sort of thing at all without NAT.)

I'm sure many will just say that I'm biased, but think about it - if you can't tell the hosts that something has changed, then how do you deal with routing and renumbering changes? Even if hosts were to support DHCPv6 reconfigure, which they don't, how do you reconcile that with the assertion that the value proposition is that DHCPv6 provides centralized management? How do you do that at scale? Does the DHCPv6 server need to know about all topology changes so it can issue appropriate RECONFIGUREs? What if the topology change was such that the global address of the DHCPv6 server is no longer valid due to renumbering? And so on.
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jul 2017 11:42:56 +0200

On Thu, Jul 20, 2017 at 11:23 AM, Bernie Volz (volz) <[email-masked]> wrote:

> >> What if the topology change was such that the global address of the
> DHCPv6 server is no longer valid due to renumbering?
>
> Address of DHCPv6 server does not matter - it can change. Clients
> generally never directly address packets to its address. They multicast to
> fe02::1:2.
>

Surely the RECONFIGURE is not multicast, but unicast from server to client?

> Also, 3315bis recommends that clients refresh information via dhcp when a
> network change occurs (such as new prefixes in an RA appear).
>

3315bis-09 does not recommend this, it says the client MAY do it and MUST
rate-limit it (with an example rate-limit of one every 30 seconds).

In any case, the server still needs to keep track of all topology changes
in order to give a correct answer.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 20 Jul 2017 19:47:28 +1000

On Thu, Jul 20, 2017 at 7:09 PM, Lorenzo Colitti <[email-masked]> wrote:
> enterprise, or even a medium enterprise using PA addresses. For exactly this
> reason. (In fact - I don't think we even know how to make that sort of thing
> at all without NAT.)

Exactly. The section 4 of
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-01
discusses in many details SLAAC vs DHCPv6 for various network topology
change scenarios.
It does not seem to be feasible to make DHCPv6-only work except for
very specific case of 'the router is acting as DHCPv6 server' and I'm
not sure it scales very well.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 20 Jul 2017 20:01:50 +1000

> network change occurs (such as new prefixes in an RA appear).

Sorry if I missed smth in that 100+ pages draft hut the only thing I found says:
'
The server MAY initiate a configuration exchange, by sending
   Reconfigure messages, to cause DHCP clients to obtain new addresses,
   prefixes and other configuration information.  For example, an
   administrator may use a server-initiated configuration exchange when
   links in the DHCP domain are to be renumbered or when other
   configuration options are updated, perhaps because servers are moved,
   added, or removed.
'

I'd rather avoid repeating the whole Section 4 of
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-01
but:
1) it's quite possible that in the event of some network failure the
client unicast address might be unreachable;
2) the delay caused by 'network change -> DHCPv6 server gets notified
(by what mechanism, btw?) -> the whole reconfiguration process happens
to ALL affected clients' seems to increase the recovery time.

> On Jul 20, 2017, at 11:10 AM, Lorenzo Colitti <[email-masked]> wrote:
>

---

From: Jen Linkova <[email-masked]>
Date: Thu, 20 Jul 2017 20:02:14 +1000

2)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Jul 2017 10:05:52 +0000

There are two ways to deliver Reconfigure: one is unicast, other is via Relay-Reply through relays were link-local is used to reach client.

- Bernie (from iPhone)

On Jul 20, 2017, at 11:43 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

3315bis-09 does not recommend this, it says the client MAY do it and MUST rate-limit it (with an example rate-limit of one every 30 seconds).

In any case, the server still needs to keep track of all topology changes in order to give a correct answer.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 20 Jul 2017 09:19:02 +0000

> effectively *is*, and no amount of word-weaseling is going to change this.

I've spoken to various ISPs who want to deploy their IPTV STBs or home automation devices, in conjunction with their CE routers, in such a way that the STBs and home automation devices do both SLAAC and DHCPv6. The STBs/etc devices automatically request IA_NA without caring about values of bits in an RA (because M=0 may be used in RAs to prevent other devices from asking). The DHCPv6 server in the ISP CE router recognizes the ISP's host devices and provides them (and only them) with DHCPv6 IA_NA addresses. Those addresses are used specifically to access the ISP service. For communicating with other devices on the LAN or other Internet services, SLAAC addresses are used.

I think this is a perfectly valid use case. There is no reason to preclude it. I don't see privacy implications. The ISP services don't tend to be delivered over "the Internet". The devices don't roam.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jul 2017 13:28:23 +0200

And, at the moment, it is not precluded, right?

On Jul 20, 2017 1:25 PM, "STARK, BARBARA H" <[email-masked]> wrote:

> I've spoken to various ISPs who want to deploy their IPTV STBs or home
> automation devices, in conjunction with their CE routers, in such a way
> that the STBs and home automation devices do both SLAAC and DHCPv6. The
> STBs/etc devices automatically request IA_NA without caring about values of
> bits in an RA (because M=0 may be used in RAs to prevent other devices from
> asking). The DHCPv6 server in the ISP CE router recognizes the ISP's host
> devices and provides them (and only them) with DHCPv6 IA_NA addresses.
> Those addresses are used specifically to access the ISP service. For
> communicating with other devices on the LAN or other Internet services,
> SLAAC addresses are used.
>
> I think this is a perfectly valid use case. There is no reason to preclude
> it. I don't see privacy implications. The ISP services don't tend to be
> delivered over "the Internet". The devices don't roam.
> Barbara
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jul 2017 13:31:22 +0200

Running both IA_NA and SLAAC is certainly not precluded by RFC 7934. In the
specific case of home routers, RFC 7084 says they MUST have a DHCPv6
server, either stateful or stateless.

On Thu, Jul 20, 2017 at 1:28 PM, Ted Lemon <[email-masked]> wrote:

>> I think this is a perfectly valid use case. There is no reason to
>> preclude it. I don't see privacy implications. The ISP services don't tend
>> to be delivered over "the Internet". The devices don't roam.
>> Barbara
>>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 20 Jul 2017 12:22:15 +0000

> specific case of home routers, RFC 7084 says they MUST have a DHCPv6 server, 
> either stateful or stateless.

I agree completely that RFC 7934 does not preclude IA_NA + SLAAC. I was merely objecting to the strongly worded statement from Gert that there was no reason to do so. There is.
I'm not sure of the relevance of the RFC 7084 requirement here. That just means that support of IA_NA is optional in CE routers.
Barbara

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Jul 2017 15:42:41 +0000

> On 20 Jul 2017, at 10:07, Ted Lemon <[email-masked]> wrote:
> 
> Alexandre, in order for that to be the case it must be true that the DHCP server is actively working to arrange for it to be the case that clients get addresses with good privacy characteristics.   What we are seeing in the field is that addresses are being allocated out of very small ranges, with no concern given to privacy.   So as a practical matter, the advice in the RFC is the correct advice.
> 
> It's possible that we could change that, but I don't see the point.   It's fine that DHCP servers work the way they do, as long as clients can also do SLAAC.   DHCP simply does not address this use case, nor need it do so.

Well, there is published advice against that DHCPv6 address pool behaviour.

Ultimately it’s the deployment scenario that matters, I think.  For an enterprise environment where all devices are under administrative control, it seems DHCPv6 is more likely to be preferred, and where SLAAC is used, privacy address generation would likely be disabled. You may even see preference for classic SLAAC rather than RFC7217, if OSes still support that mode.

For home networks, hotspots, campus WiFi, etc, I’d expect SLAAC to be available.  Personally, my expectations of privacy would differ between my workplace and networks I use when not at work.

Tim

> On Thu, Jul 20, 2017 at 10:49 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> SLAAC addresses provide ample address space and have robust privacy properties
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Jul 2017 16:53:35 +0100

Tim Chown wrote:
> For home networks, hotspots, campus WiFi, etc, I’d expect SLAAC to be available.

home networks probably yes.

<ymmv>
hotspots and campus wifi are a different kettle of fish though, due to
policy and/or legal requirements to put steps in place for end-to-end
traceability (regardless of how easy it might be to work around these
things).

Note that in cases like hotspots and campus wifi, you would be well
advised not to have any expectations of privacy to start with, so in the
general case, it would be questionable as to whether these networks
would be bcp204 compliant to start with.  This isn't a blanket statement
or a position of intent, btw - just an observation that if you use
someone else's network resources, you are subject to their policies.
</ymmv>

Nick

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Jul 2017 16:22:01 +0000

> On 20 Jul 2017, at 16:53, Nick Hilliard <[email-masked]> wrote:
> 
> Tim Chown wrote:

For campus network wifi, you get accountability through eduroam.

Many hotspots have zero authentication.

> someone else's network resources, you are subject to their policies.

Yeah things like GDPR would come into play. But let’s not go down this rathole; the point is that different scenarios will have different expectations and requirements.  And I’d argue administratively managed enterprises are the the most likely to put a requirement on DHCPv6, or to run SLAAC with 4941 disabled.

Tim

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Jul 2017 17:45:05 +0100

> For campus network wifi, you get accountability through eduroam.

s/campus network/eduroam campus network/

There are lots of different types of campus, and campus type networks.

> Many hotspots have zero authentication.

Sadly, there is an increasing number of situations which refuse hotspot
connectivity without authentication, depending on a variety of situations.

>> Note that in cases like hotspots and campus wifi, you would be
>> well advised not to have any expectations of privacy to start with,
>> so in the general case, it would be questionable as to whether
>> these networks would be bcp204 compliant to start with.  This isn't
>> a blanket statement or a position of intent, btw - just an
>> observation that if you use someone else's network resources, you
>> are subject to their policies. </ymmv>
> 
> Yeah things like GDPR would come into play. But let’s not go down
> this rathole; the point is that different scenarios will have
> different expectations and requirements.

indeed, and the ietf needs to acknowledge this explicitly.

Nick

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Jul 2017 16:52:14 +0000

> On 20 Jul 2017, at 17:45, Nick Hilliard <[email-masked]> wrote:
> 
> Tim Chown wrote:

Well, the discussion was around best practice discussion, and in that light eduroam should be aspirational. It’s deployed in 70-80 countries, but the underlying 802.1x can be used in any campus, and on wired links as well.

> indeed, and the ietf needs to acknowledge this explicitly.

Feel free to suggest text for Node Requirements -bis...

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jul 2017 19:07:50 +0200

On Thu, Jul 20, 2017 at 6:52 PM, Tim Chown <[email-masked]> wrote:

> Well, the discussion was around best practice discussion, and in that
> light eduroam should be aspirational. It’s deployed in 70-80 countries, but
> the underlying 802.1x can be used in any campus, and on wired links as well.
>

Which is, of course, technically a much better solution than relying on
insecure DHCPv6.

Additionally, there's the option of doing /64 per host (via RAs) in the
enterprise. Same tracking and authorization properties, but no limitation
on the number of addresses that can be used.

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Jul 2017 17:21:37 +0000

> On 20 Jul 2017, at 18:07, Lorenzo Colitti <[email-masked]> wrote:
> 
> Which is, of course, technically a much better solution than relying on insecure DHCPv6.
> 
> Additionally, there's the option of doing /64 per host (via RAs) in the enterprise. Same tracking and authorization properties, but no limitation on the number of addresses that can be used.

Yep, and I mention that when speaking to university admins, ad they like and understand the idea.  Though I have a feeling they may soon realise they’ll want more than a /48 to serve their campuses… and that’s an issue for campuses that want to follow 7934 and JJB’s draft.  We have three UK universities that have now gone for LIR status to obtain their own /32.

As an aside, we almost went with /64 per office in our initial campus rollout; the issue then was the extra cost of the routing image on $vendor’s hardware.

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Jul 2017 19:25:12 +0200

Tim, when you say /64 per office for your initial campus rollout, did you
mean /64 per host?

On Thu, Jul 20, 2017 at 7:21 PM, Tim Chown <[email-masked]> wrote:

> Yep, and I mention that when speaking to university admins, ad they like
> and understand the idea.  Though I have a feeling they may soon realise
> they’ll want more than a /48 to serve their campuses… and that’s an issue
> for campuses that want to follow 7934 and JJB’s draft.  We have three UK
> universities that have now gone for LIR status to obtain their own /32.
>
> As an aside, we almost went with /64 per office in our initial campus
> rollout; the issue then was the extra cost of the routing image on
> $vendor’s hardware.
>
> Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Jul 2017 17:53:44 +0000

> On 20 Jul 2017, at 18:25, Lorenzo Colitti <[email-masked]> wrote:
> 
> Tim, when you say /64 per office for your initial campus rollout, did you mean /64 per host?

No, this was back in around 2003/4-ish during a project called 6NET, when we had edge devices that would have been capable of being configured to route a /64 per office, and had good v6 support. There were various reasons discussed around isolation, accountability, etc.  Much of the same rationale of the prefix-per-host draft.  

And that was still early wireless days, and certainly pre-802.1x being anywhere near mainstream (we started work on eduroam a year or two before, but there were only very early open source supplicants and some not-cheap 3rd party ones.  So different now :).

Tim

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 31 Jul 2017 16:12:58 +0100

Lorenzo Colitti wrote:
> I think a lot of the disagreement on interpretation is due to the fact
> that some in the discussion (including myself) have inappropriately
> general*.

this was the source of the confusion which host-addr-update attempted to
clarify.  As it appears to have been a mistake to start with, the best
thing would be to let draft-hilliard-v6ops-host-addr-update expire.

> It doesn't  - it recommends against *requiring* the use of
> IA_NA / IA_TA in order to use IPv6 on a particular network. I think the
> confusion is limited to this thread though; then RFC itself is pretty clear.

This is a different issue, and it looks like a lot of people on the
v6ops-wg have different interpretations on whether it means this in the
first place.

That said, operators will do what they are going to do and will happily
ignore advice from the IETF if they decide it suits their requirements
better to do that.

Nick