Subject: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-12: (with DISCUSS)

From: Alissa Cooper <[email-masked]>
Date: Thu, 12 Oct 2017 06:53:46 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-v6ops-unique-ipv6-prefix-per-host-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I've put in a DISCUSS because I think the point I raise below warrants further
discussion, unless the WG already discussed it and concluded otherwise.

Section 7 says:

"However, when combining both IPv6 privacy extensions and a unique
   IPv6 Prefix per Host a reduced privacy experience for the subscriber
   is introduced, because a prefix may be associated with a subscriber,
   even when the subscriber implemented IPv6 privacy extensions RFC4941
   [RFC4941]."

If an operator assigns the same unique prefix to the same host every time the
host connects to the network, the unlinkability benefits of using IPv6 privacy
extensions are completely negated. It seems reasonable to me for this document
to normatively RECOMMEND that operators assign a different unique prefix to a
returning host for the purpose of limiting linkability to the lifetime of the
host's connection to the network. I'm sure there are exception cases where this
wouldn't make sense, and some examples of those could be given. But by default
this seems to me like a reasonable recommendation to mitigate the privacy risk
introduced by the unique prefix, while the attacks described in Section 1 would
also still be mitigated.

Did the WG discuss this?

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Oct 2017 16:31:39 +0200

Le 12/10/2017 à 15:53, Alissa Cooper a écrit :
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
> information about IESG DISCUSS and COMMENT positions.
> 
> 
DISCUSS:
>  I've put in a DISCUSS because I think the point I raise below
> warrants further discussion, unless the WG already discussed it and
> concluded otherwise.
> 
> Section 7 says:
> 
> If an operator assigns the same unique prefix to the same host every
> time the host connects to the network, the unlinkability benefits of
> using IPv6 privacy extensions are completely negated. It seems
> reasonable to me for this document to normatively RECOMMEND that
> operators assign a different unique prefix to a returning host for
> the purpose of limiting linkability to the lifetime of the host's
> connection to the network. I'm sure there are exception cases where
> this wouldn't make sense, and some examples of those could be given.
> But by default this seems to me like a reasonable recommendation to
> mitigate the privacy risk introduced by the unique prefix, while the
> attacks described in Section 1 would also still be mitigated.
> 
> Did the WG discuss this?

I am not sure what is the context in which this draft applies: cellular?
  Home?  WiFi Hotspot in public area?

In the cellular case, it is highly desirable that the cellular operator
delegates a prefix, and assigns another prefix, both of them being
constant.  Having the same addresses on the terminal is very helpful for
applications that may easily restart after short disconnection.  If
their addresses change at mobility events then apps may need to be
restarted by user intervention.

There is further detail.  In the cellular case there are more states
than just 'every time a host connects to the network' and there are
handovers too.  These are frequent events which currently do involve
some times changes in IP addresses; these changes are little desirable
from the application continuity standpoint.

Alex

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Oct 2017 01:08:56 +0900

On Thu, Oct 12, 2017 at 10:53 PM, Alissa Cooper <[email-masked]> wrote:

> extensions are completely negated.

They are only negated if the remote party knows that the prefix assignment
policy is static. Otherwise, at best the remote party can know that a
particular subnet is sparsely (and perhaps infrequently) populated.

It seems reasonable to me for this document to normatively RECOMMEND that
> operators assign a different unique prefix to a returning host

It seems to me that the privacy implications are the same as for a
residential network, where the prefix also identifies the user (or the
home). Do we currently normatively recommend that ISPs assign different
prefixes every time a home network reconnects? The downside of such a
recommendation is that it makes it harder for residential users to run
servers, access their network remotely, and survive brief network outages.
I'm not sure that's something we want, is it?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 12 Oct 2017 18:18:10 +0200

Agree.

Please don’t even think in suggesting non-persistent prefixes. If we go that way, privacy is also the same for employees of companies. So, are we also going to suggest that corporate prefixes are non-persistent?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Lorenzo Colitti <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 12 de octubre de 2017, 18:09
Para: Alissa Cooper <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>, The IESG <[email-masked]>, "[email-masked] WG" <[email-masked]>
Asunto: Re: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-12: (with DISCUSS)

    They are only negated if the remote party knows that the prefix assignment policy is static. Otherwise, at best the remote party can know that a particular subnet is sparsely (and perhaps infrequently) populated.

    It seems reasonable to me for this document to normatively RECOMMEND that operators assign a different unique prefix to a returning host

    It seems to me that the privacy implications are the same as for a residential network, where the prefix also identifies the user (or the home). Do we currently normatively recommend that ISPs assign different prefixes every time a home network reconnects? The downside of such a recommendation is that it makes it harder for residential users to run servers, access their network remotely, and survive brief network outages. I'm not sure that's something we want, is it?

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

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

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 Oct 2017 12:34:11 -0400

One consideration in this has to do with DNS. Let's imagine that some process within the host, and the address being used to reach it, has a name. We have RFC 3007, Secure Dynamic DNS Update, by which an addressed entity (used to be called a host, but in this context it's a process) can register a Resource Record for its name. That said, to my knowledge it is not widely used. If we assume, recommend, or require that any time a host is given a prefix it is given a different prefix than it was using at some point in the past, we are requiring a solution (perhaps that protocol; perhaps something else) that would update the DNS accordingly.

Chair hat off, I would see that as an open issue that is best left open. I believe that the service the authors discuss doesn't generally have named entities in it, but use of that type of service within a data center would probably require it, and we could provide advice in the future to operators with that requirement.

There is also the question of how different successive prefix assignments need to be (which might be a discussion of angels and pins). Let's imagine that a given ISP router has a given prefix of some length and out of it allocates prefixes to its downstream subscribers. It might have a /56 allocated to it, for example, and have 100 downstream devices. Is it sufficient for the prefix to be one of two in the indicated set, "one among the /64s in the /56", or "a random 64 bit number"? I can probably construct a privacy-theoretic response supporting each of those options, which from an operational perspective favors "one of two" or "one of 256", and from a privacy perspective favors "a 64 bit random number".

> On Oct 12, 2017, at 9:53 AM, Alissa Cooper <[email-masked]> wrote:
>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 12 Oct 2017 12:34:12 -0400

> On Oct 12, 2017, at 12:08 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Thu, Oct 12, 2017 at 10:53 PM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:

My assumption is that some remote parties can make a guess at this based on observation of other identifiers they gather that span across multiple instances of a device obtaining an address. And after gathering enough evidence, they can assume the prefix uniquely identifies the device even in the absence of those other identifiers.

> It seems to me that the privacy implications are the same as for a residential network, where the prefix also identifies the user (or the home). 

I was thinking that the difference is actually between user and home. I.e., users/devices that share a prefix within a home have some protection by virtue of sharing it; assigning a unique prefix per device negates that.

Alissa

> Do we currently normatively recommend that ISPs assign different prefixes every time a home network reconnects? The downside of such a recommendation is that it makes it harder for residential users to run servers, access their network remotely, and survive brief network outages. I'm not sure that's something we want, is it?

---

From: Tom Herbert <[email-masked]>
Date: Thu, 12 Oct 2017 09:39:04 -0700

On Thu, Oct 12, 2017 at 9:08 AM, Lorenzo Colitti <[email-masked]> wrote:

> Lorenzo,

There are multiple use cases to consider. Persistence is needed for servers
and remote access, but the opposite may be true if you want anonymity and
privacy. If one wishes to be anonymous on the Internet then likely would
want every connection to use a different source address. The source address
should be untraceable back the user, and given two such addresses it should
be impossible for a third party to draw any correlation between them other
than they belong to the same service provider. Basically, what you'd want
are addresses that only share a short provider prefix but all the rest of
the bits are seemingly random and not topological. This is one of the
things that identifier-locator can provide.

Tom

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 12 Oct 2017 18:40:04 +0200

[Jordi] For that, the remote host needs to “guess” if there are several devices in the same /64 or if multiple “access” from the same device is changing addresses in the same /64.
    
    Alissa

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 12 Oct 2017 18:50:25 +0200

If the prefix to a residential customer is NON-persistent (the ISP changes it every “x” minutes or hours or whatever), then I think there is no need to further extend the privacy measures to how each /64 is used during that time.

Otherwise we end-up demanding the same for every single /128 address …

According to my IPv6 survey, which has answers from 1512 ISPs worldwide, 63% provide “persistent” prefixes to residential users.

So, I believe is sufficient for an ISP to offer the choice for the user to “don’t have” a persistent prefix, or may depending on country laws, on the other way around.

Pushing to deploy IPv6 with NON-persistent prefixes is shooting our own foot, unless, as Fred mention, at the same time we provide a dynamic/secure DNS protocol that is widely implemented.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Tom Herbert <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 12 de octubre de 2017, 18:39
Para: Lorenzo Colitti <[email-masked]>
CC: "[email-masked] WG" <[email-masked]>, Alissa Cooper <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, The IESG <[email-masked]>
Asunto: Re: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-12: (with DISCUSS)

    

    

    Lorenzo,
    
    There are multiple use cases to consider. Persistence is needed for servers and remote access, but the opposite may be true if you want anonymity and privacy. If one wishes to be anonymous on the Internet then likely would want every connection to use a different source address. The source address should be untraceable back the user, and given two such addresses it should be impossible for a third party to draw any correlation between them other than they belong to the same service provider. Basically, what you'd want are addresses that only share a short provider prefix but all the rest of the bits are seemingly random and not topological. This is one of the things that identifier-locator can provide.
    
    Tom

---

From: Tom Herbert <[email-masked]>
Date: Thu, 12 Oct 2017 10:16:16 -0700

On Thu, Oct 12, 2017 at 9:50 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> If the prefix to a residential customer is NON-persistent (the ISP changes
> it every “x” minutes or hours or whatever), then I think there is no need
> to further extend the privacy measures to how each /64 is used during that
> time.
>
> Jordi,

How are you going to explain to a user that is exercising their right of
free speech to criticize their government that they need to carefully
schedule their private communications around some arbitrary time schedule
established by their provider (which is likely demanded by the very
government they are criticizing?).

IMO, if anonymity and privacy are rights on the Internet, which I'm
assuming they are, then those rights should be not be limited by some
window in time or other arbitrary constraints.

Tom

> According to my IPv6 survey, which has answers from 1512 ISPs worldwide,
> 63% provide “persistent” prefixes to residential users.
>
> So, I believe is sufficient for an ISP to offer the choice for the user to
> “don’t have” a persistent prefix, or may depending on country laws, on the
> other way around.
>
> Pushing to deploy IPv6 with NON-persistent prefixes is shooting our own
> foot, unless, as Fred mention, at the same time we provide a dynamic/secure
> DNS protocol that is widely implemented.
>
> Regards,
> Jordi
>
>
> CC: "[email-masked] WG" <[email-masked]>, Alissa Cooper <[email-masked]>,
> <[email-masked]>, <
> [email-masked]>, <
> [email-masked]>, The IESG <[email-masked]>
> Asunto: Re: [v6ops] Alissa Cooper's Discuss on
> draft-ietf-v6ops-unique-ipv6-prefix-per-host-12: (with DISCUSS)
>
>
>
> time the
>     They are only negated if the remote party knows that the prefix
> assignment policy is static. Otherwise, at best the remote party can know
> that a particular subnet is sparsely (and perhaps infrequently) populated.
>
>
>     It seems reasonable to me for this document to normatively RECOMMEND
> that operators assign a different unique prefix to a returning host
>
>
>     There are multiple use cases to consider. Persistence is needed for
> servers and remote access, but the opposite may be true if you want
> anonymity and privacy. If one wishes to be anonymous on the Internet then
> likely would want every connection to use a different source address. The
> source address should be untraceable back the user, and given two such
> addresses it should be impossible for a third party to draw any correlation
> between them other than they belong to the same service provider.
> Basically, what you'd want are addresses that only share a short provider
> prefix but all the rest of the bits are seemingly random and not
> topological. This is one of the things that identifier-locator can provide.
>
>     Tom
>
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Oct 2017 13:25:00 -0400

On Oct 12, 2017, at 1:16 PM, Tom Herbert <[email-masked]> wrote:
> How are you going to explain to a user that is exercising their right of free speech to criticize their government that they need to carefully schedule their private communications around some arbitrary time schedule established by their provider (which is likely demanded by the very government they are criticizing?).

More to the point, does that actually help?   If you really want your network access to be anonymous, source address randomization doesn't even come close to doing it.   Source address randomization is a tool that somewhat reduces the attack surface for violating end users' privacy, but it by no means fully protects them.   What would protect them would be requests coming from completely different addresses, with as few high-order bits matching as possible.

So the test here needs to be, does this make things worse?

In point of fact, the mechanism described in the document uses the host link-layer address as a unique identifier.   So a host that wants a variable prefix just needs to use a different link-layer address for router solicitation from time to time.   This can be done transparently, and indeed in principle the host can acquire two prefixes, one long-lived and one short-lived.   Of course, this is likely problematic, but you get the idea: the association of the prefix to a particular host is entirely within the control of that host.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 14 Oct 2017 14:26:50 +0900

On Fri, Oct 13, 2017 at 2:25 AM, Ted Lemon <[email-masked]> wrote:

> In point of fact, the mechanism described in the document uses the host
> link-layer address as a unique identifier.   So a host that wants a
> variable prefix just needs to use a different link-layer address for router
> solicitation from time to time.   This can be done transparently, and
> indeed in principle the host can acquire two prefixes, one long-lived and
> one short-lived.   Of course, this is likely problematic, but you get the
> idea: the association of the prefix to a particular host is entirely within
> the control of that host.
>

That's a great way to solve this problem, Ted. How about the following text?

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]. If a host
wishes to maintain privacy on such networks, it SHOULD ensure that its
link-layer address is periodically changed or randomized.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 14 Oct 2017 12:00:14 +0200

Le 12/10/2017 à 19:16, Tom Herbert a écrit :
> 
> 
> On Thu, Oct 12, 2017 at 9:50 AM, JORDI PALET MARTINEZ 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     If the prefix to a residential customer is NON-persistent (the ISP
>     changes it every “x” minutes or hours or whatever), then I think
>     there is no need to further extend the privacy measures to how each
>     /64 is used during that time.
> 
> Jordi,
> 
> schedule their private communications around some arbitrary time 
> schedule established by their provider (which is likely demanded by the 
> very government they are criticizing?).

Maybe the user exercising these rights can have an ability to impose her 
own schedule to the network, and not vice-versa.

Alex

>     According to my IPv6 survey, which has answers from 1512 ISPs
>     worldwide, 63% provide “persistent” prefixes to residential users.
> 
>     So, I believe is sufficient for an ISP to offer the choice for the
>     user to “don’t have” a persistent prefix, or may depending on
>     country laws, on the other way around.
> 
>     Pushing to deploy IPv6 with NON-persistent prefixes is shooting our
>     own foot, unless, as Fred mention, at the same time we provide a
>     dynamic/secure DNS protocol that is widely implemented.
> 
>     Regards,
>     Jordi
> 
> 
>     De: v6ops <[email-masked] <mailto:[email-masked]>>
>     en nombre de Tom Herbert <[email-masked]
>     <mailto:[email-masked]>>
>     Responder a: <[email-masked] <mailto:[email-masked]>>
>     Para: Lorenzo Colitti <[email-masked] <mailto:[email-masked]>>
>     CC: "[email-masked] <mailto:[email-masked]> WG" <[email-masked]
>     <mailto:[email-masked]>>, Alissa Cooper <[email-masked]
>     <mailto:[email-masked]>>,
>     <[email-masked]
>     <mailto:[email-masked]>>,
>     <[email-masked]
>     <mailto:[email-masked]>>,
>     <[email-masked] <mailto:[email-masked]>>, The IESG
>     <[email-masked] <mailto:[email-masked]>>
>          On Thu, Oct 12, 2017 at 9:08 AM, Lorenzo Colitti
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>          On Thu, Oct 12, 2017 at 10:53 PM, Alissa Cooper
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     assignment policy is static. Otherwise, at best the remote party can
>     know that a particular subnet is sparsely (and perhaps infrequently)
>     populated.
> 
> 
>          It seems reasonable to me for this document to normatively
>     RECOMMEND that operators assign a different unique prefix to a
>     returning host
> 
> 
>          It seems to me that the privacy implications are the same as
>     for a residential network, where the prefix also identifies the user
>     (or the home). Do we currently normatively recommend that ISPs
>     assign different prefixes every time a home network reconnects? The
>     downside of such a recommendation is that it makes it harder for
>     residential users to run servers, access their network remotely, and
>     survive brief network outages. I'm not sure that's something we
>     want, is it?
> 
> 
> 
> 
> 
> 
>          Lorenzo,
> 
>          There are multiple use cases to consider. Persistence is needed
>     for servers and remote access, but the opposite may be true if you
>     want anonymity and privacy. If one wishes to be anonymous on the
>     Internet then likely would want every connection to use a different
>     source address. The source address should be untraceable back the
>     user, and given two such addresses it should be impossible for a
>     third party to draw any correlation between them other than they
>     belong to the same service provider. Basically, what you'd want are
>     addresses that only share a short provider prefix but all the rest
>     of the bits are seemingly random and not topological. This is one of
>     the things that identifier-locator can provide.
> 
>          Tom
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> 
> 
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> 
> 
>     This electronic message contains information which may be privileged
>     or confidential. The information is intended to be for the exclusive
>     use of the individual(s) named above and further non-explicilty
>     authorized disclosure, copying, distribution or use of the contents
>     of this information, even if partially, including attached files, is
>     strictly prohibited and will be considered a criminal offense. If
>     you are not the intended recipient be aware that any disclosure,
>     copying, distribution or use of the contents of this information,
>     even if partially, including attached files, is strictly prohibited,
>     will be considered a criminal offense, so you must reply to the
>     original sender to inform about this communication and delete it.
> 
> 
> 
> 
> 
>

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 16 Oct 2017 07:50:34 +0000

Lorenzo, This text seems indeed as a reasonable suggestion to ensure that the host has a method to ensure its privacy if desired which is mainly under its own control.

G/

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Saturday, October 14, 2017 07:27
To: Ted Lemon <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked] WG <[email-masked]>; Alissa Cooper <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>
Subject: Re: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-12: (with DISCUSS)

On Fri, Oct 13, 2017 at 2:25 AM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
In point of fact, the mechanism described in the document uses the host link-layer address as a unique identifier.   So a host that wants a variable prefix just needs to use a different link-layer address for router solicitation from time to time.   This can be done transparently, and indeed in principle the host can acquire two prefixes, one long-lived and one short-lived.   Of course, this is likely problematic, but you get the idea: the association of the prefix to a particular host is entirely within the control of that host.

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]. If a host wishes to maintain privacy on such networks, it SHOULD ensure that its link-layer address is periodically changed or randomized.

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 16 Oct 2017 07:04:05 -0400

> On Oct 16, 2017, at 3:50 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 

+1
Alissa

---

From: Warren Kumari <[email-masked]>
Date: Mon, 16 Oct 2017 09:45:31 -0700

On Mon, Oct 16, 2017 at 4:04 AM, Alissa Cooper <[email-masked]> wrote:
> Lorenzo, This text seems indeed as a reasonable suggestion to ensure that
> the host has a method to ensure its privacy if desired which is mainly under
> its own control.
>
>
> +1
> Alissa

Thank you Alissa.
W

> Cc: Tom Herbert <[email-masked]>; [email-masked] WG <[email-masked]>;
> Alissa Cooper <[email-masked]>;
> [email-masked];
> [email-masked];
> [email-masked]; The IESG <[email-masked]>
> Subject: Re: [v6ops] Alissa Cooper's Discuss on
> link-layer address as a unique identifier.   So a host that wants a variable
> prefix just needs to use a different link-layer address for router
> solicitation from time to time.   This can be done transparently, and indeed
> in principle the host can acquire two prefixes, one long-lived and one
> short-lived.   Of course, this is likely problematic, but you get the idea:
> the association of the prefix to a particular host is entirely within the
> control of that host.
>
>
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf