Subject: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work?

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 1 Apr 2015 17:30:50 +0000

Hi:

To the WG and co-authors of this document, as a follow up from the Dallas (IETF-92) DHC WG meeting, there is the question as to next step(s) for draft-ietf-dhc-stable-privacy-addresses.

In thinking about this some, my feeling is:

-          Drop the work. There is little reason for defining this for DHCPv6 servers as there are no "interoperability" issues.

o   If there are multiple servers operating on a link and they aren't coordinating activities in some way (i.e. perhaps DHCPv6 failover or some common database), they will likely not be able to lease from the same pool of addresses anyway.

o   Sure, if you change the server to a different server implementation, it may have different a algorithm, but does this really matter (and it is fairly rare in the first place)?

o   And, there are also issues with the "range of addresses" model if the range is expanded or reduced, since this causes a change to the "stable" addresses.

o   So, do we really need this?

-          If people do feel that the work should continue (and eventually advance), the document should not be a "Standards Track" but "Informational".

So, I will propose that the DHC WG "drop this work" (mark the ID as dead). Objections? Comments?

-          Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Apr 2015 13:55:33 -0400

On Apr 1, 2015, at 1:30 PM, Bernie Volz (volz) <[email-masked]> wrote:
> So, I will propose that the DHC WG “drop this work” (mark the ID as dead). Objections? Comments?

I think that it is worth doing if use of IA_NA is going to be widespread, because otherwise we're going to have implementors who simply don't think to take user privacy into account.

This actually reminds me of another issue that came up in conversation in Dallas: what should the applicability be for IA_NA address assignment anyway?   It's fairly clear to me that it's more constrained than the applicability for IPv4 address allocation, and it might be worth giving some guidance in 3315bis.

As a starting point, I think we can pretty definitively say that IA_NA is _never_ appropriate in a home gateway DHCP server.  It's probably not appropriate in hotspot settings either.   It probably does make sense in an enterprise setting, and possibly for infrastructure devices.

Thotz?   It's possible that the set of places where IA_NA is applicable is sufficiently constrained that we don't _need_ DHCP servers to support stable privacy addresses.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 1 Apr 2015 19:07:10 +0000

My Thotz:

I'm not sure what document is the target of this IA_NA usage model (the stable-privacy-addresses? Or the anonymity profiles? Or DHCPv6bis? I would prefer not to get into that in DHCPv6bis).

Why are stable privacy addresses useful when using DHCPv6? First, DHCPv6 addresses are probably random and there are usually ways to configure servers to 'retain' a binding for a period of time beyond the "normal" end of the lease (at least our server has two techniques - grace periods and affinity periods). Yes, these have a larger cost than calculating them on the fly, but they are also more likely to be stable for the intended period (no issues of collisions). Some servers may also remember the 'last' client to use an address that has expired and give the client back that same address (many DHCPv4 servers do this). And, then most servers also allow you to reserve addresses for a specific client (which is a stable address when you're connected to the same place).

And for when you write "I think that it is worth doing if use of IA_NA is going to be widespread, because otherwise we're going to have implementors who simply don't think to take user privacy into account.", how are "stable privacy addresses" more private than randomly assigned addresses?

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Apr 2015 15:18:51 -0400

> I'm not sure what document is the target of this IA_NA usage model (the stable-privacy-addresses? Or the anonymity profiles? Or DHCPv6bis? I would prefer not to get into that in DHCPv6bis).

It pretty much has to be DHCPv6bis, since that's where the protocol is defined, and you want the applicability statement to be with the protocol.

> Why are stable privacy addresses useful when using DHCPv6? First, DHCPv6 addresses are probably random and there are usually ways to configure servers to 'retain' a binding for a period of time beyond the "normal" end of the lease (at least our server has two techniques - grace periods and affinity periods).

If it's not specified that they are random, they can't be assumed to be random.   E.g., what if the DHCP server just uses your EUI64?

> And for when you write "I think that it is worth doing if use of IA_NA is going to be widespread, because otherwise we're going to have implementors who simply don't think to take user privacy into…

Depends what it says in the spec.   If the spec doesn't say how the address is generated, then we can't assume that the way it's generated will result in privacy for the host.   So depending on the applicability of IA_NA, this could be an issue worth being specific about.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 1 Apr 2015 19:52:30 +0000

By default, our server assignment is random which does NOT make use of any client information (but yes, there is a way you can make use of EUI-64 if you like).

Yes, having a privacy considerations about address assignment is certainly within DHCPv6bis work - we likely should think about what to add there (references to privacy documents and perhaps server considerations). But, I think saying what devices should or should not use IA_NA is not within its bounds as that may change over time.

But this all is different than having a "stable-privacy-addresses" document. The discussion is good and we need to factor this into the privacy work and also into DHCPv6bis. I suspect the privacy documents will be out well before DHCPv6bis, so referencing those might be sufficient and adding a section on Server Privacy Considerations to those privacy documents is a good idea - such as to mention that address assignment (and prefix delegation?) should NOT make use of client specific information to generate the address -- at least in such a way where it is not hashed (which is what privacy-stable-addresses does).

So, we're back to the question as to whether draft-ietf-dhc-stable-privacy-addresses document is needed (and if it is, whether it is Informational). If you really like the algorithm and want to suggest to server implementers here is one you can use, that's fine but it should be Informational then. I don't see this as required to implement.

- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 1 Apr 2015 20:29:18 +0000

BTW: Section 4.3 of draft-ietf-dhc-dhcpv6-privacy already covers "allocation strategies" -- see https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-00#section-4.3. So, "it is already in there".

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 01, 2015 3:53 PM
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, April 01, 2015 3:19 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 1 Apr 2015 20:46:42 +0000

> As a starting point, I think we can pretty definitively say that IA_NA is
> _never_ appropriate in a home gateway DHCP server

I'm aware of a number of ISPs who are considering having IA_NA supplied by an ISP-provided CE router's DHCPv6 server to the ISP's IPTV set-top boxes inside the home network. Many ISPs also consider IA_NA appropriate for addressing of other ISP-supplied devices (e.g., femto access point, home automation/monitoring devices, etc.) behind ISP-supplied CE routers. These are ISP-managed devices. Often the home network segments they are attached to are also ISP-managed. Often, the only points on the Internet that these devices communicate with are the ISP servers. I'm unconvinced as to the value of "privacy" addresses in this case.
Barbara

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Apr 2015 08:28:45 +0900

On Thu, Apr 2, 2015 at 4:52 AM, Bernie Volz (volz) <[email-masked]> wrote:

> So, we're back to the question as to whether
> draft-ietf-dhc-stable-privacy-addresses document is needed (and if it is,
> whether it is Informational). If you really like the algorithm and want to
> suggest to server implementers here is one you can use, that's fine but it
> should be Informational then. I don't see this as required to implement.
>

+1. draft-ietf-dhc-stable-privacy-addresses does not really provide much
value on top of assigning addresses randomly. Address assignment via IA_NA
is fundamentally stateful, so I don't see a lot of gain in making it
"deterministic unpredictable" as opposed to "random unpredictable".

If what we want is provide guidance to implementors to use unpredictable
addresses, then we should do that without specifying a particular algorithm.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Apr 2015 08:36:45 +0900

On Thu, Apr 2, 2015 at 4:52 AM, Bernie Volz (volz) <[email-masked]> wrote:

> But, I think saying what devices should or should not use IA_NA is not
> within its bounds as that may change over time.
>

But we can certainly say what types of scenarios are appropriate for use of
address assignment via IA_NA. For example, any scenario that requires
changing client IPv6 prefixes dynamically and does not use server failover
cannot be reliably implemented using IA_NA. Even if the client supports
reconfigure, a server crash makes it impossible to change the client's IP
address, even if there is another server.

This limitation is not obvious to someone used to DHCPv4, because in IPv4
clients typically never need to change addresses because the network uses
NAT.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Apr 2015 19:52:57 -0400

> BTW: Section 4.3 of draft-ietf-dhc-dhcpv6-privacy already covers "allocation strategies" -- see https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-00#section-4.3. So, "it is already in there…

That's not normative.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Apr 2015 19:55:33 -0400

> I'm aware of a number of ISPs who are considering having IA_NA supplied by an ISP-provided CE router's DHCPv6 server to the ISP's IPTV set-top boxes inside the home network. Many ISPs also consider…

That's infrastructure.   I agree that this is a valid use case.   What I mean when I propose that HGs shouldn't do IA_NA is that they shouldn't assign IP addresses on customer networks to customer devices using IA_NA.   It would be actively bad if a CE of the sort you are describing started requiring devices on the home network to do DHCPv6 in order to connect to the Internet.   So it's good that we had this talk!   :)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 2 Apr 2015 02:20:00 +0000

I don't see this as required to be normative. It creates no interop issues. The market can decide what they want server (& client) implementers to provide.

- Bernie (from iPhone)

> On Apr 1, 2015, at 7:53 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Apr 2015 22:22:29 -0400

> I don't see this as required to be normative. It creates no interop issues. The market can decide what they want server (& client) implementers to provide.

BCPs are normative.   I don't think "let the market decide" is really an appropriate answer here.   I think your privacy considerations approach in 3315bis is fine.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 04 Apr 2015 00:31:22 +0200

Hi, Bernie,

I'm kind of surprised about the question :-), since my mental model of
this I-D as that it should be WGLC'ed rather than  abandoned.

Regarding your thoughts, please find my comments in-line...

On 04/01/2015 07:30 PM, Bernie Volz (volz) wrote:
> 
> To the WG and co-authors of this document, as a follow up from the
> Dallas (IETF-92) DHC WG meeting, there is the question as to next
> step(s) for draft-ietf-dhc-stable-privacy-addresses.
> 
> -          Drop the work. There is little reason for defining this for
> DHCPv6 servers as there are no “interoperability” issues.

If you look at the RFC series, there are plenty of documents that
specify policies that do not necessarily result in interoperability
issues: e.g., RFC4086, RFC1948, RFC6056. RFC7217.

In many cases, there are underlying requirements to prevent
interoperability issues. And some of the possible choices have other
implications (e.g., security-related). Hence having guidance or
providing good implementation approaches is more than valuable.

> o   If there are multiple servers operating on a link and they aren’t
> coordinating activities in some way (i.e. perhaps DHCPv6 failover or
> some common database), they will likely not be able to lease from the
> same pool of addresses anyway.

Actually, an approach such as that pecified by this document is
mentioned in RFC7031 itself. e.g.:

"  Also, the typical large address space (close to 2^64 addresses on /64
   prefixes expected to be available on most networks) may make managing
   address assignment significantly different from DHCPv4 failover.  In
   DHCPv4, it was not possible to use a hash or calculated technique to
   divide the significantly more limited address space, and therefore,
   much of the protocol that deals with pool balancing and rebalancing
   might not be necessary and can be done mathematically."

So this is indeed and algorithmic approach for coordinating the databases.

> o   Sure, if you change the server to a different server implementation,
> it may have different a algorithm, but does this really matter (and it
> is fairly rare in the first place)?

If stability is an issue, yes.

> o   And, there are also issues with the “range of addresses” model if
> the range is expanded or reduced, since this causes a change to the
> “stable” addresses.

This was already fixed (in the version that I didn't post because of the
I-D cutoff). We even discussed how to solve this issue on-list.

> -          If people do feel that the work should continue (and
> eventually advance), the document should not be a “Standards Track” but
> “Informational”.

Wasn't this an implicit question in the wg call for adoption?

> dead). Objections? Comments?

Me, I object to that. :-). My comments and rationale can be found above.

Thanks!

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 4 Apr 2015 00:40:42 +0000

These are questions / issues for the WG to reach consensus on. So let's see what others have to say & if people actually have use cases where they would want to make use of this (or close to it) algorithm.

I would recommend you publish a pending update if you have it.

- Bernie (from iPad)

> On Apr 3, 2015, at 6:33 PM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Bernie,
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 4 Apr 2015 11:38:55 +0900

> So, I will propose that the DHC WG “drop this work” (mark the ID as dead).

Seems reasonable to me. We should definitely address the question of
privacy, but that should be done without dictating implementation.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 05 Apr 2015 16:24:09 +0200

On 04/04/2015 04:38 AM, Lorenzo Colitti wrote:
> On Thu, Apr 2, 2015 at 2:30 AM, Bernie Volz (volz) <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

We're not dictating implementation. Why do you think so?

We're specifying one way to do it. But no one is mandating that you
should do it this way. For instance, this document does not update any
existing RFC.

(and the next revision of default-iids will be clear in this respect).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 05 Apr 2015 16:29:08 +0200

On 04/01/2015 09:18 PM, Ted Lemon wrote:
>> Why are stable privacy addresses useful when using DHCPv6? First,
>> DHCPv6 addresses are probably random and there are usually ways to
>> configure servers to 'retain' a binding for a period of time beyond
>> the "normal" end of the lease (at least our server has two
>> techniques - grace periods and affinity periods).
> 
> If it's not specified that they are random, they can't be assumed to
> be random.   E.g., what if the DHCP server just uses your EUI64?

Exactly (and we all know what they say about "assumptions"). The next
rev of 6man's default-iids I-D wil have words in this respect.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 05 Apr 2015 16:34:42 +0200

On 04/01/2015 09:52 PM, Bernie Volz (volz) wrote:
> draft-ietf-dhc-stable-privacy-addresses document is needed (and if it
> is, whether it is Informational). If you really like the algorithm
> and want to suggest to server implementers here is one you can use,
> that's fine but it should be Informational then. I don't see this as
> required to implement.

I think there's some misunderstanding wrt what a Std Track RFC means.
The fact that an RFC is published in Standards Track does not mean (by
itself), that you have to implement it (for instance, that's why we have
e.g. RFC1122, RFC1812, and IPv6's Node Requirements RFC).

Rather, it means "If you're going to implement this, this is how you
should do it. A DHCPv6-server vendor is 100% free to *not* implement
this document. But if they want the feature, the document says how to
implement it.

The reason for which the document is Std Track is because there are
requirements for the mechanism to work as expected. If you use e.g.
different algorithms in different servers (on the same subnet), the
mechanism will not work as expected. That's it.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 05 Apr 2015 16:38:44 +0200

> I don't see this as required to be normative. It creates no interop issues. The market can decide what they want server (& client) implementers to provide.

Exactly: No one forces you or mandates that you implement this document.
That's why it doesn't update the core DHCPv6 RFC.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 05 Apr 2015 16:56:14 +0200

On 04/02/2015 01:28 AM, Lorenzo Colitti wrote:
> On Thu, Apr 2, 2015 at 4:52 AM, Bernie Volz (volz) <[email-masked]
>     draft-ietf-dhc-stable-privacy-addresses document is needed (and if
>     it is, whether it is Informational). If you really like the
>     algorithm and want to suggest to server implementers here is one you
>     can use, that's fine but it should be Informational then. I don't
>     see this as required to implement.
> 
> value on top of assigning addresses randomly. Address assignment via
> IA_NA is fundamentally stateful, so I don't see a lot of gain in making
> it "deterministic unpredictable" as opposed to "random unpredictable".

You get stability of the address, even in scenarios in which you have
multiple DHCPv6 servers, without the need of an additional protocol for
synchronizing the address leases database. An approach such as that
specified by this document is mentioned in RFC7031 itself. e.g.:

If you think the extra value is worth its implementation, you implement
it. If you don't, you don't.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 5 Apr 2015 15:27:01 +0000

No, I do not misunderstand. What I meant was that a standards track document has much more "weight" than an informational document. And, as there are other ways with DHCP to provide for stability and "random" addresses, this is just one technique.

You and I can debate the merits of this document back and forth all we want, but that won't help us reach consensus. We really need to hear from others. Silence is difficult to read as it may mean almost anything.

We may have to wait until Prague to get at least an "in-room" consensus as we can then ask what people want to do (with confirmation of the result on the list). We can ask:
1. Do you want to move the document forward as Standards Track?
2. Do you want to move the document forward as Informational?
3. Do you want to not move this document forward?

- Bernie

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Sunday, April 05, 2015 10:35 AM
To: Bernie Volz (volz); Ted Lemon
Cc: [email-masked]
Subject: Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

On 04/01/2015 09:52 PM, Bernie Volz (volz) wrote:
> is, whether it is Informational). If you really like the algorithm and 
> want to suggest to server implementers here is one you can use, that's 
> fine but it should be Informational then. I don't see this as required 
> to implement.

I think there's some misunderstanding wrt what a Std Track RFC means.
The fact that an RFC is published in Standards Track does not mean (by itself), that you have to implement it (for instance, that's why we have e.g. RFC1122, RFC1812, and IPv6's Node Requirements RFC).

Rather, it means "If you're going to implement this, this is how you should do it. A DHCPv6-server vendor is 100% free to *not* implement this document. But if they want the feature, the document says how to implement it.

The reason for which the document is Std Track is because there are requirements for the mechanism to work as expected. If you use e.g.
different algorithms in different servers (on the same subnet), the mechanism will not work as expected. That's it.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 6 Apr 2015 09:40:08 +0900

> this document. But if they want the feature, the document says how to

I don't think it's a good idea for the IETF to make a statement that "if
you want to provide stable addresses using DHCP, this is the way you have
to do it". There are other ways to implement stable addressing than the
algorithm proposed in this draft.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 6 Apr 2015 11:46:51 -0700

At Wed, 1 Apr 2015 17:30:50 +0000,

> step(s) for draft-ietf-dhc-stable-privacy-addresses.

[...]

> dead). Objections? Comments?

I have no objection to abandoning it.  But I wouldn't be opposed to
publishing it either.  In that case Informational seems to be a good
choice.  My reasons follow:

As far as I understand it, the main value of this approach is:

1. allow DHCPv6-assigned addresses to be (much) less predicable, AND
2. make sure the same address is assigned to the same host in the same
   particular link over multiple DHCPv6 sessions

I guess we generally agree on the need for #1, especially for some
kind of deployment.  I also think value #2 would be considered very
useful, even if not critical - it will be convenient if I can get the
same address on my laptop or smart phone or tablet when I get back to
home.

So the question is whether this specific approach to achieve these
goals is worth an RFC.

As you pointed out, (unlike SLAAC) it would be much easier to do this
in the case of DHCPv6 *in practice*: just assign addresses randomly
for the first time but remember and reuse the binding beyond a single
DHCPv6 session as much/long as possible.  This approach is less
reliable than dhc-stable-privacy-addresses since the server could
discard the binding for some reason (storage/memory requirement, etc),
but it's probably good enough in practice (it at least provides the
same level of stability as that we have today for DHCPv4).  It will
also not work if the server is replaced with a new one, but again you
pointed out, such events would be rare enough in practice.  It may
also be difficult to achieve these goals with failover cases, but,
once again, failover itself is probably a less frequent event
(otherwise the network has a more serious issue than address
stability), and the operational cost with dhc-stable-privacy-addresses
to make this case work also seems to be non-negligible.

So, I tend to agree that the advantage of this particular proposal is
not so strong.  In that sense I have no objection to abandoning the
work.

Whether we still want to publish it would depend on whether we want to
show a solution that provides the value #1 and #2 above and that 100%
works without relying on server state or replacement.  Personally, I
don't see a strong need for that (practically good solution seems to
be enough), but if some other people want to have it, I wouldn't be
opposed to that desire.

In that case, I think it's better to publish it as an RFC (rather than
a personal blog or white paper or something like that) since one major
benefit of this approach is that it works even when we replace the
server, and to make it work different server implementations will have
to use the same algorithm.  And, in this case, I don't have a strong
opinion on which standard level is the best simply because I'm not a
standard-level police, but Informational seems to be good enough.
This approach does not affect protocol interoperability in its strict
sense, and unlike the SLAAC counterpart (RFC7217, to which the same
argument applies) we have a reasonable alternative for the expected
goal.  So the standard truck is probably too much for it.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Apr 2015 03:54:19 -0300

Lorenzo,

On 04/05/2015 09:40 PM, Lorenzo Colitti wrote:
> On Sun, Apr 5, 2015 at 11:34 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> you want to provide stable addresses using DHCP, this is the way you
> have to do it". There are other ways to implement stable addressing than
> the algorithm proposed in this draft.

This is not what this document is about.

This document specifies *one* possible algorithm for producing stable
privacy-enhanced addresses. Nowhere does it say that it is the only way
to do it, and nowhere does it mandate that you support stable
privacy-enhanced addresses in the first place (or that, if you do, you
do it with this algorithm).

A vendor can assess himself whether this is an interesting feature, and
a user can enable this feature (if this algorithm is supported) if he
thinks its of value.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Apr 2015 19:29:33 +0900

On Wed, Apr 8, 2015 at 3:54 PM, Fernando Gont <[email-masked]> wrote:

> Nowhere does it say that it is the only way

Actually it does. For example:

   DHCPv6 server implementations conforming to this specification MUST
   generate non-temporary IPv6 addresses using the algorithm specified
   in this section.

and:

   A DHCPv6 server implementing this specification must select the IPv6
   addresses to be leased with the following algorithm:

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Apr 2015 07:55:13 -0300

On 04/08/2015 07:29 AM, Lorenzo Colitti wrote:
> On Wed, Apr 8, 2015 at 3:54 PM, Fernando Gont <[email-masked]

Huh?

The text says "...*conforming to this specification*" and
"..*implementing* this specification". That means: "if you want to
implement this scheme, this is what you must do".

Nowhere does it say "DHCPv6 implementations must generate IPv6 addresses
as specified in this document". And the new "Applicability..." section
hopefully makes that even more explicit.

Is there anything I'm missing?

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Apr 2015 19:58:15 +0900

> Is there anything I'm missing?

Yes. You're missing that a DHCP server that implements your specification
must be able to choose a different method to "generate non-temporary IPv6
addresses".

Your document doesn't allow that, because the text says "DHCPv6 server
implementations conforming to this specification MUST generate
non-temporary IPv6 addresses using the algorithm specified in this section."

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Apr 2015 08:16:02 -0300

On 04/08/2015 07:58 AM, Lorenzo Colitti wrote:
> Yes. You're missing that a DHCP server that implements your
> specification must be able to choose a different method to "generate
> non-temporary IPv6 addresses".
> 

This is certainly a wording issue, that I guess is fixed by, e.g.,
s/conforming/employing/?

(For instance, there's text that suggests that if you implement this
method, you provide a knob such that you can control whether to use this
method or not:

"   Implementations conforming to this specification SHOULD provide the
   means for a system administrator to enable or disable the use of this
   algorithm for generating IPv6 addresses."

)

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Apr 2015 20:35:42 +0900

>    algorithm for generating IPv6 addresses."

That just changes the question to "what happens if the server uses both
this type of address and other types of address".

More in general: if you're serious about this document being "just one
possible way of generating IPv6 IIDs", then you'll need to make it clear
what is required for it to coexist with other ways of generating IPv6 IIDs.
If not, then you'll need to make it clear that it cannot coexist with other
ways of generating addresses.

Another issue I see is that the document says that the addresses are stable
and stateless, but they're not, because the value of counter for every
lease needs to be shared between the servers. For example, if the client
sends a DECLINE because it fails DAD, what do you do? The address is no
longer stable.

Another issue: if the addresses are stable and stateless, then that means
you can replace a server and have the client keep the same address. What
modifications are needed on the server side for that to work? If the client
sends a renew unicast to the new server, will this just work?

Again, I think this is best left unspecified and I don't see the value in
publishing this document. But I think that if you want to publish it,
you'll need to provide serious answers to the questions above.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Apr 2015 09:28:42 -0300

Hi, Lorenzo,

On 04/08/2015 08:35 AM, Lorenzo Colitti wrote:
> On Wed, Apr 8, 2015 at 8:16 PM, Fernando Gont <[email-masked]

The intent is that if you're going to use this scheme, for leasing
addreses, you use this scheme for all prefixes: at the end of the day,
if *one* of your addresses is predictable, that's enough for the
attacker to track you or scan you.

> possible way of generating IPv6 IIDs", 

I certainly am: I would have included an "Updates RFC3315" in the I-D,
otherwise.

> then you'll need to make it clear
> what is required for it to coexist with other ways of generating IPv6
> IIDs. If not, then you'll need to make it clear that it cannot coexist
> with other ways of generating addresses.

Other ways of generating IIDs for the same prefix, or for other prefixes?

For other prefixes, the idea is that if you use a weak scheme for other
prefixes, you're toast. For the same prefix, if you employ multple
schemes you won't achieve address stability.

Is this what you were referring to?

> Another issue I see is that the document says that the addresses are
> stable and stateless, but they're not, because the value of counter for
> every lease needs to be shared between the servers. For example, if the
> client sends a DECLINE because it fails DAD, what do you do? The address
> is no longer stable.

IMO, I see the counter as mostly an "optional" parameter, which allows
to recover from address collisions (rather than a mandatory field). If
you do employ the Counter, but do not store it, then whether the
addresses are stable or not depends on the order in which systems are
bootstrapped.

> Another issue: if the addresses are stable and stateless, then that
> means you can replace a server and have the client keep the same
> address. What modifications are needed on the server side for that to
> work? If the client sends a renew unicast to the new server, will this
> just work?

This deserves a clarification, indeed.

Of th top of my head:

* Address stability can be achieved 100% stateless-ly, but need not.
e.g., you can generate addresses as specified in this document, but
still keep an address lease database. In that case, the server would
employ this algorithm for generating the addresses in the first place,
but the address lease would be recorded in the lease database. After
that, things would work as for any other DHCPv6 address generation
scheme. If the server is replaced (same IP address, same server DUID),
renew/rebind itself would "fail" but then but then the same address
would be leased again (when the algorithm is applied ot generate a "new"
IPv6 address). For failover to a different server this doesn't really
matter, as a renew is sent to the same server, nt just ot "any server".

For a 100% stateless operation, then the server should check whether the
address t be renewed is the result of applying the expression in the
I-D. If it is, that'd be the same as having an entry in the lease
database. Otherwise, it's a "no binding" scenario. For the case where
one wants to cope with possible address clollisions, one might (MAY) the
server to try to expression (incrementing Counter) up to "MaxRetries"
(which should be the same value that the server should use when trying
to come up with a unique address but collissions are found).

Does (some version of) this sound reasonable?

Thanks!

Best regards,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Apr 2015 21:45:40 +0900

> attacker to track you or scan you.

No, it's not enough. The attacker can only track or scan you if you use a
stupid algorithm to generate the IIDs. Yours is not stupid, but neither are
many others such as "random". You can perfectly well use random assignment
on some subnets and your algorithm on other subnets.

Regardless - if that's the intent, then the draft should say so.

> Is this what you were referring to?

I was referring to the lack of any such statement in the draft, yes.

> addresses are stable or not depends on the order in which systems are

Then the draft needs to say what the server needs to do if it doesn't use
the counter and the client sends a decline. Does the client get no address?

> Does (some version of) this sound reasonable?

Perhaps. But you have to document this, and if you document this and it
turns out that you need server-side behaviour changes, then you need to
update RFC 3315.

Again, I don't think it's worth it.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 08 Apr 2015 11:45:40 -0300

Hi, Lorenzo,

On 04/08/2015 09:45 AM, Lorenzo Colitti wrote:
> On Wed, Apr 8, 2015 at 9:28 PM, Fernando Gont <[email-masked]
> No, it's not enough. The attacker can only track or scan you if you use
> a stupid algorithm to generate the IIDs. Yours is not stupid, but
> neither are many others such as "random". You can perfectly well use
> random assignment on some subnets and your algorithm on other subnets.

The intent is that, for a given subnet, all IIDs have the same property.

But, in any case, as far as I recall this I-D does not say "you must
employ this algorithm for all of the prefixes from which you lease
addresses", anyway.

If you have any suggested text that would address your concern, please
do let us know.

> Regardless - if that's the intent, then the draft should say so.

mm.. how about changing this:

---- cut here ----

   Implementations conforming to this specification SHOULD provide the
   means for a system administrator to enable or disable the use of this
   algorithm for generating IPv6 addresses.

   All of the parameters included in the expression below MUST be
   included when generating an IPv6 address.

---- cut here ----

to to this:

---- cut here ----
   A DHCPv6 server implementation employing this specification MUST
   generate non-temporary IPv6 addresses for the corresponding prefix
   by means of the algorithm specified in this section.

   Implementations conforming to this specification SHOULD provide the
   means for a system administrator to enable or disable the use of this
   algorithm for generating IPv6 addresses.

   Unless otherwise noted, all of the parameters included in the
   expression below MUST be included when generating an IPv6 address.

   A DHCPv6 server employing this specification must select the IPv6
   addresses to be leased from the corresponding prefix with the
   following algorithm:
---- cut here ----

?

> I was referring to the lack of any such statement in the draft, yes.

Ok, how about adding something along these lines:

---- cut here ----
In order to achieve the goals described in Section 3 of this document,
all of the DHCPv6 servers leasing addresses from a given IPv6 address
range must employ this algorithm. If different DHCPv6 servers leasing
addresses from the same IPv6 address range employ different algorithms,
address stability will not be achieved.

DHCPv6 servers leasing addresses from different IPv6 address ranges may
employ other algorithms for selecting the IPv6 addresses to be leased.
We note, however, that security-unwise algorithm is employed for
selecting addresses from a different IPv6 address range on the same
subnet, the benefits of the algorithm specified in this document may be
reduced. For example, if a DHCPv6 server employs this algorithm for
selecting addresses from a given address range, and another server on
the same subnet selects address incrementally for a different address
range on the same subnet, a node that is leased addresses from both
address ranges will still be vulnerable to address scans attacks.
---- cut here ----

?

> Then the draft needs to say what the server needs to do if it doesn't
> use the counter and the client sends a decline. Does the client get no
> address?

If you don't use the counter at all, yes. However, I'd expect
implementations not to include the counter, but not to record it's
contents (if they don't record the address lease) -- (yes, sorry, my
previous response was confusing).

I'll craft text about this and send it to the list for review.

>     employ this algorithm for generating the addresses in the first place,
[....[
> Again, I don't think it's worth it.

For the time being, I think we should not consider the 100% stateless
version of this. After all, the man goal of this document is an address
selection scheme for DHCPv6, rather than an improvement in terms of "now
DHCPv6 can be fully stateless".

Thanks!

Best regards,

---

From: Christian Huitema <[email-masked]>
Date: Wed, 8 Apr 2015 21:32:24 +0000

To comment further on this discussion between Fernando and Lorenzo

> >     ...
> > No, it's not enough. The attacker can only track or scan you if you
> > use a stupid algorithm to generate the IIDs. Yours is not stupid, but

I think there is value in having some part of the DHCPv6 spec specify the "don't be stupid" logic. My personal preference would be to add the list of privacy attacks in the "security considerations" of DHCPv6bis. Something like:

Some address allocation schemes are known to be harmful, because they facilitate scanning, allow for information leakage, or fail to maintain the address stability required by many applications. In particular:
* Assigning addresses using some kind of sequential algorithm (prefix::1, prefix:2, prefix::3,...) greatly facilitate scanning of the network;
* Deriving the IID part of addresses from the link layer address of the client exposes information about the client hardware and enables tracking the client across multiple subnets;
* Using memory-less random allocation schemes fails to maintain enough stability for many applications;
The algorithm presented in [RFC7217] provides a solution to this problem for nodes using IPv6 Stateless Address Autoconfiguration. Similar algorithms could be used by DHCPv6 servers to avoid the aforementioned issues.

If we added that to the main DHCPv6 spec, there would be no need for a separate RFC presenting a variant of the 7217 algorithm.

-- Christian Huitema

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Apr 2015 21:48:20 +0000

There is already some text in draft-ietf-dhc-dhcpv6-privacy, section 4.3, on DHCP server allocation strategies, so it the question is whether that is sufficient or whether perhaps something is needed in the draft-huitema-dhc-anonymity-profile ... though I think that is more focused on the client. If there was existing text, the 3315bis document can refer to it in the Security/Privacy Considerations section. Note that I suspect that these privacy documents will be RFCs long before 3315bis will be.

I think your text is fine. And, it is recorded in the ticket on this issue, http://trac.tools.ietf.org/group/dhcpv6bis/ticket/145.

I also think your conclusion is fine :).

- Bernie

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]] 
Sent: Wednesday, April 08, 2015 5:32 PM
To: Fernando Gont; Lorenzo Colitti
Cc: [email-masked]; Bernie Volz (volz); Ted Lemon
Subject: RE: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

> > use a stupid algorithm to generate the IIDs. Yours is not stupid, 
> > but neither are many others such as "random". You can perfectly well 
> > use random assignment on some subnets and your algorithm on other subnets.

Some address allocation schemes are known to be harmful, because they facilitate scanning, allow for information leakage, or fail to maintain the address stability required by many applications. In particular:
* Assigning addresses using some kind of sequential algorithm (prefix::1, prefix:2, prefix::3,...) greatly facilitate scanning of the network;
* Deriving the IID part of addresses from the link layer address of the client exposes information about the client hardware and enables tracking the client across multiple subnets;
* Using memory-less random allocation schemes fails to maintain enough stability for many applications; The algorithm presented in [RFC7217] provides a solution to this problem for nodes using IPv6 Stateless Address Autoconfiguration. Similar algorithms could be used by DHCPv6 servers to avoid the aforementioned issues.

-- Christian Huitema

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Apr 2015 09:18:14 +0900

> If you have any suggested text that would address your concern, please

Well, as you know my suggestion is to leave this up to implementers and not
standardize this algorithm at all :-)

> DHCPv6 can be fully stateless".

If this algorithm does not allow stateless operation, and still requires
keeping (and synchronizing) a lease database, then I really don't see the
point of specifying this algorithm at all, as it provides no advantages
over stateful random assignment.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 09 Apr 2015 14:25:13 -0300

On 04/08/2015 09:18 PM, Lorenzo Colitti wrote:
> keeping (and synchronizing) a lease database, then I really don't see
> the point of specifying this algorithm at all, as it provides no
> advantages over stateful random assignment.

This algorithm doesn't require keeping a lease database. DHCPv6 does.

And no, as noted in my other email, it does not require synchronization
of the lease database. IN the case of failover, rather than "renewing"
or "rebinding" the same address, the node will be leased the same
address as if it was a brandnew address -- same end result.

So the clear benefit is that you can have multiple DHCPv6 servers
operating on the same network, and you get address stabiity without an
additional protocol.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 9 Apr 2015 18:29:31 +0000

> So the clear benefit is that you can have multiple DHCPv6 servers operating on the same network, and you get address stability without an additional protocol.

This concept is flawed if the servers aren't cooperating. If there are multiple servers that don't share lease data, how does server 1 know whether the lease was leased to another client or renewed, if server 2 ends up communicating with the client? Server 1 may also expire the lease (and remove FQDN or other data). Or when a leasequery is done, the servers will return conflicting data (one says not leased, other says leased).

I just don't buy that is has any real benefit.

But I am going to refrain from discussing this topic any further as my position (not as co-chair, but as an individual) is clear. Once we get different people to weight in (either on the mailing list or at IETF-93) to determine consensus we can figure out the appropriate next step.

- Bernie

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Thursday, April 09, 2015 1:25 PM
To: Lorenzo Colitti
Cc: [email-masked]; Bernie Volz (volz); Ted Lemon
Subject: Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

On 04/08/2015 09:18 PM, Lorenzo Colitti wrote:
> If this algorithm does not allow stateless operation, and still 
> requires keeping (and synchronizing) a lease database, then I really 
> don't see the point of specifying this algorithm at all, as it 
> provides no advantages over stateful random assignment.

And no, as noted in my other email, it does not require synchronization of the lease database. IN the case of failover, rather than "renewing"
or "rebinding" the same address, the node will be leased the same address as if it was a brandnew address -- same end result.

So the clear benefit is that you can have multiple DHCPv6 servers operating on the same network, and you get address stabiity without an additional protocol.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 09 Apr 2015 16:34:50 -0300

On 04/09/2015 03:29 PM, Bernie Volz (volz) wrote:
>> operating on the same network, and you get address stability
>> without an additional protocol.
> 
> This concept is flawed if the servers aren't cooperating. If there
> are multiple servers that don't share lease data, how does server 1
> know whether the lease was leased to another client or renewed, if
> server 2 ends up communicating with the client? 

Usually, you need servers to communicate because there's no way to tell
which address each server may have assigned to which client. But that's
not the case with this method.

Let me provide another example:

Let's assume that servers were to implement e method by which they
select the IID by embedding the client's MAC address in the IID (that
is, the server essentially generates a SLACC address for the client).

If you have multiple servers, and you have access to the client's MAC,
then there's no need for black magic to tell which addres will be leased
to which client.

The method specified in this document is similar in that respect, with
the only difference in that the IIDs are unpredictable.

> Server 1 may also
> expire the lease (and remove FQDN or other data). Or when a
> leasequery is done, the servers will return conflicting data (one
> says not leased, other says leased).

In all cases, the servers will compute the same address. -- that's the
whole point of the expression we use, and of the servers sharing the
same secret key.

> But I am going to refrain from discussing this topic any further as
> my position (not as co-chair, but as an individual) is clear. Once we
> get different people to weight in (either on the mailing list or at
> IETF-93) to determine consensus we can figure out the appropriate
> next step.

That's fine. I'd just like folks to decide based on the properties of
the method. Some of the assertions you've made about it are incorrect,
though.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Apr 2015 08:20:26 +0900

> not the case with this method.

It is still the case even with this method, because the servers need to
agree on the value of the counter variable.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Apr 2015 13:29:43 -0300

On 04/09/2015 08:20 PM, Lorenzo Colitti wrote:
> On Fri, Apr 10, 2015 at 4:34 AM, Fernando Gont <[email-masked]

The Counter value is there for completeness sake. Me, I don't expecThe
assumption is that thanks to the huge address space, you want hit
collisions.

In order for this scheme to not result in address stability, two things
must happen:

1) There address collisions -- considered extremely unlikely, and,

2) Clines employ different DHCPv6 servers (failover scenario), and,

2) The two nodes that bootstrap do so in a different order (otherwise,
they will still be leased the same addresses).

I'd say that a DHCPv6 servers is free to store the Counter value for
each lease, if they please. But it's not worth it to synchronize it. --
the assumption in this scheme is that the address space for the local
subnet is so large that you will not find collisions.

If you, we could rename the I-D as "probabilistically stable" -- but I
hope that's not needed.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 11 Apr 2015 13:38:44 +0900

> assumption is that thanks to the huge address space, you want hit

But you have to say what happens in this case. If the client sends a
DECLINE for any reason, what happens? Is it dead in the water with the
wrong IP address? Does the server just respond with the same IP address as
before, hoping that the client will like it? If you don't want the draft to
specify the behaviour, you should at least provide a list of the possible
options, because from what I see, the possible options are all bad.

> If you, we could rename the I-D as "probabilistically stable" -- but I

One of the major objections I have here is that the draft says that the
addresses are stable and stateless. However, that statement is not true in
the presence of DECLINEs, collisions, or misconfigurations (probably more
likely than collisions). If the draft didn't say the addresses are stable,
or if it didn't say that the addresses can be calculated statelessly, then
that would be OK, but it does. I think that if you want to standardize this
approach, then IMO you need to quantify what happens in these cases.

Also, I think statelessness is pointless. DHCPv6 is a fundamentally
stateful protocol. It's not just the lease database - clients and servers
also keep track of IAs, server IDs, client IDs, DUIDs. Even if you make the
address calculation stateless, to show value you'll need to show whether
this scheme works when you swap out servers. If it this scheme doesn't work
when you swap servers, then there's really no point in making the address
calculation stateless, since you need to share state anyway.

More in general. Whether you continue work on this document is to you, but
I'll point out that Bernie has stated multiple times that he wants to see
people support this draft, not just "not object to it". I don't see much in
the way of support today. As far as I'm concerned, you may be able to
address the issues that I list above and remove some of the objections, but
I doubt you'll be able to convince me personally that this scheme has value
and turn me into supporter.

Cheers,
Lorenzo

---

From: 神明達哉 <[email-masked]>
Date: Mon, 13 Apr 2015 11:16:56 -0700

At Thu, 09 Apr 2015 16:34:50 -0300,

> not the case with this method.

I tend to agree with Bernie here.  Those servers would most likely
have to maintain/share other kinds of states than address itself
anyway: T1/T2, address lifetimes, previously advertised FQDN, etc.
This algorithm might make address information optional from that has
to be explicitly shared, but even so it won't make the failover
implementation any simpler in practice.

As I stated in my own response to this inquiry, I see some niche
benefit in the proposed approach, so I wouldn't necessarily be opposed
to publishing it.  But, to me, the benefit seems to be quite minor.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2015 22:04:30 -0300

Hi, Lorenzo,

On 04/11/2015 01:38 AM, Lorenzo Colitti wrote:
> On Sat, Apr 11, 2015 at 1:29 AM, Fernando Gont <[email-masked]
> wrong IP address? Does the server just respond with the same IP address
> as before, hoping that the client will like it? If you don't want the
> draft to specify the behaviour, you should at least provide a list of
> the possible options, because from what I see, the possible options are
> all bad.

In my mental model, if the client sends a DECLINE, that's interpreted as
a collision, hence Counter is incremented, and you get a different IPv6
address.

I guess this should be configurable:
1) "Hard assignment": IPv6 addresses collisions are flagged as
"impossible", and server always offer the same address (i.e., Counter is
not used at all)

2) Soft assignment: server assigns an address but offers an alternative
one in the case of collisions.

Not sure why you say all options are bad. If you were doing
randomized/statefull DCHPv6 address assignments, you'd have to handle
DECLINEs, too.

> addresses are stable and stateless. However, that statement is not true
> in the presence of DECLINEs, collisions, or misconfigurations (probably
> more likely than collisions). If the draft didn't say the addresses are
> stable, or if it didn't say that the addresses can be calculated
> statelessly, then that would be OK, but it does. I think that if you
> want to standardize this approach, then IMO you need to quantify what
> happens in these cases.

Ok. I will craft text along these lines. Among other things, discuss
DECLINES, note that collissions are expected to be virtually impossible
thanks to the address space, etc.

> stateful protocol. It's not just the lease database - clients and
> servers also keep track of IAs, server IDs, client IDs, DUIDs. Even if
> you make the address calculation stateless, to show value you'll need to
> show whether this scheme works when you swap out servers. If it this
> scheme doesn't work when you swap servers, then there's really no point
> in making the address calculation stateless, since you need to share
> state anyway.

Swap == replace the server with a "cloned" one (same IPv6 address, and
Server DUID)?

or...?

> More in general. Whether you continue work on this document is to you,
> but I'll point out that Bernie has stated multiple times that he wants
> to see people support this draft, not just "not object to it". I don't
> see much in the way of support today. As far as I'm concerned, you may
> be able to address the issues that I list above and remove some of the
> objections, but I doubt you'll be able to convince me personally that
> this scheme has value and turn me into supporter.

Part of that seems to have to do with how things work if you swap the
server. I can give that a try (if you stay open to change yur mind if
that makes sense).

Thanks,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 14 Apr 2015 17:49:22 +0000

>Ok. I will craft text along these lines. Among other things, discuss DECLINES, note that collisions are expected to be virtually impossible thanks to the address space, etc.

This is NOT true at all (collisions virtually impossible). In fact, the exact opposite will almost certainly be true.

Also think of cases where much smaller spaces than a /64 are being used (such as when a server is configured for a start to end range (1 to 100000)) or when a longer prefix length is being used (/96) for assigning addresses.

- Bernie

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, April 13, 2015 9:05 PM
To: Lorenzo Colitti
Cc: Bernie Volz (volz); [email-masked]
Subject: Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

Hi, Lorenzo,

On 04/11/2015 01:38 AM, Lorenzo Colitti wrote:
> wrong IP address? Does the server just respond with the same IP 
> address as before, hoping that the client will like it? If you don't 
> want the draft to specify the behaviour, you should at least provide a 
> list of the possible options, because from what I see, the possible 
> options are all bad.

In my mental model, if the client sends a DECLINE, that's interpreted as a collision, hence Counter is incremented, and you get a different IPv6 address.

I guess this should be configurable:
1) "Hard assignment": IPv6 addresses collisions are flagged as "impossible", and server always offer the same address (i.e., Counter is not used at all)

2) Soft assignment: server assigns an address but offers an alternative one in the case of collisions.

Not sure why you say all options are bad. If you were doing randomized/statefull DCHPv6 address assignments, you'd have to handle DECLINEs, too.

> One of the major objections I have here is that the draft says that 
> the addresses are stable and stateless. However, that statement is not 
> true in the presence of DECLINEs, collisions, or misconfigurations 
> (probably more likely than collisions). If the draft didn't say the 
> addresses are stable, or if it didn't say that the addresses can be 
> calculated statelessly, then that would be OK, but it does. I think 
> that if you want to standardize this approach, then IMO you need to 
> quantify what happens in these cases.

Ok. I will craft text along these lines. Among other things, discuss DECLINES, note that collissions are expected to be virtually impossible thanks to the address space, etc.

> you make the address calculation stateless, to show value you'll need 
> to show whether this scheme works when you swap out servers. If it 
> this scheme doesn't work when you swap servers, then there's really no 
> point in making the address calculation stateless, since you need to 
> share state anyway.

Swap == replace the server with a "cloned" one (same IPv6 address, and Server DUID)?

or...?

> this scheme has value and turn me into supporter.

Part of that seems to have to do with how things work if you swap the server. I can give that a try (if you stay open to change yur mind if that makes sense).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Apr 2015 15:58:11 -0300

On 04/14/2015 02:49 PM, Bernie Volz (volz) wrote:
>> Ok. I will craft text along these lines. Among other things,
>> discuss DECLINES, note that collisions are expected to be virtually
>> impossible thanks to the address space, etc.
> 
> This is NOT true at all (collisions virtually impossible). In fact,
> the exact opposite will almost certainly be true.

May I ask that you provide a rationale for that assertion?

Mine is this: the subnet address space is so large that the problem is
essentially a birthday paradox.

> Also think of cases where much smaller spaces than a /64 are being
> used (such as when a server is configured for a start to end range (1
> to 100000)) or when a longer prefix length is being used (/96) for
> assigning addresses.

That is true. In the first version of the I-D we didn't support ranges.
Now we do, and we should certainly put a huge warning that the address
space should be huge, or things don't work as expected.

If you ask me, I'd say that the standard subnet size is /64. And if you
have a /64 but are assigning addresses from, say, a /110, that's where
the flaw relies. And if you just want to keep some part of the address
space for assigning static addresses to servers, then grab a small
address pool for that, and use the rest for the random/stable addresses
-- but not the other way around!

Thanks!

Cheers,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 15 Apr 2015 10:09:33 +0900

> space should be huge, or things don't work as expected.

Supporting stateless allocation in anything smaller than a /64 is harmful.

You are creating the risk that people coming from outdated IPv4 assumptions
will take a /112, think, "That's big enough for everyone, right? I only
have a few hundred hosts. And I want to limit my subnet size to avoid these
ND cache DoS attacks I've heard about," and get burned by the fact that
there's a 50% chance of collision when there are 250 hosts in the network.
Because your algorithm doesn't support collisions well, they'll be
completely stuck.

Before you argue that it makes sense to support stateless allocation when
the subnet is "large enough" - how large is large enough? People used to
fully-stateful IPv4 deployments with forced forwarding (e.g., large
conference networks that force 1 IPv4 address = 1 MAC address and don't use
broadcast ARP because the wifi chipset filters it out for them) may well do
something like /96 (That's large enough, right? It's the size of the whole
of the IPv4 Internet!) and put 20,000 hosts on it and fall over in the same
way. Yes - large conferences like MWC do have 20k hosts on the same subnet.

Also - if you change the range size, do all the addresses change? That
would make it an even worse idea.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Apr 2015 21:51:03 -0400

> essentially a birthday paradox.

That assumes a random distribution.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Apr 2015 13:26:38 -0300

> That assumes a random distribution.

Random addreses, uniform distribution. And F() provides that.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Apr 2015 13:34:15 -0300

On 04/14/2015 10:09 PM, Lorenzo Colitti wrote:
> On Wed, Apr 15, 2015 at 3:58 AM, Fernando Gont <[email-masked]
> You are creating the risk that people coming from outdated IPv4
> assumptions will take a /112, think, "That's big enough for everyone,
> right? I only have a few hundred hosts. And I want to limit my subnet
> size to avoid these ND cache DoS attacks I've heard about," and get
> burned by the fact that there's a 50% chance of collision when there are
> 250 hosts in the network. Because your algorithm doesn't support
> collisions well, they'll be completely stuck.

The only reason for which ranges are supported is such that you can
reserve a small part of the address space for static allocations.

Reserving ~100-1000 out of the 2**64 addresses is more than enough for
that purpose, and does not affect the collision rate.

> Before you argue that it makes sense to support stateless allocation
> when the subnet is "large enough" - how large is large enough? People
> used to fully-stateful IPv4 deployments with forced forwarding (e.g.,
> large conference networks that force 1 IPv4 address = 1 MAC address and
> don't use broadcast ARP because the wifi chipset filters it out for
> them) may well do something like /96 (That's large enough, right? It's
> the size of the whole of the IPv4 Internet!) and put 20,000 hosts on it
> and fall over in the same way. Yes - large conferences like MWC do have
> 20k hosts on the same subnet.

Sorry, I don't follow. I never argued in favor of non-/64 subnets. And,
as noted above, the only reason for which our I-D supports ranges is so
that you can reserver a tiny bit of the address space for static
allocations. That's it.

> would make it an even worse idea.

They don't. It's the Prefix that we include in F().