Subject: [v6ops] Security: Unique IPv6 Prefix per Host

From: DY Kim <[email-masked]>
Date: Fri, 27 Oct 2017 10:32:17 +0900

Hi all,

How do you ensure the periodically changed or randomized link-layer addresses are not duplicate on the shared network?

Is the collision detection of the link-layer addresses stated somewhere in NDv6?

---
DY

---

From: Fred Baker <[email-masked]>
Date: Fri, 27 Oct 2017 10:42:17 +0400

> On Oct 27, 2017, at 5:32 AM, DY Kim <[email-masked]> wrote:
> 

It's beyond me why we care about link layer addresses in a network layer protocol in which the network layer addresses are not derived from link layer addresses.

---

From: DY Kim <[email-masked]>
Date: Fri, 27 Oct 2017 19:17:53 +0900

I’m talking about the 2nd last paragraph of Sec. 7  "Security Considerations" of https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13:

"If a host wishes to maintain privacy on such networks, it SHOULD ensure that its link-layer address is periodically changed or randomized.”

---
DY

> On 27 Oct 2017, at 15:42, Fred Baker <[email-masked]> wrote:
> 
> 
>

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 Oct 2017 22:22:58 +1100

On 27 Oct. 2017 21:18, "DY Kim" <[email-masked]> wrote:

I’m talking about the 2nd last paragraph of Sec. 7  "Security
Considerations" of https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-
prefix-per-host-13:

"If a host wishes to maintain privacy on such networks, it SHOULD ensure
that its link-layer address is periodically changed or randomized.”

The assumption is that the prefix may be tied to a host's link-layer
address, making a prefix an analog for an individual host, defeating
privacy.

That should probably be expanded on a bit and explained.

Regards,
Mark.

---
DY

>> How do you ensure the periodically changed or randomized link-layer
addresses are not duplicate on the shared network?
>
> It's beyond me why we care about link layer addresses in a network layer
protocol in which the network layer addresses are not derived from link
layer addresses.

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

---

From: DY Kim <[email-masked]>
Date: Fri, 27 Oct 2017 20:39:09 +0900

Let me elaborate my question again.

3rd para of Sec. 4:

"When the First Hop Router sends a solicited RA response, or periodically sends unsolicited RAs, the RA MUST be sent only to the subscriber that has been assigned the Unique IPv6 prefix contained in the RA.  This is achieved by sending a solicited RA response or unsolicited RAs to the all-nodes group, as detailed in RFC4861 [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link-layer multicast address associated with the all-nodes group, the link-layer unicast address of the subscriber that has been assigned the Unique IPv6 prefix contained in the RA MUST be used as the link-layer destination RFC6085 [RFC6085].”

Then, 2nd last sentence of Sec. 7:

My question:

"How do you ensure the periodically changed or randomized link-layer addresses are not duplicate on the shared network?"

---
DY

> On 27 Oct 2017, at 20:22, Mark Smith <[email-masked]> wrote:
> 
> 
> 
> The assumption is that the prefix may be tied to a host's link-layer address, making a prefix an analog for an individual host, defeating privacy.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 Oct 2017 22:29:52 +0900

On Fri, Oct 27, 2017 at 8:39 PM, DY Kim <[email-masked]> wrote:

> "How do you ensure the periodically changed or randomized link-layer
> addresses are not duplicate on the shared network?"
>

You keep the network small enough that the expected number of collisions is
less than the reliability goals of the network.

Example: with a 46-bit random MAC address and 1000 hosts chosen at random,
the probability of a collision is less than 1 in 100M. Even when more hosts
are added, the probability of collision goes below 99.999% only when there
are more than ~37000 hosts on the network. Most networks don't provide
99.999% uptime.

http://mac-collision-probability.appspot.com/

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 27 Oct 2017 14:05:46 +0000

If the link layer address is periodically changed, how will the router send RAs to the new LL of the subscriber? Should that be explained in the draft?

Dusan

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of DY Kim
> Sent: Friday, October 27, 2017 7:39 AM
> To: Mark Smith
> Cc: v6ops list
> Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host
> 
> "When the First Hop Router sends a solicited RA response, or periodically sends
> unsolicited RAs, the RA MUST be sent only to the subscriber that has been
> assigned the Unique IPv6 prefix contained in the RA.  This is achieved by sending
> a solicited RA response or unsolicited RAs to the all-nodes group, as detailed in
> RFC4861 [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link-layer
> multicast address associated with the all-nodes group, the link-layer unicast
> address of the subscriber that has been assigned the Unique IPv6 prefix
> contained in the RA MUST be used as the link-layer destination RFC6085
> [RFC6085].”
> 
> "If a host wishes to maintain privacy on such networks, it SHOULD ensure that
> its link-layer address is periodically changed or randomized.”
> 
> My question:
> 
> > I’m talking about the 2nd last paragraph of Sec. 7  "Security Considerations" of
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dunique-2Dipv6-2Dprefix-
> 2Dper-2Dhost-
> 2D13&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo
> UWB8YLZU23029sMQGQ2kY&m=dyjvRnnyNAOIt36FqtilUbfZGjTMATslNrgyG7
> 6dVj8&s=pyZSBDrYiinER2MflzUajtZ5UZ-5FhI2lL40lqsQRao&e=:
> >
> > "If a host wishes to maintain privacy on such networks, it SHOULD ensure that
> its link-layer address is periodically changed or randomized.”
> >
> > The assumption is that the prefix may be tied to a host's link-layer address,
> making a prefix an analog for an individual host, defeating privacy.
> >
> protocol in which the network layer addresses are not derived from link layer
> addresses.
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dyjvR
> nnyNAOIt36FqtilUbfZGjTMATslNrgyG76dVj8&s=D2e2MIClb5PoiCzRPhBKTYmw
> 1BU8SeotmQe4QiBp6RE&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dyjvR
> nnyNAOIt36FqtilUbfZGjTMATslNrgyG76dVj8&s=D2e2MIClb5PoiCzRPhBKTYmw
> 1BU8SeotmQe4QiBp6RE&e=

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Oct 2017 10:15:41 -0400

> If the link layer address is periodically changed, how will the router send RAs to the new LL of the subscriber? Should that be explained in the draft?

From the router's perspective it's just a new host—it doesn't know that "it has changed its LL address".

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 27 Oct 2017 14:36:38 +0000

Hi Ted,

Can you provide more details please? Like:

-          Would the host send RS when the link-layer address changes?

-          Would the router assign a new prefix to the host?

-          If the ‘new host’ gets a ‘new prefix’, what happens to the host’s old prefix and address?

-          …?

Thanks,
Dusan.

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, October 27, 2017 10:16 AM
To: Mudric, Dusan (Dusan)
Cc: DY Kim; Mark Smith; v6ops list
Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host

On Oct 27, 2017, at 10:05 AM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
If the link layer address is periodically changed, how will the router send RAs to the new LL of the subscriber? Should that be explained in the draft?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Oct 2017 10:46:27 -0400

> -          Would the host send RS when the link-layer address changes?

Presumably so, but this would require that the host be deliberately trying to get a new prefix.

> -          Would the router assign a new prefix to the host?

Presumably so.

> -          If the ‘new host’ gets a ‘new prefix’, what happens to the host’s old prefix and address?

It's still valid until the valid lifetime expires.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 27 Oct 2017 14:59:02 +0000

This behavior needs to be defined in the draft because the link-layer address change does impact the unique prefix(es) (can be two ‘unique’ prefixes assigned to the host during the transition; the prefixes are then not quite ‘unique’) on the host.

If the link-layer address changes on the host and the router has a packet to deliver to it, before the router was able to detect the host is unreachable on the old link-layer address, what happens to the packet? Since NCE entry is still in the table, is the router going to do the address resolution for the old IPv6 address or drop the packet?

Dusan

Sent: Friday, October 27, 2017 10:46 AM

On Oct 27, 2017, at 10:36 AM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
-          Would the host send RS when the link-layer address changes?

Presumably so.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 28 Oct 2017 00:04:10 +0900

A host interested in privacy should not change the link-layer address while
connected, as that could be a clear signal to the network that it is in
fact the same host. It should instead disconnect from the network and
assume a new link-layer address the next time it connects.

On Fri, Oct 27, 2017 at 11:59 PM, Mudric, Dusan (Dusan) <[email-masked]>
wrote:

> This behavior needs to be defined in the draft because the link-layer
> address change does impact the unique prefix(es) (can be two ‘unique’
> prefixes assigned to the host during the transition; the prefixes are then
> not quite ‘unique’) on the host.
>
>
>
> If the link-layer address changes on the host and the router has a packet
> to deliver to it, before the router was able to detect the host is
> unreachable on the old link-layer address, what happens to the packet?
> Since NCE entry is still in the table, is the router going to do the
> address resolution for the old IPv6 address or drop the packet?
>
>
>
> Dusan
>
>
>
> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Friday, October 27, 2017 10:46 AM
> *To:* Mudric, Dusan (Dusan)
> *Cc:* DY Kim; Mark Smith; v6ops list
> *Subject:* Re: [v6ops] Security: Unique IPv6 Prefix per Host
>
>
>

---

From: DY Kim <[email-masked]>
Date: Sat, 28 Oct 2017 09:26:41 +0900

I’m afraid not. The whole idea of changing the link-layer address (as I understand the draft) is not to be tracked by the combination of the unique prefix and the link-layer, for privacy. When the link-layer address changes while the same prefix be kept, the correspondence between the two breaks so that the host may not be traced. This is as I understand the idea of the draft:

Para in Sec. 7:

"If the operator assigns the same unique prefix to the same link-layer address every time a host connects, any remote party who is aware of this fact can easily track a host simply by tracking its assigned prefix.  This nullifies the benefit provided by privacy addresses RFC4941 [RFC4941]."

---
DY

> On 27 Oct 2017, at 23:46, Ted Lemon <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Sat, 28 Oct 2017 09:29:40 +0900

I’m afraid that’s not the idea of the draft, Lorenzo. The draft reads in Sec. 7:

"If the operator assigns the same unique prefix to the same link-layer address every time a host connects, any remote party who is aware of this fact can easily track a host simply by tracking its assigned prefix.  This nullifies the benefit provided by privacy addresses RFC4941 [RFC4941
].  If a host wishes to maintain privacy on such networks, it SHOULD ensure that its link-layer address is periodically changed or randomized.”

---
DY

> On 28 Oct 2017, at 00:04, Lorenzo Colitti <[email-masked]> wrote:
> 
> A host interested in privacy should not change the link-layer address while connected, as that could be a clear signal to the network that it is in fact the same host. It should instead disconnect from the network and assume a new link-layer address the next time it connects.

---

From: DY Kim <[email-masked]>
Date: Sat, 28 Oct 2017 10:05:57 +0900

OK, you mean to leave it to the chance as we do with randomized iid.

With iid, however, we thus have to DAD since it is left to chance.

Shouldn’t we then do the same for the randomized link-layer address of this draft, too? That is, shouldn’t there be a collision detection procedure accompanied to the randomizing?

---
DY

> On 27 Oct 2017, at 22:29, Lorenzo Colitti <[email-masked]> wrote:
> 
> You keep the network small enough that the expected number of collisions is less than the reliability goals of the network.
> 
> Example: with a 46-bit random MAC address and 1000 hosts chosen at random, the probability of a collision is less than 1 in 100M. Even when more hosts are added, the probability of collision goes below 99.999% only when there are more than ~37000 hosts on the network. Most networks don't provide 99.999% uptime.
>

---

From: David Farmer <[email-masked]>
Date: Fri, 27 Oct 2017 20:19:50 -0500

> On Oct 27, 2017, at 19:29, DY Kim <[email-masked]> wrote:
> 

Based on the context within the first sentence, I believe the intent is fairly clear, randomization is in tended to occur on connection.  However, that could be made abundantly clear by adding “when connecting” to the end of the last sentence.

---

From: DY Kim <[email-masked]>
Date: Sat, 28 Oct 2017 10:24:44 +0900

Yes, I do agree to your interpretation.

On the other hand, ‘periodically’ may not necessarily mean ‘when connecting’…

---
DY

> On 28 Oct 2017, at 10:19, David Farmer <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 27 Oct 2017 18:52:31 -0700

> On the other hand, ‘periodically’ may not necessarily mean ‘when connecting’…
I'm not sure that difference is relevant unless 'periodically' gets
down to some very small interval. RFC4941 suggests that default should
be one day, but that was 2007 when maybe it made sense. But, now we
clearly have devices running apps that are constantly connected and
users are identified via a login (like Google, Facebook apps on a
smartphone etc.). So any time the prefix is changed they will see the
new prefix and be able to associate the address with a user. If the
user then connects to a different site, the information needed to
correlate the source address to a user already exists in the outside
world-- preventing someone from doing the correlation is out of the
user's and their network providers hands.

If the user wants strong privacy it seems like best way is get
multiple uncorrelated addresses via DHCPv6 and use them only once
(i.e. a different address per connection where privacy is required).

Tom

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 28 Oct 2017 13:04:15 +0900

I see no contradiction between these two things. A privacy-sensitive host
that is not managed by the network operator is free to disconnect from
network whenever it wants, and can reconnect with a different link-layer
address.

On Sat, Oct 28, 2017 at 9:29 AM, DY Kim <[email-masked]> wrote:

> "If the operator assigns the same unique prefix to the same link-layer
> address every time a host connects, any remote party who is aware of this
> fact can easily track a host simply by tracking its assigned prefix.  This
> nullifies the benefit provided by privacy addresses RFC4941 [RFC4941
> ].  If a host wishes to maintain privacy on such networks, it SHOULD
> ensure that its link-layer address is periodically changed or randomized.”
>
> ---
> DY
>
> > A host interested in privacy should not change the link-layer address
> while connected, as that could be a clear signal to the network that it is
> in fact the same host. It should instead disconnect from the network and

---

From: DY Kim <[email-masked]>
Date: Sat, 28 Oct 2017 19:29:43 +0900

OK, let’s focus on this point; reconnect with a different link-layer address.

How do you ensure that the refreshed link-layer address is not already used by another device on the same shared network?

Just leave it to a chance since the collision probability is low enough?

Or don’t we have to run a DAD-like protocol (in the link layer?) to avoid use of duplicate link-layer address of the shared network in question?

---
DY

> On 28 Oct 2017, at 13:04, Lorenzo Colitti <[email-masked]> wrote:
> 
> and can reconnect with a different link-layer address.

---

From: DY Kim <[email-masked]>
Date: Sat, 28 Oct 2017 19:30:47 +0900

> On 28 Oct 2017, at 19:29, DY Kim <[email-masked]> wrote:
> 
> to avoid use of duplicate link-layer address IN the shared network

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 28 Oct 2017 19:56:40 +0900

As I said before, you don't need to ensure it's unique, you only need to
ensure it's unique enough.

Additionally, that problem is separate from this document, as it is common
to any form of MAC address randomization.

You can certainly design a protocol to perform DAD on MAC addresses, but I
don't think that would be done at the IETF since it's link layer specific.
Some links, like Wi-Fi, use the MAC address to identify the host at layer
2, so any whatever scheme you design will need to take that into account.

On 28 Oct 2017 19:29, "DY Kim" <[email-masked]> wrote:

> How do you ensure that the refreshed link-layer address is not already
> used by another device on the same shared network?
>
> Or don’t we have to run a DAD-like protocol (in the link layer?) to avoid
> use of duplicate link-layer address of the shared network in question?
>
> ---
> DY
>

---

From: DY Kim <[email-masked]>
Date: Sat, 28 Oct 2017 20:17:52 +0900

OK, although I’m not fully happy with the apparent reality.

---
DY

> On 28 Oct 2017, at 19:56, Lorenzo Colitti <[email-masked]> wrote:
> 
> As I said before, you don't need to ensure it's unique, you only need to ensure it's unique enough.
> 
> Additionally, that problem is separate from this document, as it is common to any form of MAC address randomization.

---

From: Ole Troan <[email-masked]>
Date: Sat, 28 Oct 2017 13:20:03 +0200

> On 28 Oct 2017, at 13:17, DY Kim <[email-masked]> wrote:
> 

Consider that a part of the human condition. 

Ole

---

From: DY Kim <[email-masked]>
Date: Sat, 28 Oct 2017 20:25:51 +0900

:-).

---
DY

> On 28 Oct 2017, at 20:20, Ole Troan <[email-masked]> wrote:
> 
>> 
>> OK, although Ifm not fully happy with the apparent reality.
>

---

From: Tom Herbert <[email-masked]>
Date: Sat, 28 Oct 2017 12:07:44 -0700

> network whenever it wants, and can reconnect with a different link-layer
Lorenzo,

What frequency of disconnecting and reconnecting is needed to ensure
the user's privacy? Consider that the user might be a political
dissident speaking out against an oppressive government, so privacy
could very well be a matter of life and death for them.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Sat, 28 Oct 2017 15:19:47 -0400

> could very well be a matter of life and death for them.

Tom, how are we in the IETF supposed to answer that?   We are providing the mechanism here.   It's up to either the user or the provider of the service they are using to figure out what frequency is right.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 28 Oct 2017 13:51:08 -0700

On Oct 28, 2017 12:19 PM, "Ted Lemon" <[email-masked]> wrote:

Tom, how are we in the IETF supposed to answer that?   We are providing the
mechanism here.   It's up to either the user or the provider of the service
they are using to figure out what frequency is right.

Ted,

The fact that IETF can't answer the question is precisely the problem. With
one exception, there is no way to quantify the effectiveness of periodic
address randomization to provide privacy.  We can only make qualitative
statements that higher frequency of randomization seems to be better.

The exception is the case of single use addresses, that is a different
source address per connection. In this case the privacy properties are
quantifiable, given any two connections, a third party cannot determine any
significant correlation or identification based on the source addresses.

The irony is that single use addresses are widely deployed for IPv4 in the
form of NAT. It provides strong privacy properties as validated by law
enforcement's concerns over it's use. In this sense it seems to be that
privacy is stronger in IPv4 that IPv6 as being deployed today. I believe,
to get IPv6 to the same level of privacy without resorting to NAT can be
done by allocating sufficiently randomized host addresses and the system
can enforce single use. I think this could work concurrently with prefix
allocation, and would be used when user privacy is essential.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Sat, 28 Oct 2017 16:56:43 -0400

On Oct 28, 2017, at 4:51 PM, Tom Herbert <[email-masked]> wrote:
> The fact that IETF can't answer the question is precisely the problem. With one exception, there is no way to quantify the effectiveness of periodic address randomization to provide privacy.  We can only make qualitative statements that higher frequency of randomization seems to be better.

In what sense is it a problem?

> The exception is the case of single use addresses, that is a different source address per connection. In this case the privacy properties are quantifiable, given any two connections, a third party cannot determine any significant correlation or identification based on the source addresses.

This is (a) the problem the draft we are discussing solves and (b) not the issue.   The issue we are solving here is varying the _prefix_ in addition to the host bits.

> The irony is that single use addresses are widely deployed for IPv4 in the form of NAT. It provides strong privacy properties as validated by law enforcement's concerns over it's use. In this sense it seems to be that privacy is stronger in IPv4 that IPv6 as being deployed today. I believe, to get IPv6 to the same level of privacy without resorting to NAT can be done by allocating sufficiently randomized host addresses and the system can enforce single use. I think this could work concurrently with prefix allocation, and would be used when user privacy is essential.

Well, in IPv4 you get a /32.   In IPv6 with this proposal you get a /64.   So it's hard to see how IPv4 gives you better privacy.   If you mean "because people don't use privacy addresses," then you are right, but that's why we're advocating the use of privacy addresses.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 28 Oct 2017 14:22:01 -0700

On Oct 28, 2017 1:56 PM, "Ted Lemon" <[email-masked]> wrote:

On Oct 28, 2017, at 4:51 PM, Tom Herbert <[email-masked]> wrote:
> The fact that IETF can't answer the question is precisely the problem.
With one exception, there is no way to quantify the effectiveness of
periodic address randomization to provide privacy.  We can only make
qualitative statements that higher frequency of randomization seems to be
better.

In the sense that I cannot provide any sane guidance to the user about what
a correct frequency is to ensure their privacy. If the intent of the
mechanism is to protect privacy, then we should be able to give some
assurance that the mechanism does that.

This is (a) the problem the draft we are discussing solves and (b) not the
issue.   The issue we are solving here is varying the _prefix_ in addition
to the host bits.

Right, it's the prefix that identifies the device, varying the host bits
doesn't help here.

> The irony is that single use addresses are widely deployed for IPv4 in
the form of NAT. It provides strong privacy properties as validated by law

Well, in IPv4 you get a /32.   In IPv6 with this proposal you get a /64.
 So it's hard to see how IPv4 gives you better privacy.   If you mean
"because people don't use privacy addresses," then you are right, but
that's why we're advocating the use of privacy addresses.

It's not IPv4 that provides privacy, it's NAT. If a host creates two
connections that go through a NAT the source address and port are rewritten
such that no one in the outside world can determine the two connections
originated from the same host device.

In a /64 assignment, if a host creates two flows then they will share the
same prefix and can be correlated to have originated from the same device.
The intent of refreshing the prefix is to minimize the number of flows that
use the address to reduce tracking. But, I suspect that the benefits high
frequency can be negated by just one app that wants to be always connected
and its server maintains a log of addresses and identities The logs can the
be used to identify flows to other sites that are intercepted. Single use
/128 host addresses cannot be tracked this way.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Sat, 28 Oct 2017 17:37:35 -0400

> The fact that IETF can't answer the question is precisely the problem. With one exception, there is no way to quantify the effectiveness of periodic address randomization to provide privacy.  We ca…

I hear you, Tom, and I agree that this is a problem.  There are actually two problems here: how do we vary the IP address and prefix, and at what rate do we vary them.   We have solved the first problem.   We have not solved the second.   I don't know the right answer.   This is an area in which research can now be done, because we have a protocol mechanism for varying the address.   It would be nice if we already knew the answer, but we don't.

> The exception is the case of single use addresses, that is a different source address per connection. In this case the privacy properties are quantifiable, given any two connections, a third party…

The source addresses contain topology information, so I would say that this statement isn't true.   This is why we want to vary the prefix: just varying the host bits doesn't get you any more privacy than NAT, because the tracker can key on the prefix, which will not vary.   Even then, you can do statistical tricks to correlate behavior if you are able to collect enough different bits of envelope information from an individual user and correlate them with other information you get through other means.

> The irony is that single use addresses are widely deployed for IPv4 in the form of NAT. It provides strong privacy properties as validated by law enforcement's concerns over it's use. In this sense…

I think this is a very plausible claim, which you (or someone) should test for practicality.   Suppose we decide that this is really the only good solution.   What parts of the infrastructure break if we start doing this?   That's a problem we can look at solving.

---

From: David Farmer <[email-masked]>
Date: Sat, 28 Oct 2017 16:50:12 -0500

>> On Oct 28, 2017, at 14:07, Tom Herbert <[email-masked]> wrote:
>> 

No amount of changing the prefix or IID is going to be sufficient to protect someone by itself. If the consequences are dire enough, or the motivation to track someone is strong enough, and the resources available to the tracker are sufficient, then the form of privacy provided by changing addresses by itself is not sufficient to protect users from tracking. There is no inherent privacy provided by changing your address, any privacy only comes from blending in and being indistinguishable from the other users of a service.

Therefore, changing the prefix or IID too frequent only serves to attract attention. Honestly, there is no absolute value for how frequently to make such changes, the optimal value depends on the usage patterns of the other users of a service.

David Farmer

---

From: Tom Herbert <[email-masked]>
Date: Sat, 28 Oct 2017 14:59:39 -0700

Hi

On Oct 28, 2017 2:37 PM, "Ted Lemon" <[email-masked]> wrote:

> I hear you, Tom, and I agree that this is a problem.  There are actually
> two problems here: how do we vary the IP address and prefix, and at what
> rate do we vary them.   We have solved the first problem.   We have not
> solved the second.   I don't know the right answer.   This is an area in
> which research can now be done, because we have a protocol mechanism for
> varying the address.   It would be nice if we already knew the answer, but
> we don't.
>
> The source addresses contain topology information, so I would say that
> this statement isn't true.   This is why we want to vary the prefix: just
> varying the host bits doesn't get you any more privacy than NAT, because
> the tracker can key on the prefix, which will not vary.   Even then, you
> can do statistical tricks to correlate behavior if you are able to collect
> enough different bits of envelope information from an individual user and
> correlate them with other information you get through other means.
>

Right, that's why I carefully used the words "significant correlation" :-)

> I think this is a very plausible claim, which you (or someone) should test
> for practicality.   Suppose we decide that this is really the only good
> solution.   What parts of the infrastructure break if we start doing this?
>  That's a problem we can look at solving.
>

Some of this has been touched upon in the IDEAS discussions, but nothing
formalized yet (identifier-locator use implied to eliminate as much
topology on address as possible). I could spin a draft specifically on one
time use addresses and privacy (won't make cutoff though).

Tom

---

From: Ted Lemon <[email-masked]>
Date: Sat, 28 Oct 2017 18:19:41 -0400

On Oct 28, 2017, at 5:59 PM, Tom Herbert <[email-masked]> wrote:
> Some of this has been touched upon in the IDEAS discussions, but nothing formalized yet (identifier-locator use implied to eliminate as much topology on address as possible). I could spin a draft specifically on one time use addresses and privacy (won't make cutoff though).

The problem is that now you have a requirement for substantial infrastructure to manage the ID/locator separation.   Would look a bit like Tor.   Who's going to pay for it?

---

From: Tom Herbert <[email-masked]>
Date: Sat, 28 Oct 2017 15:29:33 -0700

> could very well be a matter of life and death for them.

No amount of changing the prefix or IID is going to be sufficient to
protect someone by itself. If the consequences are dire enough, or the
motivation to track someone is strong enough, and the resources available
to the tracker are sufficient, then the form of privacy provided by
changing addresses by itself is not sufficient to protect users from
tracking. There is no inherent privacy provided by changing your address,
any privacy only comes from blending in and being indistinguishable from
the other users of a service.

David,

I think the fact that law enforcement is afraid of NAT is my counter
argument. But, it is true that NAT blends traffic such that all source
addresses and ports convey little distinguishable information about the
underlying source. And the properties of this blending can be quantified. I
am saying that we should want a mechanism in IPv6 with similar properties
but without NAT.

Tom

Therefore, changing the prefix or IID too frequent only serves to attract
attention. Honestly, there is no absolute value for how frequently to make
such changes, the optimal value depends on the usage patterns of the other
users of a service.

David Farmer

---

From: Tom Herbert <[email-masked]>
Date: Sat, 28 Oct 2017 15:36:41 -0700

On Oct 28, 2017 3:19 PM, "Ted Lemon" <[email-masked]> wrote:

The problem is that now you have a requirement for substantial
infrastructure to manage the ID/locator separation.   Would look a bit like
Tor.   Who's going to pay for it?

Ted,

Identifier-locator is already being proposed/implemented for mobile
networks to provide mobility. Single use addresses versus prefixes are two
variants handled by a core infrastructure of that.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Sat, 28 Oct 2017 18:42:17 -0400

On Oct 28, 2017, at 6:36 PM, Tom Herbert <[email-masked]> wrote:
> Identifier-locator is already being proposed/implemented for mobile networks to provide mobility. Single use addresses versus prefixes are two variants handled by a core infrastructure of that.

Yup.   But that actually makes your address more stable.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 29 Oct 2017 09:14:26 +0900

On 29 Oct 2017 04:07, "Tom Herbert" <[email-masked]> wrote:

I don't know the answer to that question.

However, the privacy section in this draft is comparing this scheme to RFC
4941, which by default changes addresses once per day. Disconnecting once
per day doesn't even seem like something the user would consciously need to
do - they can just move around and naturally disconnect.

OTOH, if an oppressive government is in a position to compel the network to
track a user's activities, I don't know that RFC 4941 would help much at
all - or any privacy scheme based only on changing IP addresses. Other
angles of attack such as sniffing DNS and SNI handshakes seem quite
dangerous even if IP addresses are completely anonymized.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 29 Oct 2017 09:24:39 +0900

On 29 Oct 2017 05:51, "Tom Herbert" <[email-masked]> wrote:

But on the other hand single use IP addresses have an extremely dangerous
weakness: if someone can compel or compromise the party handing out the
/128s, then all IP address privacy for all user's on that network is gone.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sun, 29 Oct 2017 01:44:40 +0000

> But, it is true that NAT blends traffic such that all
> source addresses and ports convey little
> distinguishable information about the underlying
> source. And the properties of this blending can be
> quantified. I am saying that we should want a
> mechanism in IPv6 with similar properties but
> without NAT.

The property of a NAT that gives rise to enhanced privacy is the lack of link identifier in the address tuple (address+port). Without such an identifier, some network element needs to keep state to map address tuples to links. That network element would be very much a NAT, even if it goes by any other name (even if the network element picks not only the port but also an ip from a large pool available to it).

What's worse is that NATs are technically necessary and therefore ubiquitous in the IPv4 world. No one, including state agencies, could fault or suspect anyone for using a NAT or outlaw NATs. With IPv6, NAT-like devices are technically unnecessary. They can be outlawed, or their use can draw special attention.

Users requiring absolute privacy, especially operating in environments hostile to privacy, are well-advised not to rely on their ISP to guarantee their privacy.

So strong privacy is not likely to be found in some feature of IPv6. Privacy can be enhanced by pretending to your ISP to be multiple users (as was suggested in terms of reconnections with mutating link addresses) -- something that is problematic to do often enough not to draw attention and, therefore, is prone to creating correlations between concurrent connections.

Privacy can also be found in disguising your "objectionable" network activities as "ordinary" activities -- something that requires 3rd party cooperating hosts. (For example, using stenography in pictures/videos you regularly upload to a popular picture/video sharing sites. This is a high latency, low bandwidth channel, unless the popular site itself is a cooperating party.)

- Igor

-----Original Message-----
From: Tom Herbert [[email-masked]]
Received: Saturday, 28 Oct 2017, 6:29PM
To: David Farmer [[email-masked]]
CC: IPv6 Operations [[email-masked]]
Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host

On Oct 28, 2017 2:50 PM, "David Farmer" <[email-masked]<mailto:[email-masked]>> wrote:

>> On Oct 28, 2017, at 14:07, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> On Fri, Oct 27, 2017 at 9:04 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

David,

I think the fact that law enforcement is afraid of NAT is my counter argument. But, it is true that NAT blends traffic such that all source addresses and ports convey little distinguishable information about the underlying source. And the properties of this blending can be quantified. I am saying that we should want a mechanism in IPv6 with similar properties but without NAT.

Tom

David Farmer

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Oct 2017 00:36:29 -0300

> It's beyond me why we care about link layer addresses in a network layer protocol in which the network layer addresses are not derived from link layer addresses.

Indeed. However, we don't care anymore: RFC8064, RFC7217.

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

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Oct 2017 00:52:25 -0300

(authors CC'ed)

> "If a host wishes to maintain privacy on such networks, it SHOULD ensure that its link-layer address is periodically changed or randomized.”

I think the text should be augmented.

If the node(s) to which the host is connecting is aware that each host
is being given given a whole prefix, then, as noted, RFC4941 is
nullified, and there's nothing you can do about it.

Changing the MAC address does matter for local eavesdroppers, but this
seems pretty orthogonal to this I-D, so one might even remove the
comment regarding MAC address randomization.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Oct 2017 01:00:56 -0300

> Shouldn’t we then do the same for the randomized link-layer address of this draft, too? That is, shouldn’t there be a collision detection procedure accompanied to the randomizing?

Maybe... but that looks like IEEE's arena...

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Oct 2017 01:12:10 -0300

> could very well be a matter of life and death for them.

At that point you'd most likely do things in a much different way
(including the option of destroying your host once you did what you had
to do).

There's so many things that leak out information on a host (browsers,
nodes scanning for wifi networks to which you had previously connected,
lots of protocol IDs in so many different layers), that if this is
really a "life or death" thing, you should be ding things in a very
different way.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 29 Oct 2017 13:40:28 +0900

On 29 Oct 2017 13:11, "Fernando Gont" <[email-masked]> wrote:

(authors CC'ed)

What are you talking about? Changing the MAC address allows the host to
change the prefix it is assigned, and thus disrupt IP address tracking by
third parties in a similar way to RFC 4941.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Oct 2017 01:48:30 -0300

On 10/28/2017 05:51 PM, Tom Herbert wrote:
> periodic address randomization to provide privacy. 

If you are aiming at privacy, then timing should also be random.
Otherwise, a new address that shows up can be correlated with the
previous ones.

> quantifiable, given any two connections, a third party cannot determine
> any significant correlation or identification based on the source addresses.

We have ongoing work on this topic:

*
<https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-03>

* <https://tools.ietf.org/html/draft-gont-6man-non-stable-iids-01>

> the form of NAT. It provides strong privacy properties as validated by
> law enforcement's concerns over it's use. In this sense it seems to be
> that privacy is stronger in IPv4 that IPv6 as being deployed today. I
> believe, to get IPv6 to the same level of privacy without resorting to
> NAT can be done by allocating sufficiently randomized host addresses and
> the system can enforce single use. I think this could work concurrently
> with prefix allocation, and would be used when user privacy is essential.

Indeed, a node need not be assigned a unique prefix for this. In fact,
multiple nodes employing a single prefix helps a bit in terms of privacy.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Oct 2017 02:06:32 -0300

On 10/29/2017 01:40 AM, Lorenzo Colitti wrote:
> On 29 Oct 2017 13:11, "Fernando Gont" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     (authors CC'ed)
> 
>     Considerations" of
>     https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13
>     <https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13>:
>     >
>     > "If a host wishes to maintain privacy on such networks, it SHOULD

> change the prefix it is assigned, and thus disrupt IP address tracking
> by third parties in a similar way to RFC 4941.

Can you please point me at how the prefix bits are generated? (algorithm)

Besides, there's some math to be done, and details to be provided: How
many bits do we expect that we are playing with? How many nodes on the
net? How often that the prefix change?  What happens with addresses from
a previous prefix (once you've changed the prefix)?  What if a prefix is
reassigned?

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Oct 2017 02:09:14 -0300

On 10/28/2017 09:24 PM, Lorenzo Colitti wrote:
> On 29 Oct 2017 05:51, "Tom Herbert" <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     The exception is the case of single use addresses, that is a
>     different source address per connection. In this case the privacy
>     properties are quantifiable, given any two connections, a third
>     party cannot determine any significant correlation or identification
>     based on the source addresses.
> 
> 
> But on the other hand single use IP addresses have an extremely
> dangerous weakness: if someone can compel or compromise the party
> handing out the /128s, then all IP address privacy for all user's on
> that network is gone.

I assume he meant autoconfigured, single use IPv6 addresses.

That said, the same thing is true for the case where the device handing
out the prefixes is compromised.

---

From: DY Kim <[email-masked]>
Date: Sun, 29 Oct 2017 19:09:06 +0900

Of course, anything related to link-layer is in the IETF purview and would belong to the IEEE’s area.

The thing is, however, that the current draft suggests a measure dependent on the link-layer and leave the details thereof unmentioned.

As for me, I would suggest a measure not dependent on the link-layer such that, every time a host reconnects, it would be assigned a new prefix that was not assigned to it before. That is, the prefix assignment by the operator should be sufficiently randomized to ensure that a host of a given link-layer address should not be given the same prefix. Such a method then won’t rely on the link-layer and we don’t have to leave the fate to the chances in the link-layer.

For that, the text might be rewritten like:

[current text]

“… If a host wishes to maintain privacy on such networks, it SHOULD ensure that its link-layer address is periodically changed or randomized.”

[proposed text]

“… To maintain host privacy, the unique prefix assignment by the operator should be sufficiently randomized so that the probability that a reconnecting host is assigned the same unique prefix as the one previously assigned to the same host within a timeframe of engineering interest is sufficiently low. Otherwise or at the same time, a host may reject a unique prefix assigned at reconnection if the prefix is the same as one previously assigned to the same host.”

---
DY

> On 29 Oct 2017, at 13:00, Fernando Gont <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Sun, 29 Oct 2017 19:13:41 +0900

typo:

> anything related to link-layer is NOT in the IETF purview

---
DY

> On 29 Oct 2017, at 19:09, DY Kim <[email-masked]> wrote:
> 
> anything related to link-layer is in the IETF purview

---

From: DY Kim <[email-masked]>
Date: Sun, 29 Oct 2017 19:16:52 +0900

Is that the only way?

Instead of forcing hosts to change the link-layer addresses, the operator may assign a different unique prefix every time the same host reconnects.

That is, instead of randomizing the link-layer address, we could randomized the assigned unique prefix.

---
DY

> On 29 Oct 2017, at 13:40, Lorenzo Colitti <[email-masked]> wrote:
> 
> What are you talking about? Changing the MAC address allows the host to change the prefix it is assigned, and thus disrupt IP address tracking by third parties in a similar way to RFC 4941.

---

From: Ca By <[email-masked]>
Date: Sun, 29 Oct 2017 15:26:42 +0000

> variants handled by a core infrastructure of that.

Careful. Let me remind you that on the other thread about traceability, i
strongly encouraged ipv6 for enhacing traceability for LEA.

You will not find a mobile network operator that is willing to sacrafice
traceability in any scenario

In the context of a mobile network operator, there is always logging of who
is assigned the source address.  Be this for LEA requirements or “big data
monetization”

I would avoid insinuating that anything in mobile core infrastructure with
regards to ip addressing will provide any type of privacy.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 29 Oct 2017 10:20:05 -0700

>> formalized yet (identifier-locator use implied to eliminate as much
topology
>> on address as possible). I could spin a draft specifically on one time
use
>> addresses and privacy (won't make cutoff though).
>>
>>
Yes, it should be expected that the source address and the user are logged
by the provider and provided to law enforcement as required (although it's
still not clear to me why the same effect isn't accomplished by logging NAT
mappings).

> regards to ip addressing will provide any type of privacy.

The question is what is being encoded in addresses that could enable
tracking by a potentially malicious third  party that doesn't have access
to the source addresses logs.

I already pointed out one scenario where an app is always connected an
reveals address to user identity that can be correlated to other flows with
same source address.

Another concern particular to mobile is if geo-location can be inferred
from the address. For instance, if a smartphone reconnected every time it
enters a new cell and the prefix routes  packets to the cell then location
of the device can be inferred with good accuracy (potentially enabling
stalkers).

There are also concerns about interception over the air. IIRC WAVE was
looking at address obfuscation for that.

Tom

---

From: Ca By <[email-masked]>
Date: Sun, 29 Oct 2017 17:45:57 +0000

> still not clear to me why the same effect isn't accomplished by logging NAT

1. Legacy

2.  NAT binding logging would be a new and unreasonable cost, while ipv6
prefix assignment is already captured in data bearer setup CDR.

3.  There situation for LEA traceability is improving with IPv6 so the
motivations on all sides is deploy ipv6 instead of invest in legacy ipv4
cgn

> to the source addresses logs.

Nothing is encoded in the IID today, you may get metro-area level
geolocation from the prefix, afaik

> of the device can be inferred with good accuracy (potentially enabling

Cell site are generally L2 only, prefixes are tied metro area aggregations
/ gateways, not towers

---

From: David Farmer <[email-masked]>
Date: Sun, 29 Oct 2017 12:58:38 -0500

> still not clear to me why the same effect isn't accomplished by logging NAT

Such logging is done for NAT mappings, both NAT44 and NAT64, but you need
source ports as well as source addresses to attribute traffic to a user
behind a NAT.  And as has been discussed in other threads servers
frequently don't log source port for connections, therefore in many cases
LEA don't have source ports with their reports of malicious activity

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 Oct 2017 03:36:43 +0900

On 29 Oct 2017 14:14, "Fernando Gont" <[email-masked]> wrote:

Surely that's out of scope for this discussion, since it's not something
that the host can control?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 Oct 2017 03:39:01 +0900

On 29 Oct 2017 19:09, "DY Kim" <[email-masked]> wrote:

“… To maintain host privacy, the unique prefix assignment by the operator
should be sufficiently randomized so that the probability that a
reconnecting host is assigned the same unique prefix as the one previously
assigned to the same host within a timeframe of engineering interest is
sufficiently low. Otherwise or at the same time, a host may reject a unique
prefix assigned at reconnection if the prefix is the same as one previously
assigned to the same host.”

Reject how? Send another RS and get the same prefix again?

What's wrong with the current text?

---

From: Tom Herbert <[email-masked]>
Date: Sun, 29 Oct 2017 14:14:13 -0700

On Sun, Oct 29, 2017 at 10:45 AM, Ca By <[email-masked]> wrote:
> motivations on all sides is deploy ipv6 instead of invest in legacy ipv4 cgn
>
All sides? I'm not sure that privacy advocates, including many in
IETF, will agree with that especially if improving LEA traceability
means improving non-LEA traceability as well.

Tom

---

From: DY Kim <[email-masked]>
Date: Mon, 30 Oct 2017 07:59:55 +0900

I’m suggesting to randomize the prefix instead of the link-layer address.

---
DY

> On 30 Oct 2017, at 03:39, Lorenzo Colitti <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Mon, 30 Oct 2017 08:26:56 +0900

My comments might be out of place since the WGLC for the draft is over and the text might be frozen by now.

---
DY

> On 30 Oct 2017, at 07:59, DY Kim <[email-masked]> wrote:
>

---

From: David Farmer <[email-masked]>
Date: Sun, 29 Oct 2017 18:51:06 -0500

The host can’t cause the prefix to be randomized, and the network can only randomize the prefix within the aggregate prefix it has been allocated, which is probably going to be a /48 or less in many situations.

As the text says if the network assigns the same prefix to a host every time the host connects to the network, the only thing in the control of the host that it can do is to randomize it’s MAC address. 

Now the network probably shouldn’t always assign the same prefix. However, there is no good way for a network to know if a host has intentionally disconnected or if there is some intermittent WiFi interference.  In the first case assigning a new prefix is a good idea, but in the second case assigning a new prefix would break any active connections, and is probably a bad idea.  The best a network can do is assign the same prefix if the host disconnects for something like 30 minutes or less, and assign a new prefix if the host disconnects for 30 minuets or more.  

Whereas the host’s user could have full control of when to randomize the MAC address, maybe as simple as turning off and on the WiFi interface.

I think the current text has the right balance on this issue.

> On Oct 29, 2017, at 17:59, DY Kim <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Mon, 30 Oct 2017 09:44:16 +0900

Got it. Thanks.

---
DY

> On 30 Oct 2017, at 08:51, David Farmer <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Oct 2017 00:54:55 -0300

On 10/29/2017 03:36 PM, Lorenzo Colitti wrote:
> On 29 Oct 2017 14:14, "Fernando Gont" <[email-masked]

*You* were the one assuming properties about the assigned prefix (e.g.,
that it changes if the MAC address of the host changes). Thus, unless
you specify how the prefix is generated, statements like "you need to
change the MAC address so that the prefix changes" is out place.

That said, responses to all my other questions are warranted
particularly if you expect the prefix that is assigned to each client to
change -- otherwise, what might seem to work, could actually totally break.

Note to the authors: I think the current document is fine describing why
the idea (one prefix per host) is interesting. But somewhere (whether
this or a companion document) should explore all those details.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 Oct 2017 13:06:32 +0900

> change the MAC address so that the prefix changes" is out place.

In this scheme, I don't see a way for the prefix *not* to change if the MAC
address changes. Do you?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Oct 2017 01:37:47 -0300

On 10/30/2017 01:06 AM, Lorenzo Colitti wrote:
> On Mon, Oct 30, 2017 at 12:54 PM, Fernando Gont <[email-masked]
>     > On 29 Oct 2017 14:14, "Fernando Gont" <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
> In this scheme, I don't see a way for the prefix *not* to change if the
> MAC address changes. Do you?

No algorithm has been specified for generating the prefix, so... how
could you possibly make such assertion?

One could easily come up with an algorithm that generates prefixes that
is not a function of the MAC address (including prefix=random()), or
others).

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 Oct 2017 16:30:41 +0900

> is not a function of the MAC address (including prefix=random()), or

Of course you can, but such a network does not contradict my statement at
all.

I still don't see a realistic way for the prefix *not* to change if the MAC
address changes.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Oct 2017 06:16:37 -0300

On 10/30/2017 04:30 AM, Lorenzo Colitti wrote:
> On Mon, Oct 30, 2017 at 1:37 PM, Fernando Gont <[email-masked]
>     No algorithm has been specified for gerefix bits nerating the prefix, so... how
> Of course you can, but such a network does not contradict my statement
> at all.
> 
> I still don't see a realistic way for the prefix *not* to change if the
> MAC address changes.

Given the history (draft-gont-numeric-ids-history) that we have on
numeric IDs generation -- and you can think of the prefix bits as a
numeric ID -- I wouldn't be surprised at all to see a flawed prefix
generation scheme that just doesn't give you what you might expect.

So, if you care about any specific property, such as the prefix changing
if the MAC address changes, be explicit about it, and make such property
a requirement.

Then, the other factors come into play (expected prefix length, number
of nodes, lifetimes, etc.), to at least be able to do some quick math
regarding when such a scheme might work well, and when we might be
hitting the limit.

How you deal with "prefix collisions" (request from two different nodes
result in the same prefix number) needs to be discussed, too.  -- not to
mention the case of "employ multicast at layer-2 while unicast at
layer-2", which in my experience can fail (e.g. broadcasted domain when
an interface is in promiscuous mode).

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 Oct 2017 19:20:35 +0900

> generation scheme that just doesn't give you what you might expect.

I still don't see an answer to my question.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Oct 2017 07:36:16 -0300

On 10/30/2017 07:20 AM, Lorenzo Colitti wrote:
> On Mon, Oct 30, 2017 at 6:16 PM, Fernando Gont <[email-masked]

How can you possible assume properties, and talk about properties of an
algorithm that has not been specified?

History (as in draft-gont-numeric-ids-history) gives you a realistic way
regarding why that would be possible.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 Oct 2017 21:46:19 +0900

I stand by my earlier statement: I still don't see a realistic way for the
prefix *not* to change if the MAC address changes.

If you disagree, how about providing counterexamples that do not meet the
above statement? Then we can all discuss about whether those
counterexamples are possible and/or realistic.

If we can't come up with realistic examples, then maybe they don't exist.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Oct 2017 09:54:31 -0400

> if the MAC address changes, be explicit about it, and make such property

I guess I have to admit that while I don't think the above is true, I think you are pointing to a legitimate problem with the document: it says "Unique IPv6 Prefix."    I think this implies that when you change the link-local address, you can't get the same prefix, because then it wouldn't be unique.   However, it doesn't say so explicitly; this may be the source of your confusion.   The document should explicitly say that the uniqueness of the prefix is assured by tying the prefix to the link-local address for the valid lifetime of the prefix.

I think the document is actually a bit vague in general, and I wish I'd given it a close review earlier.   One example of this vagueness is that the document seems to be saying that the router will spontaneously send RAs after the initial solicited RA, and even acknowledges that this is an open-ended process, but doesn't say how the router will decide to stop sending them.   This is a pretty major omission.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Oct 2017 12:44:48 -0300

On 10/30/2017 09:46 AM, Lorenzo Colitti wrote:
> I stand by my earlier statement: I still don't see a realistic way for
> the prefix *not* to change if the MAC address changes.

If you want to discuss an algorithm, specify the algorithm.

Because it is kind of the height of irony that, a a standards
organization, we left stuff unspecified, and then have a discussion
about what we think could happen, as if it was an esoteric topic.

> If you disagree, how about providing counterexamples that do not meet
> the above statement? Then we can all discuss about whether those

If you can't come up with a specification, then don't pretend you have
one, and that you have a protocol that has properties you didn't specify.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Oct 2017 12:53:37 -0300

On 10/30/2017 09:46 AM, Lorenzo Colitti wrote:
> On 30 Oct 2017 20:09, "Fernando Gont" <[email-masked]
>     >     >     No algorithm has been specified for gerefix bits
>     nerating the
>     >     prefix, so... how
>     >     >     could you possibly make such assertion?
>     >     >
>     >     >     One could easily come up with an algorithm that
>     generates prefixes that
>     >     >     is not a function of the MAC address (including
>     prefix=random()), or
>     >     >     others).
>     >     >
>     >     >
>     >     > Of course you can, but such a network does not contradict my
>     statement
>     >     > at all.
>     >     >
>     >     > I still don't see a realistic way for the prefix *not* to
>     change if the
>     >     > MAC address changes.
>     >

I stand by my earlier comments, but since you asked an example, and it
is simple:

Prefix_bits=Hash(src link-local-addr, secret)

The link-local address need not change if you change the MAC address
(the Net_Iface parameter in RFC7217 could be the interface *name*, such
that you can swap NICs without that affecting autoconfigured addresses).
And in this case, the prefix being "stable" is considered a feature.

As noted before, I don't know how many bits of "prefix" we're playing
with, how many nodes we're expecting, etc., so I can't tell how bad the
birthday paradox is going to hit us.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Oct 2017 12:57:04 -0300

On 10/30/2017 10:54 AM, Ted Lemon wrote:
> On Oct 30, 2017, at 5:16 AM, Fernando Gont <[email-masked]
> I guess I have to admit that while I don't think the above is true, I

If the prefix is supposed to be unpredictable -- which I would expect,
but nobody required --, then quite likely the prefix is going to change,
no matter whether you change the MAC address or not?

--- or... do folks expect prefixes to be stable-per-mac-address,
something ala-RFC7217?

> think you are pointing to a legitimate problem with the document: it
> says "Unique IPv6 Prefix."    I think this implies that when you change
> the link-local address, you can't get the same prefix, because then it
> wouldn't be unique.

It all depends on which basis the prefix is supposed to be unique. MAC
address? link-local address? Something else?

> However, it doesn't say so explicitly; this may be
> the source of your confusion. 

It is actually the source of my complaints ;-)

> The document should explicitly say that
> the uniqueness of the prefix is assured by tying the prefix to the
> link-local address for the valid lifetime of the prefix.

And here we go: if you do that, a change in the MAC address does not
necessarily imply a change in the link-local address (you are not
required to use the MAC address as the Net_Iface parameter in RFC7217).

> I think the document is actually a bit vague in general, and I wish I'd
> given it a close review earlier.   One example of this vagueness is that
> the document seems to be saying that the router will spontaneously send
> RAs after the initial solicited RA,

"Unicasted" per-pefix RAs? Does the router need to remember which
prefixes it has "handed"?

Thanks,

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 30 Oct 2017 15:55:52 +0000

There are two discussions:

1.       Whether to use link-local address for privacy? and

2.       What if the link-local address changes?

1.       The current draft version is focused on the use of the link-local address for privacy:

“If a host wishes to maintain privacy on
   such networks, it SHOULD ensure that its link-layer address is
   periodically changed or randomized.”
There are suggestions not to do this and rather randomize the prefix assigned by a router (or use some other mechanism). This needs to be sorted out.

2.       The draft does not talk about what a host should do if the link local address changes. Let’s assume the link-local address change is outside of the scope of this draft and is not related to the privacy.

Dusan

From: v6ops [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, October 30, 2017 9:55 AM
To: Fernando Gont
Cc: [email-masked] WG; [email-masked]
Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host

On Oct 30, 2017, at 5:16 AM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
So, if you care about any specific property, such as the prefix changing
if the MAC address changes, be explicit about it, and make such property
a requirement.

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Oct 2017 12:17:09 -0700

> MAC address changes. Do you?

Which reminds me, it's probably worth noting somewhere in an 
applicability statement that Multicast DNS Proxy Service [RFC 6762] is 
incompatible with this scheme, i.e., there is no way for a subscriber 
host to delegate a proxy for its MDNS responder to another subscriber.

This is probably viewed as a feature by the network operator, but it 
could be viewed as brokenness by ordinary subscribers.

--james

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 08:51:15 +0900

It’s not the ‘link-local’ address but the ‘link-layer’ address which is the focus of this thread discussion.

---
DY

> On 31 Oct 2017, at 00:55, Mudric, Dusan (Dusan) <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Oct 2017 20:44:06 -0400

> It’s not the ‘link-local’ address but the ‘link-layer’ address which is the focus of this thread discussion.

I can say from recent personal experience that it's really easy to say "link-layer" when you mean "link-local" so let us not hassle each other over this particular typo.   I think that Mudric's use of the term was consistent.   Also, varying the link-local address at the same time you vary the link-layer address is necessary to avoid tracking.

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 09:48:23 +0900

OK, if Dusan meant link-layer address…

I wish we had chosen a different terminology so that the two might not be confused in use…

---
DY

> On 31 Oct 2017, at 09:44, Ted Lemon <[email-masked]> wrote:
> 
> I can say from recent personal experience that it's really easy to say "link-layer" when you mean "link-local" so let us not hassle each other over this particular typo.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 10:37:09 +0900

> Prefix_bits=Hash(src link-local-addr, secret)

I don't think you can use this algorithm in a real network because it
cannot support hosts that send RAs from the unspecified address, which is
explicitly listed as a possibility by RFC 4861 section 6.3.7.

> And in this case, the prefix being "stable" is considered a feature.

While I don't consider this a valid counterexample for this purpose because
of the above, you make a good point that a client that desires privacy
should not use stable identifiers for RFC 7217 addresses.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 10:46:27 +0900

On Mon, Oct 30, 2017 at 10:54 PM, Ted Lemon <[email-masked]> wrote:

> think you are pointing to a legitimate problem with the document: it says
> "Unique IPv6 Prefix."    I think this implies that when you change the
> link-local address, you can't get the same prefix, because then it wouldn't
> be unique.   However, it doesn't say so explicitly; this may be the source
> of your confusion.   The document should explicitly say that the uniqueness
> of the prefix is assured by tying the prefix to the link-local address for
> the valid lifetime of the prefix.
>

It's not the link-local address, it's the link-layer address. But I think
the document implies this already, because it says the router has to send
RAs to the link-layer address of the subscriber.

> the document seems to be saying that the router will spontaneously send RAs
> after the initial solicited RA, and even acknowledges that this is an
> open-ended process, but doesn't say how the router will decide to stop
> sending them.   This is a pretty major omission.
>

This works well on networks that have an explicit signal from layer 2 that
a given host has disconnected. Wi-Fi is a good example of such a network,
and thus this method is widely applicable.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 10:49:05 +0900

> prefixes it has "handed"?

Sending RAs is documented very clearly in the draft:

   When the First Hop Router sends a solicited RA response, or
   periodically sends unsolicited RAs, the RA MUST be sent only to the
   subscriber that has been assigned the Unique IPv6 prefix contained in
   the RA.  This is achieved by sending a solicited RA response or
   unsolicited RAs to the all-nodes group, as detailed in RFC4861
   [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link-
   layer multicast address associated with the all-nodes group, the
   link-layer unicast address of the subscriber that has been assigned
   the Unique IPv6 prefix contained in the RA MUST be used as the link-
   layer destination RFC6085 [RFC6085].  Or, optionally in some cases,

but the router always needs to remember this information anyway, because
otherwise it doesn't know who to send packets to.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Oct 2017 21:56:06 -0400

On Oct 30, 2017, at 9:46 PM, Lorenzo Colitti <[email-masked]> wrote:
> This works well on networks that have an explicit signal from layer 2 that a given host has disconnected. Wi-Fi is a good example of such a network, and thus this method is widely applicable.

The document could mention that.   Ethernet is another such network medium; the only thing is that this requires that the router have knowledge of what's happening at the layer two where the host is connecting, which may or not actually be the case.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 11:00:18 +0900

Agreed. I think this could be done as a minimal addition to the first
paragraph of section 5. Not sure if it's possible to do that at this point
since the document is in AUTH48. If it is, care to suggest text?

On Tue, Oct 31, 2017 at 10:56 AM, Ted Lemon <[email-masked]> wrote:

> The document could mention that.   Ethernet is another such network
> medium; the only thing is that this requires that the router have knowledge
> of what's happening at the layer two where the host is connecting, which
> may or not actually be the case.
>
>

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 11:04:15 +0900

But, Fernando’s example should still be valid in that the Prefix doesn’t change even if the unspecified address should be used.

In order to reflect you comment on the unspecified address, Fernando’s algorithm could be rewritten like

 Prefix_bits=Hash(src link-local-addr or unspecified addresses, secret),

resulting in the unchanged unique prefix for the host on reconnection.

---
DY

> On 31 Oct 2017, at 10:37, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Tue, Oct 31, 2017 at 12:53 AM, Fernando Gont <[email-masked]> wrote:
> I don't think you can use this algorithm in a real network because it cannot support hosts that send RAs from the unspecified address, which is explicitly listed as a possibility by RFC 4861 section 6.3.7.

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 11:14:38 +0900

I’m afraid such is not necessarily implied in the draft. The draft says the RA should be sent to the link-layer address, but does not explicitly says that the prefix is changed when the link-layer address changes.

The draft is just silent about how the prefix is generated. The usual reader should interpret that the generation of the prefix and where to send the RA are rather independent. Like…

  o The prefix is generated with the information of the source address of the corresponding RS, that is either the link-local address of the originating host or the unspecified address

  o The prefix thus generated should then be sent to the link-layer address imbedded in the previous RS message.

With this, randomizing the link-layer address does not necessarily mean that the host acquires the new prefix different from the one assigned on a previous connection.

---
DY

> On 31 Oct 2017, at 10:46, Lorenzo Colitti <[email-masked]> wrote:
> 
> It's not the link-local address, it's the link-layer address. But I think the document implies this already, because it says the router has to send RAs to the link-layer address of the subscriber.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Oct 2017 22:17:36 -0400

On Oct 30, 2017, at 10:00 PM, Lorenzo Colitti <[email-masked]> wrote:
> Agreed. I think this could be done as a minimal addition to the first paragraph of section 5. Not sure if it's possible to do that at this point since the document is in AUTH48. If it is, care to suggest text?

Before I suggest text, maybe get signoff from your AD that this change is acceptable in AUTH48.   :)

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 11:17:25 +0900

On Tue, Oct 31, 2017 at 11:04 AM, DY Kim <[email-masked]> wrote:

> But, Fernando’s example should still be valid in that the Prefix doesn’t
> change even if the unspecified address should be used.
>

That doesn't work. if more than one host sends an RS from the unspecified
address, they will all be assigned the same prefix, and this scheme
completely stops working.

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 11:23:40 +0900

Then, the Fernando’s original algorithm should be correct.

Furthermore, the host should never use the unspecified address in sending out an RS to request for a prefix, in contrast to your reference to RFC 4861 section 6.3.7 or more generally sec. 4.3.

---
DY

> On 31 Oct 2017, at 11:17, Lorenzo Colitti <[email-masked]> wrote:
> 
> That doesn't work. if more than one host sends an RS from the unspecified address, they will all be assigned the same prefix, and this scheme completely stops working.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 11:42:07 +0900

That would not meet the document's goals. Specifically, one of the goals of
this scheme is "to ensure that the widest population of UE implementations
can leverage the availability of IPv6".

That goal cannot be met if we disallow RS from the unspecified address. RS
from the unspecified address has been allowed by the standards since RFC
1970, which was published more than 20 years ago. So there almost certainly
exist implementations that use it.

On Tue, Oct 31, 2017 at 11:23 AM, DY Kim <[email-masked]> wrote:

> Furthermore, the host should never use the unspecified address in sending
> out an RS to request for a prefix, in contrast to your reference to RFC
> 4861 section 6.3.7 or more generally sec. 4.3.
>
> ---
> DY
>
>
> > That doesn't work. if more than one host sends an RS from the
> unspecified address, they will all be assigned the same prefix, and this
> scheme completely stops working.
>
>

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 11:55:21 +0900

Then, what is the algorithm how the prefix is generated?

With the unspecified address, there’s not even the link-layer address in the RS:

 [Sec. 4.1 of RFC 4861]

 Valid Options:

      Source link-layer address
	The link-layer address of the sender, if known.  MUST NOT be included if the Source Address is the unspecified address.

With no source link-layer address available for the source unspecified address, how do you generate a unique prefix for the host?

In fact, you cannot return the prefix even if a prefix should be generated somehow, since there’s no link-layer address to send the prefix back through.

The only viable situation is the the source host sends a RS with the link-local address, wherein Fernando’s algorithm is valid.

Or do you mean that the prefix be generated randomly with no dependency on any information of the source host? That’s exactly what David Farmer discouraged; don’t rely on the operator for randomization, rather randomize the link-layer address by the host.

---
DY

> On 31 Oct 2017, at 11:42, Lorenzo Colitti <[email-masked]> wrote:
> 
> That would not meet the document's goals. Specifically, one of the goals of this scheme is "to ensure that the widest population of UE implementations can leverage the availability of IPv6".
> 
> That goal cannot be met if we disallow RS from the unspecified address. RS from the unspecified address has been allowed by the standards since RFC 1970, which was published more than 20 years ago. So there almost certainly exist implementations that use it.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 12:05:13 +0900

The network always has access to the link-layer address. It's in in the
link-layer header of all packets that the host transmits, including the RS.

On Tue, Oct 31, 2017 at 11:55 AM, DY Kim <[email-masked]> wrote:

>         The link-layer address of the sender, if known.  MUST NOT be
> included if the Source Address is the unspecified address.
>
> With no source link-layer address available for the source unspecified
> address, how do you generate a unique prefix for the host?
>
> In fact, you cannot return the prefix even if a prefix should be generated
> somehow, since there’s no link-layer address to send the prefix back
> through.
>
> The only viable situation is the the source host sends a RS with the
> link-local address, wherein Fernando’s algorithm is valid.
>
> Or do you mean that the prefix be generated randomly with no dependency on
> any information of the source host? That’s exactly what David Farmer
> discouraged; don’t rely on the operator for randomization, rather randomize
> the link-layer address by the host.
>
>
> ---
> DY
>
> > That would not meet the document's goals. Specifically, one of the goals
> of this scheme is "to ensure that the widest population of UE
> implementations can leverage the availability of IPv6".
> >
> > That goal cannot be met if we disallow RS from the unspecified address.
> RS from the unspecified address has been allowed by the standards since RFC
> > Furthermore, the host should never use the unspecified address in
> sending out an RS to request for a prefix, in contrast to your reference to
> RFC 4861 section 6.3.7 or more generally sec. 4.3.
> >
> > ---
> > DY
> >
> >
> > > But, Fernando’s example should still be valid in that the Prefix
> doesn’t change even if the unspecified address should be used.
> > >

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 12:18:21 +0900

Then, for the better, the draft should say explicitly that

 “the prefix is generated as a function of the link-layer address”

which should guarantee that the prefix changes when the link-layer address changes as you assert it’s ‘implied’.

BTW, I’m curious why RFC 4861 ever mentions the source link-layer address option if the router can always retrieve it as you say.

---
DY

> On 31 Oct 2017, at 12:05, Lorenzo Colitti <[email-masked]> wrote:
> 
> The network always has access to the link-layer address. It's in in the link-layer header of all packets that the host transmits, including the RS.

---

From: Erik Kline <[email-masked]>
Date: Tue, 31 Oct 2017 12:41:23 +0900

>  “the prefix is generated as a function of the link-layer address”

But that's not strictly required.  It just needs to be unique per
attached node.  It could be randomly assigned, for example, and not "a
function of the [node's] link-layer address".

---

From: DaeYoung KIM <[email-masked]>
Date: Tue, 31 Oct 2017 13:09:01 +0900

Even such a prefix randomization as you suggest is not explicitly stated in the draft.

With the current draft’s silence about the prefix generation specifics, there’s no way of preventing implementation s up to Fernando’ algorithm , for example, resulting in the same prefix for the same host at each reconnection.

Sent from my iPhone

> On 31 Oct 2017, at 12:41, Erik Kline <[email-masked]> wrote:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 14:47:36 +0900

There is one thing preventing networks from using Fernando's algorithm: it
doesn't work when hosts send the RS from the unspecified address.
Fernando's algorithm can't cause a privacy if it's not in use.

Also, there is something preventing Fernando's algorithm from becoming a
privacy problem: privacy-conscious hosts could decide that when they change
the link-layer address for privacy purposes they are *not* going to
maintain a stable link-local address. In which case again there is no
privacy problem.

Personally, I think it would be pretty silly for an implementation that
randomizes MAC addresses not to randomize IPv6 addresses as well.

On Tue, Oct 31, 2017 at 1:09 PM, DaeYoung KIM <[email-masked]> wrote:

> With the current draft’s silence about the prefix generation specifics,
> there’s no way of preventing implementation s up to Fernando’ algorithm ,
> for example, resulting in the same prefix for the same host at each
> reconnection.
>
> Sent from my iPhone
>

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 17:12:12 +0900

The interest was not in randomization of the IPv6 address by the host. The interest was in whether the prefix generated by the operator might change if the host’s link-layer address changes.

Your assertion was that there’s no way the prefix not change if the link-layer address changes.

The question then was what would be the algorithm used by the operator that ensures the change of the unique prefix to give out if the link-layer address of the RS-sending host changes.

You might want to say it’s OK that the draft is silent about that, to which Fernando (and possibly I) won’t agree.

A viable way to ensure the prefix change at link-layer address change might be that

  o the prefix is generated by the operation as a function of the link-layer address of the RS-sending host.

---
DY

> On 31 Oct 2017, at 14:47, Lorenzo Colitti <[email-masked]> wrote:
> 
> Personally, I think it would be pretty silly for an implementation that randomizes MAC addresses not to randomize IPv6 addresses as well.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 20:14:10 +0900

To be pedantic, every possible algorithm is a function of the link-layer
address of the host that sends the RS. That includes the infinite number of
algorithms that take the link-layer address as input and then ignore it. :-)

That said: the text you proposed is non-normative, so I don't see much
point in adding it. Are you saying you want the text to place additional
requirements on the operators, such as saying they SHOULD or MUST assign a
different prefix if the link layer address changes? I'm not sure if it's
feasible to add that sort of text any more now that this draft has reached
AUTH48.

On Tue, Oct 31, 2017 at 5:12 PM, DY Kim <[email-masked]> wrote:

> The interest was not in randomization of the IPv6 address by the host. The
> interest was in whether the prefix generated by the operator might change
> if the host’s link-layer address changes.
>
> The question then was what would be the algorithm used by the operator
> that ensures the change of the unique prefix to give out if the link-layer
> address of the RS-sending host changes.
>
> You might want to say it’s OK that the draft is silent about that, to
> which Fernando (and possibly I) won’t agree.
>
>   o the prefix is generated by the operation as a function of the
> link-layer address of the RS-sending host.
>
> ---
> DY
>

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 20:36:29 +0900

---
DY

> On 31 Oct 2017, at 20:14, Lorenzo Colitti <[email-masked]> wrote:
> 
> That said: the text you proposed is non-normative, so I don't see much point in adding it. Are you saying you want the text to place additional requirements on the operators, such as saying they SHOULD or MUST assign a different prefix if the link layer address changes? I'm not sure if it's feasible to add that sort of text any more now that this draft has reached AUTH48.

I’m not proposing to add the text, since, as you say, the text of the draft is frozen by now.

I’m just trying to say that Fernando has a point when he argues that the prefix generation algorithm should be explicitly stated in the draft in order to meet to your assumption/assertion that the prefix will also change if the link-layer address changes.

---

From: Erik Kline <[email-masked]>
Date: Tue, 31 Oct 2017 20:50:25 +0900

> I’m just trying to say that Fernando has a point when he argues that the prefix generation algorithm should be explicitly stated in the draft in order to meet to your assumption/assertion that the…

If the operator wanted to (re)assign the same prefix to a host based
on, say, IEEE 802.1x credentials regardless of MAC address would that
not be a reasonable mode of operation?  Without having given it much
thought it seems like something reasonable to me...

---

From: DY Kim <[email-masked]>
Date: Tue, 31 Oct 2017 21:00:12 +0900

The draft already recommends to randomize the link-layer address. If the prefix generation by the operator be based on that randomized link-layer address, the host will get a new (different from the one of the previous connection) prefix on a new connection.

However, the draft says nothing about the way the prefix should be generated. This leaves the concern that the host could possibly be assigned the same prefix at every reconnection regardless of the randomized link-layer address, which might possibly compromise the host’s privacy.

---
DY

> On 31 Oct 2017, at 20:50, Erik Kline <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Oct 2017 10:13:59 -0300

> function of the [node's] link-layer address".

If it is not required (which I agree with you), then one cannot make
assertions (as Lorenzo did).

Isn't it a bit ironic that we're an std organization, and rather than
specifying what we should be specifying, we just make assertions and
rely on assumptions?

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Oct 2017 10:20:04 -0300

On 10/30/2017 10:49 PM, Lorenzo Colitti wrote:
> On Tue, Oct 31, 2017 at 12:57 AM, Fernando Gont <[email-masked]

I have two questions:

1) Isn't this a protocol spec?

2) If a router needs to "remember" this... isn't this kind of stateful
slaac?

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Oct 2017 09:32:05 -0400

> 2) If a router needs to "remember" this... isn't this kind of stateful

Only on the router side.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Oct 2017 10:31:45 -0300

On 10/31/2017 02:47 AM, Lorenzo Colitti wrote:
> There is one thing preventing networks from using Fernando's algorithm:
> it doesn't work when hosts send the RS from the unspecified address.

Have you found a real world case where this happens?

> privacy problem: privacy-conscious hosts could decide that when they
> change the link-layer address for privacy purposes they are *not* going
> to maintain a stable link-local address. In which case again there is no
> privacy problem.

Well, if you don't want a stable address, you just don't configure a
stable address. draft-gont-6man-non-stable-addresses is about that.

> randomizes MAC addresses not to randomize IPv6 addresses as well.

What you want is the IPv6 address to e.g. be a function of the
link-layer address.

In that case, you could either use the mac adress as net_iface in
RFC7217, or you might opt not to configure stable addressses at all.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Oct 2017 10:33:06 -0300

On 10/30/2017 11:42 PM, Lorenzo Colitti wrote:
> RS from the unspecified address has been allowed by the standards since
> RFC 1970, which was published more than 20 years ago. So there almost
> certainly exist implementations that use it.

Please name the culprit, and send a pcap.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 23:01:26 +0900

> Have you found a real world case where this happens?

I don't think it matters. We can't publish a BCP that lists as a goal
"ensure the widest population of UE implementations can leverage the
availability of IPv6" and then say that said BCP doesn't work at all if a
host does something that is explicitly permitted in every version of the
standard since 1996.

> stable address. draft-gont-6man-non-stable-addresses is about that.

Right. The assertion was that your "use the hash of the link-local address
to determine the prefix" algorithm would create a privacy problem. My reply
was that it doesn't, because a privacy-conscious host can and should ensure
that it doesn't have a stable link-local address.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Oct 2017 11:20:33 -0300

On 10/31/2017 11:01 AM, Lorenzo Colitti wrote:
> On Tue, Oct 31, 2017 at 10:31 PM, Fernando Gont <[email-masked]
> availability of IPv6" 

Correction: this is a protocol spec. I am even curious why the protocol
part was doabl in v6ops.

> and then say that said BCP doesn't work at all if
> a host does something that is explicitly permitted in every version of
> the standard since 1996.

I love it. So in some cases, you ask for real world cases, but in others
you care about what's on paper. Great.

> Right. The assertion was that your "use the hash of the link-local
> address to determine the prefix" algorithm would create a privacy
> problem. My reply was that it doesn't, because a privacy-conscious host
> can and should ensure that it doesn't have a stable link-local address.

Then you should put that on a document. Because as far as I understand
the output of the IETF is documents, not what one participant thinks
that people should do about what we decided not to specify.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Oct 2017 11:22:45 -0300

On 10/31/2017 10:32 AM, Ted Lemon wrote:
> On Oct 31, 2017, at 9:20 AM, Fernando Gont <[email-masked]

So we have.. stateful DHCPv6, stateless DHCPv6, SLAAC, and SSLAAC
(Stateful Stateless Address Autoconfiguration, or SSLAAC).

The casual reader must be enjoying it, I guess :-)

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Oct 2017 11:26:21 -0300

> "ensure the widest population of UE implementations can leverage the

You might just as well say "Use DHCPv6-PD"...

---

From: Ole Troan <[email-masked]>
Date: Tue, 31 Oct 2017 15:47:47 +0100

The noise to signal ratio in this discussion is rapidly approaching zero.

Ole

> On 31 Oct 2017, at 15:26, Fernando Gont <[email-masked]> wrote:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 Oct 2017 23:49:34 +0900

> Please name the culprit, and send a pcap.

"Culprit" implies the implementation is doing something wrong, but it
isn't. Sending an RS from the unspecified address is entirely permissible
behaviour, and this BCP should not change that. Even if no implementation
does this today, implementations should be free to do it tomorrow without
causing the scheme described in this document to fail.

Here's a PCAP. The client implementation is one I wrote, the router is my
ISP-supplied home gateway. The MAC addresses and prefix are obfuscated in
the reply, but you'll see that the router is correctly to responding to the
RS, per spec.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Oct 2017 12:24:45 -0300

So now the router doing slaac is expected to sniff traffic. Wow..

On Tuesday, October 31, 2017, Lorenzo Colitti <[email-masked]> wrote:

> On Tue, Oct 31, 2017 at 11:55 AM, DY Kim <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> In fact, you cannot return the prefix even if a prefix should be
>> generated somehow, since there’s no link-layer address to send the prefix
>> back through.
>>
>> Or do you mean that the prefix be generated randomly with no dependency
>> on any information of the source host? That’s exactly what David Farmer
>> > On 31 Oct 2017, at 11:42, Lorenzo Colitti <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> >
>> > That would not meet the document's goals. Specifically, one of the
>> goals of this scheme is "to ensure that the widest population of UE
>> > On Tue, Oct 31, 2017 at 11:23 AM, DY Kim <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> > > On 31 Oct 2017, at 11:17, Lorenzo Colitti <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> > >
>> > > On Tue, Oct 31, 2017 at 11:04 AM, DY Kim <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> > > In order to reflect you comment on the unspecified address,
>> Fernando’s algorithm could be rewritten like
>> > >

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 31 Oct 2017 16:53:21 +0100

Zero: I agree to say "use DHCPv6-PD".

But I guess you meant infinity :-)

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 31 Oct 2017 16:56:44 +0100

Le 31/10/2017 à 15:49, Lorenzo Colitti a écrit :
> On Tue, Oct 31, 2017 at 10:33 PM, Fernando Gont <[email-masked] 
> isn't. Sending an RS from the unspecified address is entirely 
> permissible behaviour, and this BCP should not change that. Even if no 
> implementation does this today, implementations should be free to do it 
> tomorrow without causing the scheme described in this document to fail.
> 
> Here's a PCAP. The client implementation is one I wrote, the router is 
> my ISP-supplied home gateway. The MAC addresses and prefix are 
> obfuscated in the reply, but you'll see that the router is correctly to 
> responding to the RS, per spec.

I read the pcap, it parses.

The router does respond when it is requested, but the response is sent 
to many computers not just one (multicast).

It is possible to have a meaningful communication even though each 
computer sends messages to everybody.

Alex

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 31 Oct 2017 19:24:17 +0000

Correct, link-layer address

> From: DY Kim [mailto:[email-masked]]
> Sent: Monday, October 30, 2017 7:51 PM
> Cc: Ted Lemon; Fernando Gont; [email-masked] WG; draft-ietf-v6ops-unique-
> [email-masked]
> > There are suggestions not to do this and rather randomize the prefix assigned
> by a router (or use some other mechanism). This needs to be sorted out.
> >
> > 2.       The draft does not talk about what a host should do if the link local
> address changes. Let’s assume the link-local address change is outside of the
> scope of this draft and is not related to the privacy.

---

From: DY Kim <[email-masked]>
Date: Wed, 1 Nov 2017 08:57:20 +0900

In fact, this is where I got lost.

ND is expected to run in L3, and agnostic to L2 behaviors, isn’t it?

A packet will be delivered to you because it’s framed in L2 with the destination L2 address pointing to you. But, once the L2 unwraps the frame, only the (payload) L3 packet will be delivered up to L3; L3 normally gets no information about the L2 headers.

With this ‘textbook-level’ knowledge, Lorenzo’s comment fell surprising to me:

 "The network always has access to the link-layer address."

---
DY

> On 1 Nov 2017, at 00:24, Fernando Gont <[email-masked]> wrote:
>