Subject: RFC4941bis: consequences of many addresses for the network

From: [email-masked]
Date: Thu, 23 Jan 2020 09:59:17 +0100

While reviewing RFC4941bis (https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis) I think I found one gap.

A discussion of the consequences of a host having many (active) addresses on the network.

A 4941bis implementation following the defaults, would at the maximum use 8 active addresses.
(Valid lifetime of one week and one new address per day.)

Shorter regeneration intervals or other approaches like a new address per connection could lead to dramatic numbers.

If we use Ethernet as an example, each new address requires state in the network. In the ND cache in first-hop routers, and in SAVI binding tables in bridges. Given ND's security properties these tables must be policed by the network. A host with a very liberal address regeneration policy might be viewed as performing an attack.

There is no signal available in SLAAC apart from DAD to reject an address. If the network runs out of resources (or prohibits the additional address by policy) the address will not be served. The host has to be deal with that situation.

SLAAC is also missing a mechanism to release an address. Which leads me to think that the address regeneration interval must not be shorter than the ND cache scavenger timeout (which in many networks is high to avoid cache churn and high level of address re-resolutions).

I would like to hear from other network-side implementors and operators.
Is there an issue here?

Best regards,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jan 2020 10:26:34 +0000

Hello Ole

There are a number of cases where the address creates a state in the network:
- in case there's routing taking place within the subnet (e.g., RPL in the an IOT LLN and RIFT or eVPN in a data center)
- in case the network protects the address ownership since ND doesn't (SEND being what it is) and does minimal SAVI
- in case the network tries to implement ND proxy which is mandated by IEEE std 802.11
- in case Jen's draft is used to proactively assign ND state in the routers

In order to protect itself, the network blocks excessive amounts of addresses for a same device. It would serve this list to recognize it as a fact of life.

Sadly it is very hard with IPv6 ND alone to decide which address(es) to keep and which to remove. For the temporary addresses, LRU seems to work most of the time, with  a reasonable count of like 8 as suggested below. But some nodes like printers (silently) keep a permanent addresses that should survive the churn of other temporary addresses.

To serve the hosts correctly, the network is missing a classical but so useful information of lifetime that allows the state associated to the address to age out if not renewed. It is also classical in many IPv6-based standards (e.g., MIPv6, NEMO and RPL) that the nodes have  a chance to release a binding by indicating a lifetime of zero. The shortest path to get that is generalizing RFC 8505 to all MAC layers. *Is there any reason we do not?*

Conversely the network cannot signal how many addresses per node will be served properly in parallel. It cannot recommend lifetime values for temporary addresses and quasi-permanent addresses. It cannot signal that it rebooted and that all state need to be rebuilt. We need new RA information for that. I can write the draft within a few days if the group is willing to progress the work.

All the best,

Pascal

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of [email-masked]
> Sent: jeudi 23 janvier 2020 09:59
> To: 6man WG <[email-masked]>
> Subject: RFC4941bis: consequences of many addresses for the network
> 
> Shorter regeneration intervals or other approaches like a new address per
> connection could lead to dramatic numbers.
> 
> If we use Ethernet as an example, each new address requires state in the
> network. In the ND cache in first-hop routers, and in SAVI binding tables in
> bridges. Given ND's security properties these tables must be policed by the
> network. A host with a very liberal address regeneration policy might be
> viewed as performing an attack.
> 
> There is no signal available in SLAAC apart from DAD to reject an address. If
> the network runs out of resources (or prohibits the additional address by
> policy) the address will not be served. The host has to be deal with that
> situation.
> 
> SLAAC is also missing a mechanism to release an address. Which leads me to
> think that the address regeneration interval must not be shorter than the ND
> cache scavenger timeout (which in many networks is high to avoid cache churn
> and high level of address re-resolutions).
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 23 Jan 2020 17:38:36 +0530

Hello,

Some time back a draft was submitted to tackle some of these problems in
SLAAC.

https://tools.ietf.org/html/draft-naveen-slaac-prefix-management-00

If WG is okay, we can enhance the draft to tackle more cases.

Yours,
Naveen.

On Thu, 23 Jan 2020 at 15:57, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> - in case there's routing taking place within the subnet (e.g., RPL in the
> an IOT LLN and RIFT or eVPN in a data center)
> - in case the network protects the address ownership since ND doesn't
> (SEND being what it is) and does minimal SAVI
> In order to protect itself, the network blocks excessive amounts of
> addresses for a same device. It would serve this list to recognize it as a
> fact of life.
>
> Sadly it is very hard with IPv6 ND alone to decide which address(es) to
> keep and which to remove. For the temporary addresses, LRU seems to work
> most of the time, with  a reasonable count of like 8 as suggested below.
> But some nodes like printers (silently) keep a permanent addresses that
> should survive the churn of other temporary addresses.
>
> To serve the hosts correctly, the network is missing a classical but so
> useful information of lifetime that allows the state associated to the
> address to age out if not renewed. It is also classical in many IPv6-based
> standards (e.g., MIPv6, NEMO and RPL) that the nodes have  a chance to
> release a binding by indicating a lifetime of zero. The shortest path to
> get that is generalizing RFC 8505 to all MAC layers. *Is there any reason
> we do not?*
>
> Conversely the network cannot signal how many addresses per node will be
> served properly in parallel. It cannot recommend lifetime values for
> temporary addresses and quasi-permanent addresses. It cannot signal that it
> rebooted and that all state need to be rebuilt. We need new RA information
> for that. I can write the draft within a few days if the group is willing
> to progress the work.
>
> All the best,
>
> Pascal
>
> > A discussion of the consequences of a host having many (active)
> addresses on
> > the network.
> >

---

From: [email-masked]
Date: Thu, 23 Jan 2020 13:16:16 +0100

Pascal,

All good points!
Before this diverge too far though, can we try to focus on RFC4941bis text.
Is there anything that document can say or should say to alleviate some of these issues?
Does temporary addresses add to the more general problem that SLAAC has?

Cheers,
Ole

> On 23 Jan 2020, at 11:26, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Ole
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 23 Jan 2020 13:32:59 +0000

> On 23 Jan 2020, at 12:16, [email-masked] wrote:
> 
> Pascal,
> 
> All good points!

The problem statement section in 4941bis is all about user privacy, no mention of operational / management complexity, or other “general problems” that SLAAC has.  It seems there are unstated problems here :)

Tim

---

From: Jared Mauch <[email-masked]>
Date: Thu, 23 Jan 2020 08:37:19 -0500

> On Jan 23, 2020, at 8:32 AM, Tim Chown <[email-masked]> wrote:
> 

I would +1 this here.

I would also generally question if rotating IPs is a adequate privacy protector considering there are other ways to identify users that are being (broadly) employed today.

The complexity that this introduces into networks for operational debugging (provider: what’s your IP address so I can debug? User: Well here’s the 20 on the host because I have limited lifetime privacy addresses, and I don’t know what outbound one it’s using for this connection.  Provider: What’s your IP address so I can debug?  Actually, can you just turn off v6 so I can debug your problem?  User: sure, I just want it fixed).

- Jared

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 23 Jan 2020 14:46:58 +0100

Even not just debugging, but the operational complexity when in some scenarios, certain apps need to "audit" which user did what. Using DHCPv6 is not an option, because Android doesn't support it ... and I will not recommend a customer to use "manual IPv6 configuration" :-(

El 23/1/20 14:37, "ipv6 en nombre de Jared Mauch" <[email-masked] en nombre de [email-masked]> escribió:

    I would +1 this here.

    
    - Jared

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2020 10:57:37 -0300

Hello, Ole,

On 23/1/20 05:59, [email-masked] wrote:
> While reviewing RFC4941bis
> (https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis) I think I
> found one gap.
> 
> addresses on the network.
> 
> A 4941bis implementation following the defaults, would at the maximum
> use 8 active addresses. (Valid lifetime of one week and one new
> address per day.)
> 
> Shorter regeneration intervals or other approaches like a new address
> per connection could lead to dramatic numbers.

I guess we could add a small note to e.g. Section 4, along
the lines of:

"Use of an extremely large number of IPv6 addresses (as would result if
an implementation were to override TEMP_PREFERRED_LIFETIME with a much
shorter value) may have negative implications on some network devices,
and/or may lead to traffic from the offending addresses being policed by
devices enforcing port security (e.g. SAVI [REF]). A discussion on
possible approaches to allow for unconstrained use of IPv6 addresses can
be found in [RFC7934]"

Note: RFC7934 is *Very* relevant to this discussion.

> If we use Ethernet as an example, each new address requires state in
> the network. In the ND cache in first-hop routers, and in SAVI
> binding tables in bridges. Given ND's security properties these
> tables must be policed by the network. A host with a very liberal
> address regeneration policy might be viewed as performing an attack.

That's true, indeed. But isn't that sort of a design principle of SLAAC? 
-- i.e., kind of "anarchy" when it comes to host configuration?

SAVI with SLAAC is essentially telling nodes "do what you please", and 
then punishing nodes when they don't do what you *expect* or *wished*.

> SLAAC is also missing a mechanism to release an address. Which leads
> me to think that the address regeneration interval must not be
> shorter than the ND cache scavenger timeout (which in many networks
> is high to avoid cache churn and high level of address
> re-resolutions).

Which probably begs the question as why we don't make DHCPv6 mandatory, 
and add fill the necessary gaps there, so that a network that is to be 
operated as a managed network can apply policy to hosts, as needed. 
(yes, I did mean what I've just said :-) )

Put another way: SLAAC doesn't enforce any sort of policy on the 
network. Even attempts to *suggest* policy (e.g. 
draft-gont-6man-managing-slaac-policy) were shot down.

We also published draft-gont-6man-address-usage-recommendations to 
discuss the topic in a more general way. The suggestion was to take it 
to TAPS, where it somehow vanished.

So my personal conclusion is that one could certainly add a note like 
the one I suggested above. But other than that, I think further 
discussion of the topic belongs to a different document. -- We could 
revive draft-gont-6man-address-usage-recommendations if desired. -- in 
fact, it's kind of a shame that there hasn't been further work in that area.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 23 Jan 2020 15:06:07 +0100

Le 23/01/2020 à 14:32, Tim Chown a écrit :
>> All good points! Before this diverge too far though, can we try to
>> focus on RFC4941bis text. Is there anything that document can say
>> or should say to alleviate some of these issues? Does temporary
>> addresses add to the more general problem that SLAAC has?
> 
> The problem statement section in 4941bis is all about user privacy,
> no mention of operational / management complexity, or other “general
> problems” that SLAAC has.  It seems there are unstated problems here
> :)

Within "general [SLAAC] problems" I also think about "Permission-less 
extensions of the network with new links (and by implications new 
routers) are not supported."

Last December, we heard half-joking topics.  A further half of that half
might be related to SLAAC:

>>   - 64 bit boundary
>>   - M/O bits
>>   - ULA or not ULA
>>   - Extension headers
>>   - Defining new mechanisms for IID formats

Alex
>> Cheers, Ole
>>> There are a number of cases where the address creates a state in
>>> the network: - in case there's routing taking place within the
>>> subnet (e.g., RPL in the an IOT LLN and RIFT or eVPN in a data
>>> center) - in case the network protects the address ownership
>>> since ND doesn't (SEND being what it is) and does minimal SAVI -
>>> in case the network tries to implement ND proxy which is mandated
>>> by IEEE std 802.11 - in case Jen's draft is used to proactively
>>> assign ND state in the routers
>>> 
>>> In order to protect itself, the network blocks excessive amounts
>>> of addresses for a same device. It would serve this list to
>>> recognize it as a fact of life.
>>> 
>>> Sadly it is very hard with IPv6 ND alone to decide which
>>> address(es) to keep and which to remove. For the temporary
>>> addresses, LRU seems to work most of the time, with  a reasonable
>>> count of like 8 as suggested below. But some nodes like printers
>>> (silently) keep a permanent addresses that should survive the
>>> churn of other temporary addresses.
>>> 
>>> To serve the hosts correctly, the network is missing a classical
>>> but so useful information of lifetime that allows the state
>>> associated to the address to age out if not renewed. It is also
>>> classical in many IPv6-based standards (e.g., MIPv6, NEMO and
>>> RPL) that the nodes have  a chance to release a binding by
>>> indicating a lifetime of zero. The shortest path to get that is
>>> generalizing RFC 8505 to all MAC layers. *Is there any reason we
>>> do not?*
>>> 
>>> Conversely the network cannot signal how many addresses per node
>>> will be served properly in parallel. It cannot recommend lifetime
>>> values for temporary addresses and quasi-permanent addresses. It
>>> cannot signal that it rebooted and that all state need to be
>>> rebuilt. We need new RA information for that. I can write the
>>> draft within a few days if the group is willing to progress the
>>> work.
>>> 
>>> All the best,
>>> 
>>> Pascal
>>> 
>>>> -----Original Message----- From: ipv6 <[email-masked]>
>>>> On Behalf Of [email-masked] Sent: jeudi 23 janvier 2020
>>>> 09:59 To: 6man WG <[email-masked]> Subject: RFC4941bis:
>>>> consequences of many addresses for the network
>>>> 
>>>> (https://tools.ietf.org/html/draft-ietf-6man- rfc4941bis) I
>>>> think I found one gap.
>>>> 
>>>> A 4941bis implementation following the defaults, would at the
>>>> maximum use 8 active addresses. (Valid lifetime of one week and
>>>> one new address per day.)
>>>> 
>>>> Shorter regeneration intervals or other approaches like a new
>>>> address per connection could lead to dramatic numbers.
>>>> 
>>>> If we use Ethernet as an example, each new address requires
>>>> state in the network. In the ND cache in first-hop routers, and
>>>> in SAVI binding tables in bridges. Given ND's security
>>>> properties these tables must be policed by the network. A host
>>>> with a very liberal address regeneration policy might be viewed
>>>> as performing an attack.
>>>> 
>>>> There is no signal available in SLAAC apart from DAD to reject
>>>> an address. If the network runs out of resources (or prohibits
>>>> the additional address by policy) the address will not be
>>>> served. The host has to be deal with that situation.
>>>> 
>>>> SLAAC is also missing a mechanism to release an address. Which
>>>> leads me to think that the address regeneration interval must
>>>> not be shorter than the ND cache scavenger timeout (which in
>>>> many networks is high to avoid cache churn and high level of
>>>> address re-resolutions).
>>>> 
>>>> I would like to hear from other network-side implementors and
>>>> operators. Is there an issue here?
>>>> 
>>>> Best regards, Ole
>>>> 
>>>> [email-masked] Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6 
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2020 11:08:15 -0300

> The complexity that this introduces into networks for operational debugging (provider: what’s your IP address so I can debug? User: Well here’s the 20 on the host because I have limited lifetime pr…

FWIW, rfc4941bis is a revision of RFC4941, to address existing 
flaws/shortcomings. -- i.e., we're *not* introducing temporary addresses.

As noted, there are networks that wouldn't fancy temporary addresses, 
but then:

* SLAAC is not about managed configuration, but more about anarchy
   in this respect (for better or worse)

* We have a BCP supporting the use of multiple addresses: RFC7934

* Attempts to suggest policy in slaac have been shot down
  (draft-gont-6man-managing-slaac-policy)

* DHCPv6 support is not required, and in fact we seem to do our best to
   trash DHCPv6 and borrow cool DHCPv6 features into slaac as much as
   possible -- which doesn't help the situation.

So... while I sympathize with what you describe (for instance, I was an 
author of draft-gont-6man-managing-slaac-policy), I think what you're 
arguing has more to do with slaac itself, than with rfc4931.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2020 11:10:29 -0300

On 23/1/20 10:46, JORDI PALET MARTINEZ wrote:
> Even not just debugging, but the operational complexity when in some
> scenarios, certain apps need to "audit" which user did what. Using
> DHCPv6 is not an option, because Android doesn't support it ... and I
> will not recommend a customer to use "manual IPv6 configuration" :-(

To the occasional reader or lurker, this might read as IPv6 folks 
arguing that, after all, having too many addresses wasn't much of a good 
idea (?) :-)

Thanks,

---

From: [email-masked]
Date: Thu, 23 Jan 2020 15:11:31 +0100

Fernando,

> Note: RFC7934 is *Very* relevant to this discussion.

I don't think 7934 uses the words "unconstrained". There is always going to be a limit.
The network operator's response to this might 8273. In which case the privacy aspect changes quite a lot.

> That's true, indeed. But isn't that sort of a design principle of SLAAC? -- i.e., kind of "anarchy" when it comes to host configuration?

Absolutely. Just that temporary addresses changes the equation quite a bit.
A network might be willing to serve a small set of addresses to a host, but with temporary addresses there are really no limit.
If you do an address per transport connection, would you expect the network to serve that?
And if it doesn't, how is the host supposed to detect it? An happy eyeballs approach?
Right now that is completely unspecified in 4941bis (and sure it also was in 4941).
Question is if we should (try to) fix that?

> SAVI with SLAAC is essentially telling nodes "do what you please", and then punishing nodes when they don't do what you *expect* or *wished*.

> Which probably begs the question as why we don't make DHCPv6 mandatory, and add fill the necessary gaps there, so that a network that is to be operated as a managed network can apply policy to hosts, as needed. (yes, I did mean what I've just said :-) )
> 
> Put another way: SLAAC doesn't enforce any sort of policy on the network. Even attempts to *suggest* policy (e.g. draft-gont-6man-managing-slaac-policy) were shot down.
> 
> We also published draft-gont-6man-address-usage-recommendations to discuss the topic in a more general way. The suggestion was to take it to TAPS, where it somehow vanished.
> 
> So my personal conclusion is that one could certainly add a note like the one I suggested above. But other than that, I think further discussion of the topic belongs to a different document. -- We could revive draft-gont-6man-address-usage-recommendations if desired. -- in fact, it's kind of a shame that there hasn't been further work in that area.

For the purpose of 4941bis I would also be fine with a more ellaborate note expanding on the issues.
And I would also prefer that we suggested some strategies hosts can use to deal with this. There is already text in 4941bis regarding DAD. But the recommended behaviour when receiving DAD "rejects" seems a little harsh currently.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2020 11:32:19 -0300

On 23/1/20 11:11, [email-masked] wrote:
[....]
> I don't think 7934 uses the words "unconstrained". There is always going to be a limit.

They do use "can address unlimited endpoints, subject to network 
limitations". That said, of course I agree with you in this respect.

> The network operator's response to this might 8273. In which case the privacy aspect changes quite a lot.

At the end of the day, you are always at the mercy of the network operator.

> A network might be willing to serve a small set of addresses to a host, but with temporary addresses there are really no limit.

I'd argue that that's a potential problem intrinsic to slaac, rather 
than temporary addresses.

Datapoint: I have some apps explicitly meant to circumvent security 
controls. RFC4941 is not enough, because address generation is bound to 
time (and OS implementations set a lower bound). So essentially I do 
one-address-per-application (configure the address, explicitly bind it 
when issuing connections, then remove it).

> Question is if we should (try to) fix that?

I think that at least a "warning note" on the topic would be desirable. 
That's one option. Another option might be to enforce an upper limit on 
the time regeneration frequency (although I'd expect that it would be 
virtually impossible to come up with an agreeable value)

> For the purpose of 4941bis I would also be fine with a more ellaborate note expanding on the issues.

That sounds sensible. Unless I hear a specific text proposal beforehand, 
I will come back with suggested text later today.

> And I would also prefer that we suggested some strategies hosts can use to deal with this. There is already text in 4941bis regarding DAD. But the recommended behaviour when receiving DAD "rejects"…

Wouldn't *this* be more of a slaac issue than a rfc4941bis one?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 23 Jan 2020 16:07:12 +0100

Not really, as I don't think is related to having more or less addresses. We have 2 ways to resolve that:
a) Make DHCPv6 mandatory, so people in those scenarios can force all the devices to use DHCPv6.
b) Make some way to SLAAC to "report" the addresses.

El 23/1/20 15:11, "ipv6 en nombre de Fernando Gont" <[email-masked] en nombre de [email-masked]> escribió:

    
    Thanks,

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 23 Jan 2020 16:11:09 +0100

Le 23/01/2020 à 14:37, Jared Mauch a écrit :
>> no mention of operational / management complexity, or other
>> “general problems” that SLAAC has.  It seems there are unstated
>> problems here :)
> 
> 
> I would +1 this here.
> 
> I would also generally question if rotating IPs is a adequate privacy
> protector considering there are other ways to identify users that are
> being (broadly) employed today.
> 
> The complexity that this introduces into networks for operational
> debugging (provider: what’s your IP address so I can debug? User:
> Well here’s the 20 on the host because I have limited lifetime
> privacy addresses, and I don’t know what outbound one it’s using for
> this connection.  Provider: What’s your IP address so I can debug?
> Actually, can you just turn off v6 so I can debug your problem?
> User: sure, I just want it fixed).

I cheer the good effects of GDPR, and now of California law on privacy, 
in that end users can decide how much data about themselves to share or 
not share.

I admit the shortcomings and the bad side effects of Privacy concepts à 
la GDPR:
- when clicking No on homepages I get much less data than if I said Yes.
   In that direction, I might get isolated because I dont tell my
   address.
- some sites dont even bother to ask, they just stop serving because
   they have out-of-band data about my IP address being under the rule of
   law related to GDPR.  That's not  good.

Something unrelated to GDPR, but witness of lack of consideration of 
full picture of Privacy, is the following: the existence of the /64 
boundary makes the attackers' job on privacy easier.

There are possibilities to address each of these issues, and some of 
them might impact what RFC4941 needs.

For example, the problem of Yes/No giving less information, is a problem 
of layers: of course I am a powerful end user, and that is a weak 
Server.  The human intelligence is with me, the AI is with it.  The 
privacy of the two cant be compared- it's not on the same layer. 
'Privacy' is something between two humans on the same layer, not between 
a Human and a Server.

As such, I use something like Diffie-Helmann between me and a peer, and 
the servers something like pre-agreed keys between two servers.

But I cant talk about me hiding from a Server.  I might talk  about me 
hiding from sniffers on the way to server, but it is still me hiding 
form others like me.

I cant get into a bank and cover my face.  I cant drive the car without 
a license plate.  I cant get data from a server without telling who I 
am.  It's the law.  It's almost as the Nature.  Opposing Nature doesnt work.

This Yes/No homepage problem could be solved by a mechanism inspired 
from Diffie-Helman, as long as I accept the results will not be 100% 
satisfying either.  I could use a protocol to replace the Yes/No 
clicking.  That protocol would work like Diffie-Helman automated 
negotiation: I try see some data by revealing just a bit of me, then the 
server replies 'maybe', then I reveal a bit more, and so on.  A gradual 
escalation-deescalation, which would allow settling somewhere in a 
middle.  And without 1000 clicks.

I am sure http designers already thought about it.  I guess http already 
has a need of IP addresses and privacy.  Is http in line with RFC4941bis?

Still, it would still be me vs a server, and not me vs a me like me.  It 
means that the questions the Server poses would be too generic (how old 
are you, etc.) such as to accommodate a large number of people like me; 
that is where I might get bored first.

Maybe then another human should be in the loop, behind the server.  Then 
the whole Privacy and IP addressing would be different again.

S/he knows my address but I also know hers (his) - so there is no 
danger.  That's how privacy is respected.

You cant try to respect Privacy if you accept from a start that it's not 
on the same layer (human vs Server).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 23 Jan 2020 16:35:58 +0100

> arguing that, after all, having too many addresses wasn't much of a good 

If both ends each had multiple IP addresses, and they had a mechanism to 
agree on them all while ensuring one doesnt tell more about self than it 
learned from the other - that would be a good idea.

But here we talk about a poor end user that we technical people try to 
empower with many  addresses vs one Server that must have just one 
address so it can be reachable at a well-known, err, address.

It's strange that in the Privacy discussion no-one worries about the 
fact that Servers must have a unique address such as to be reachable at 
a well-known address.

The side effect of that Server Privacy address is the 'cyber squatting' 
- I hear a Name becomes fashionable, I book the name before the others, 
then I sell it for unreasonable amounts of money.  There are so many 
cases today that way that it is a huge business.  Now some Registrars do 
themselves the same job of cyber-squatters (pre-buy domains, and sell at 
huge prices).  It is a business, but it is not right either - it is 
artificial.

So, I think Privacy and cyber squatting are facets of the same and 
unique problem.

And Spam.

Alex

---

From: Bob Hinden <[email-masked]>
Date: Thu, 23 Jan 2020 09:34:18 -0800

Ole,

Clearly a very number of addresses is a problem for router and other devices on the link.   I note looking at my local machine (MacOS 10.14.6) I have five IPv6 addresses:

Link-local
ULA (temp and secured)
Global  (temp and secured)

My router advertises a Global and ULA prefix.

This seems to be current practice.   Is this a problem?   If I had 100 local devices on my link that would be 700 addresses, 1000 devices, then 7,000 addresses.  Is that excessive?   Also, depends on how the nodes manage this state, completely separate entries for each address, or all the addresses tied to the same link address.

For RFC4941bis, I think text that raises the issue is a good thing, but the issue isn’t created by the bis draft, it a part of SLACC.   We have multiple ways of creating IPv6 addresses, they all contribute to this.

I think a new document that discusses the issue and makes some recommendations would be useful.

Bob

> On Jan 23, 2020, at 12:59 AM, [email-masked] wrote:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 Jan 2020 17:52:31 +0000

Hello Bob

The issue is not confined within the node. This impacts the routers and the whole infra (think VXLANs).

Regards,

Pascal

> Le 23 janv. 2020 à 18:35, Bob Hinden <[email-masked]> a écrit :
> 
> Ole,
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Jan 2020 13:52:30 -0500

> The issue is not confined within the node. This impacts the routers and the whole infra (think VXLANs).

Indeed -- RFC6583 - "Operational Neighbor Discovery Problems", and,
much more so, RFC8273 - "Unique IPv6 Prefix per Host" seem very
relevant here...

Yay,  "We can solve any problem by introducing an extra level of
indirection" ( or aegrescit medendo :-))

W

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

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Jan 2020 08:05:59 +1100

On Fri, 24 Jan 2020, 00:37 Jared Mauch, <[email-masked]> wrote:

> > The problem statement section in 4941bis is all about user privacy, no
> mention of operational / management complexity, or other “general problems”
> that SLAAC has.  It seems there are unstated problems here :)
>
>
> I would +1 this here.
>
> protector considering there are other ways to identify users that are being
> (broadly) employed today.
>

This is the common "it's not perfect, so let's do nothing." Nothing ever
improves if perfect is the only threshold of acceptance. (Nothing is ever
perfect, there are always trade-offs. If you don't think there are
trade-offs, it just means you haven't identified them.)

At the IPv6 layer, we can't do anything about privacy issues at other
layers.

What we can do is improve privacy at the IPv6 layer. That helps reduce the
privacy attack surface. It adds to other measures, and prevents them being
defeated by the IPv6 layer.

Not providing IPv6 address privacy through temporary addresses will mean
people resort to the other address privacy measure they're familiar with,
and the one that makes IPv6 entirely pointless - NAT. Of course, it too
doesn't provide privacy at upper layers.

> debugging (provider: what’s your IP address so I can debug? User: Well
> here’s the 20 on the host because I have limited lifetime privacy
> addresses, and I don’t know what outbound one it’s using for this
> connection.  Provider: What’s your IP address so I can debug?  Actually,
> can you just turn off v6 so I can debug your problem?  User: sure, I just
> want it fixed).
>

Anonymity/privacy and unique identity are naturally and will always be in
conflict.

Do we compromise a desire for end-user privacy 100% of the time things are
working correctly for the 0.00...% of the time the end-user is impacted by
a fault?

We have to accept that sometimes an operators' work may be harder than it
could be, and that an end user might suffer for longer in a failure
situation, when under the common case of non-failure situations there are
valuable end-user benefits.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Thu, 23 Jan 2020 16:32:29 -0600

> can you just turn off v6 so I can debug your problem?  User: sure, I just

First, the idea of changing addresses is not a new one, this is
RFC4941bis or version 3 of this idea.  Second, if you read the draft it
discusses that this can complicate troubleshooting and the trade-off may
not be worth it in all cases.

Thanks.

-- 
===============================================
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: Michael Richardson <[email-masked]>
Date: Thu, 23 Jan 2020 18:49:48 -0500

> trade-offs, it just means you haven't identified them.)

I also have doubts about whether the rotating temporary address mechanisms
that 4941 provides is useful privacy when the upper-64 bits are unchanging.
But, I agree with you, that it is an improvement... except when it causes
other issues.  So we should consider when and where it's more effort than
it's worth, and when it has benefit.  That requires information that is
presently not available to hosts.

I think that we will need to re-think the ND mechanism(s) and L2/L3 binding
process.  I think that this will cause redesign of hardware switching
fabrics, and I note that it was a good 15 years between IPv4 ARP being
designed and the first hardware switching fabrics, and that was during a time
of much stepper IPv4 deployment than I think IPv6 has had.

I believe that we need to find ways to SEND and SHIM6 (or equivalent)
deployable.

I also think that we need to recognize that we have a number of distinct
deployment environments, and I think that we should be explicit about them:
1) protected home environments
2) guest home environments
3) enteprise environments
4) conference/guest/coffee-shop environments
5)  >4< at ridiculous scale
6) segregated L2 environments with vertically integrated operators (aka
   "LTE", Fred's ATN work, possibly RAW).

I think that the hosts need to know which environment they are in, and need
to change their behaviour.  I think that the DHCP v6only document is the
first of these type of documents.

So I would welcome a document that informed a host system about how many
Temporary is should expect, and we need a to generalize the LLN-specific ND
registration system, so that hosts can get feedback if they use too many,
etc.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 02:14:04 -0300

> b) Make some way to SLAAC to "report" the addresses.

Any of these two are out of the scope of rfc4941bis.

Thta said, I'll bite:
"a)" makes sense, but will probably suffer from a religious war.

"b)" would be in line with other efforts that somehow make slaac more 
stateful, or that try to incorporate dhcpv6 features into slaac. -- 
which look a bit like fooling ourselves.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 02:20:26 -0300

> The issue is not confined within the node. This impacts the routers and the whole infra (think VXLANs).

Well, that's slaac: configuration anarchy of some sort.

Nodes can configure as many addresses as they please. If you want the 
network to enforce policy, then you should probably be using DHCPv6 -- 
as many enterprises do.

That said, 4941bis addresses flaws/shortcommings of RFC4941. It is not 
introducing the concept of temporary addresses.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 02:44:43 -0300

On 23/1/20 20:49, Michael Richardson wrote:
[....]
> presently not available to hosts.

As noted by Bob, myself, and others, this is a slaac issue, and not 
something specifically related to 4942bis.

For instance, an ipv6-aware browser might e.g. decide to configure and 
employ different addresses for each tab, or for different apps. And 
you'll end up with way more addresses than those resulting from rfc4941.

>     "LTE", Fred's ATN work, possibly RAW).

If you expect hosts to behave nicely with your network, then you should 
probably convey policy information in RAs (as we tried, to some extent, 
in draft-gont-6man-managing-privacy-extensions). At the time, there was 
pushback.

If slaac doesn't convey policy, then nodes do what they assume is in 
their best interest.

And if the network doesn't really like the possible chaos resulting from 
slaac, then it should probably be using dhcpv6.

The nice thing about us doing nothing about the automatic configuration 
mess, is that it typically gets worse: e.g. my CPE sets "M" and "O" in 
RAs, while advertising PIOs for autoconf. So my Ubuntu conf ends up with:
* slaac stable addresses (RFC7217)
* slaac temporary addresses (rfc4941)
* one dhcpv6-leased address

PLease let me reiterate: the problem being discussed in this thread is a 
shortcoming of slaac.

It's certainly fine to add a note along the lines of "hey! don't 
regenerate addresses too frequently (i.e., beware when overriding 
default falues(, or else you might end up screwing the network".

But other than that, 4941bis is not about addressing shortcomings of slaac.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jan 2020 02:07:11 -0500

> But other than that, 4941bis is not about addressing shortcomings of slaac.

Gyan> This draft addresses the operational impacts of multiple addresses
for SLAAC defined with RFC 4862.  With PIO options capability the network
has the ability to send the host multiple addresses to the host.  Some
implementations I have seen have a ULA 4193 address and a GUI address sent
in the SLAAC  PIO prefix list.  Although I have tested this scenario in the
lab, practical  use of the address and which to use with the host OS
default source address selection algorithm is too complicated.  It would be
nice if you could use the ULA for internal intranet communications and GUA
for external but unfortunately it does not work that way.  Their is a
pecking order built with the source address selection algorithm and thus
the same address ends up being used all the time for all flows.  Defeats
the purpose or reason to have multiple addresses if the same one always
gets used.

Most host Operating Systems such as Windows and MAC by default have RFC
4941 privacy extensions implemented which generate a temporary address
which has default valid and preferred lifetime which are configurable by
the operator.

Definitely having multiple addresses on a host from an operations
prospective adds tremendous complexity.

Operations and user operational late of complexity is added to now
determine which address is used for conversation flows.

By default most operating systems both windows Mac and others follow a
default address selection pecking order to determine which address.  RFC
6724 defines this default address selection algorithm used in cases where
multiple PIO addresses exist on the host.  End result of the source address
selection algorithm is the same address is used all the time.

With implementations I have deployed personally from an operators and IT
security perspective as a standard for host images we would disable the
privacy extension temporary 4941 privacy address and also disable the
random IID so end hosts IPv6 address is stable.  For IT operators
simplicity is key for troubleshooting and trying to determine which address
is used for a conversation flow is an operations nightmare.  IPv6 SLAAC
address privacy makes sense and is Ok if you are connected to the internet,
however on corporate owned host endpoints for endpoint security “stable”
address is utmost importance.

My recommended direction for operator is to disable SLAAC random IID and
temp privacy address until RFC 7217 semantically opaque IID and RFC 8064
stable IID are implemented by host OS vendors which as Microsoft and
Apple.  Also for simplicity in troubleshooting from operations perspective,
even though IPv6 with PIO options had the ability to send unlimited number
of prefixes to a host I would recommend only sending a single address.

Since this draft talks about all the IID generation schemes I think it
should talk about operational impact of each option implemented.  Maybe
there should be another draft which discusses SLAAC IID options and
operational impact

I can kick start a draft that discussed this topic and makes a
recommendation as I mentioned above.

Kind regards

Gyan

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Jan 2020 11:35:44 +0100

>A network might be willing to serve a small set of addresses to a host, but wi
>th temporary addresses there are really no limit.

I'd say that if a network wants to have control over how addresses are
allocated it should use DHCPv6. Certainly if we are talking about relatively
low limited on the number of addresses per host.

However, given the desire to fit everything in SLAAC, what is missing at
the moment is a way for the network to express intent. 

The most basic way would be for a flag that disables temporary addresses.

A more adavanced option would be specify limits on the number of temporary
addresses and possibly ways to register/deregister an address. For example,
nodes can keep addresses alive be periodically generating a NA for the address.

The question of an address per transport connection is why would you do that?
In many IPv4 installations, the NAT box has state per flow. So having an IPv6
address per transport connection doesn't seem beyond what we can do.

The question is what the benefits are. I don't see a lot of privacy benefits
for lots of addresses.

Note that a single network port may still end up with losts of addresses:
- users may use bridges to extend the network and connect more than one host
  to a single port
- users may run virtual machines (or containers) in bridged mode and end up
  with multiple virtual hosts by behind a single port
- having an IPv6 address per process on a host may have benefits in particular
  if many processes would like to use the same port for some reason

Typically, even very small network switches support many thousand MAC
addresses. I think that network devices should support similar numbers of
IPv6 addresses per /64.

---

From: [email-masked]
Date: Fri, 24 Jan 2020 11:52:09 +0100

Hi Philip,

> address per transport connection doesn't seem beyond what we can do.

On reason might be because the application uses the temporary address in a way that taints it.
E.g. the address is used in a connection where the user is identified through authentication.
That address is now tained from thew perspective of privacy, and should not be used for other connections.

Given that we are downgrading 4941 to proposed standard, it might also be worth evaluating the state of 4941 implementations.
Are applications clever enough to not reuse tainted addresses?
Are they incorrectly exposed by e.g. MP-TCP or ICE implementations?
Anyone with data on this?

> addresses. I think that network devices should support similar numbers of

Sure, but when a host incurs a cost in the network, and the network has to have some policy in place to protect itself, there is going to be a limit.
I think we need some text in 4941 discussing this, and also give a recommendation for host behaviour. And perhaps also for network configuration.

Cheers,
Ole

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 Jan 2020 10:58:49 +0000

On 24 Jan 2020, at 10:52, [email-masked]<mailto:[email-masked]> wrote:

Hi Philip,

There is new work that is aware of that.  For example (as I was reviewing it very recently) in draft-ietf-intarea-provisioning-domains:

   In order to address privacy concerns around
   linkability of the PvD HTTP connection with future user-initiated
   connections, if the host has a temporary address per [RFC4941<https://tools.ietf.org/html/rfc4941>] in
   this PvD, then it SHOULD use a temporary address to fetch the PvD
   Additional Information and MAY deprecate the used temporary address
   and generate a new temporary address afterward.

I like that from a privacy perspective, even if it is only a MAY, but from the management/ops point of view it’s another address in use.

The flip side is there’s no note there mentioning the downside of doing so.

It’s an interesting tradeoff, and different environments will want the slider on that tradeoff at different ends of the scale.  But it’s certainly worth capturing.

Tim

Cheers,
Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Jan 2020 22:50:09 +1100

On Fri, 24 Jan 2020, 21:36 Philip Homburg, <[email-masked]>
wrote:

> >If you do an address per transport connection, would you expect the
> network to
> > serve that?
> >And if it doesn't, how is the host supposed to detect it? An happy
> eyeballs ap
> >proach?
> >Right now that is completely unspecified in 4941bis (and sure it also was
> in 4
> >941).

(Sorry for the size, this is how it copy-and-pasted)
Transient Addressing for Related Processes: Improved Firewalling by Using
IPV6 and Multiple Addresses per Host

https://www.cs.columbia.edu/~smb/papers/tarp/tarp.html
Many Addr

In many IPv4 installations, the NAT box has state per flow. So having an
> IPv6

Hiding in the crowd.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 08:47:50 -0300

> Anyone with data on this?

As noted elsewhere, there's a difference between the generation of 
temporary addresses, and their use.

Hostas and applications are quite dumb baout the use of addresses -- not 
just temporary addresses -- since we haven't done much on the topic. 
That's why we had published this: 
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations

I'm not aware of any API to trigger the generation of a new address, or 
deprecate an existing one. Or even to make more appropriate use of 
addresses based on their properties.

But, again, this is not an issue of temporary addresses, specifically. 
And thus would seem out of scope for this document.

> Sure, but when a host incurs a cost in the network, and the network has to have some policy in place to protect itself, there is going to be a limit.

If you want to enforce policy, that's what dhcpv6 is for.

If you use a /64 for the subnet (tons of addresses available), employ 
SLAAC for address configuration ("this is the local prefix... do what 
you please"), and even refrain from having SLAAC convey network policy 
(e.g. as in our circa 2011 to set a bit in PIOs regarding whether 
temporary addresses are desirable), I don't think you can complain about 
having nodes "using more addresses than you'd wish".

> I think we need some text in 4941 discussing this, and also give a recommendation for host behaviour. And perhaps also for network configuration.

I don't think we can give a recommendation other than something along 
the lines of "beware of regenerating temporary addresses too quickly, 
because this might affect the network".

RFC4941 is a deployed reality, and I don't think rfc4941is is changing 
anything significantly in terms of the number of addresses.

Rather I take this discussion as an indication that in a number of 
scenarios the network may want to convey policy (no surprises here), 
which leads e to believe that:

1) we should make dhcpv6 mandatory for once and for all, such that 
networks that want to enforce policy, they can

2) we might want to do something along the lines of 
draft-gont-6man-managing-slaac-policy, such that a network that wouldn't 
like privacy addresses, can convey that information to hosts.

However, when it comes to rfc4941bis, I don't think there's much more to 
do than simply including a small paragraph noting that an implementation 
should be aware about regenerating addresses too quickly,

The topic of "many addresses in a network" is way broader than temporary 
addresses, and includes e.g. "throw-away addresses" (one address per 
app), which have nothing to do with temporary addresses.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Jan 2020 13:19:53 +0100

>should be aware about regenerating addresses too quickly,

If people feel strongly about the risk of generating temporary addresses
too quickly, why not have a TEMP_MIN_PREFERRED_LIFETIME and have some
text that a node SHOULD NOT generate temporary addresses more often
than one address (per prefix) per TEMP_MIN_PREFERRED_LIFETIME.

This still allows any future RFC to describe a more advance privacy model
that does generate addresses more often.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jan 2020 09:54:11 -0500

Operators already have the option of not using the default valid and
preferred lifetimes.  Most operators don’t change the default values so
maybe  a suggestion could be to change the default values of of the
temporary address regeneration would help with stability.

Also disable temporary address regeneration churn is an issue to make the
address stable by disabling the privacy extension.  If security and
tracking of IPv6 addresses in use is a concern, disable the random station
ID defaulting to the modified EUI64 format.

Can we mention in the draft that a stable IID with privacy extension and
not having a separate temporary address is the directional approach for
6MAN to RFC 7217 and 8064.  Does everyone agree???

Also mention caveats with having multiple addresses from an operations
perspective is not desirable per the default source address selection
algorithm RFC 6724.  With RFC 6724 and predecessor 3484you are not gaining
anything with multiple addresses as the same address is always used.  So
the recommendation is to not send multiple slaac prefixes.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 13:29:55 -0300

> temporary address regeneration would help with stability.

NOt sure what you mean.

> Also disable temporary address regeneration churn is an issue to make 
> the address stable by disabling the privacy extension.  If security and 
> tracking of IPv6 addresses in use is a concern, disable the random 
> station ID defaulting to the modified EUI64 format.

NO idea what this means. You shouldn't use EUI64-nbased addressess. If 
you need stable addresses, that's what RFC7217 is for.

> 6MAN to RFC 7217 and 8064.  Does everyone agree???

That's a misrepresentation of RFC7217 and RFC8064.

RFC7217 specifies an alternative algorithm (to EUI64-baed) for 
generating stable addresses. RFC8064 simply recommends RFC7217 over the 
traditional slaac addresses that embed a mac address.

Those two documents don't say much about temporary addresses -- and they 
shouldn't, since they are about stable addresses.

> algorithm RFC 6724.  With RFC 6724 and predecessor 3484you are not 
> gaining anything with multiple addresses as the same address is always 
> used.  So the recommendation is to not send multiple slaac prefixes.

Not sure what you mean. RFC6724 is, in fact, all about leveraging 
multiple addresses.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 13:36:27 -0300

> than one address (per prefix) per TEMP_MIN_PREFERRED_LIFETIME.

I guess the issue here is which value to pick for it; i.e., something 
that gives enough leeway for folks that want to tweak this parameter, 
but now too low to alow folks to cause damage.

If anything, I'd probably employ the limit enforced on BSDs and Linux (I 
don't remember the specific value, but could check). It's mostly there 
to prevent insane settings, but still allows hosts to generate addresses 
quite frequently.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 12:17:19 -0500

> PLease let me reiterate: the problem being discussed in this thread is a

I think that the problem is bigger than SLAAC.  That's just one way to
configure addresses, and as you said, the problem is about communicating policy.

    > It's certainly fine to add a note along the lines of "hey! don't regenerate
    > addresses too frequently (i.e., beware when overriding default falues(, or
    > else you might end up screwing the network".

    > But other than that, 4941bis is not about addressing shortcomings of slaac.

I think that 4941bis should say something about the network cost.
Section 3.5 has a paragraph about the client costs of having a large number
of addresses, and maybe that's a place to talk about what happens if there
are too many.

I think that we need some way for a host to recognize that it's used too many
temporary addresses.  I wish that 6man-grand was able to add some kind of ACK
from the routers, but that won't scale.  So, we need a heuristic.
I would be happy if the document just said that this is a place for future work.

I've seen (wired) ubuntu hosts with a screen full of temporary
addresses.  Maybe that's a bug.

----

I also think that 3.6 should suggest that the enable/disable should be
settable on a per-attachment ("ESSID" aka "Provisioning Domain") basis.  The
text about doing this per-prefix would seem to mostly address this
requirement, but I'd prefer to write this differently.  Maybe it's enough to
start a new a paragraph at "Another site..."

I don't know how a "site" will communicate it's need to the OS, except via a
trusted administrator.  Maybe I missed somethinig?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 12:20:25 -0500

> network to enforce policy, then you should probably be using DHCPv6 --

I think that the too many addresses is more an issue on
conference/coffee-shop networks rather than in an enterprise environment.

I think that it is reasonable to establish an upper limit (8? 16?) of number
of entries per MAC address in a border router in those environments.
(Are there such controls today in APs/routers?)
This is exactly the place where temporary addresses make the most sense.
The only reason it isn't a problem now is because (a) lack of IPv6,
(b) most coffee-shop visits are shorter than lifetime.

Maybe there is some data from IETF/ARIN/RIPE network NOCs that could help.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 12:22:36 -0500

> nodes can keep addresses alive be periodically generating a NA for the address.

I would love to see an RA option with a byte in it that said how many slots
per mac address the router supported.

A value of 0 would force temporary addresses off.

Probably "0" would imply that there were actually two slots available per MAC
(LL and one ULA).

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 12:23:55 -0500

> not be used for other connections.

And so the application would like to give a hint to throw away that address *NOW*?
Or maybe the application would like to ask the OS for a *per-connection*
temporary address?

    > I think we need some text in 4941 discussing this, and also give a
    > recommendation for host behaviour. And perhaps also for network
    > configuration.

+1

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 14:59:48 -0300

> conference/coffee-shop networks rather than in an enterprise environment.

Why should it? The only reason why the number of addresses could be a 
concern in that scenario is:

1) MLD-snooping
2) Neighbor Cache entries

For the former, I guess one can resort to broadcasting the frames. For 
the later. Well, you need to be smart at managing the neighbor cache, 
anyway.

> of entries per MAC address in a border router in those environments.

HOw would that go along with RFC7834/BCP204?

> (Are there such controls today in APs/routers?)

I'm aware there are things like that for devices implementing first home 
security.

Now, given that rfc4941 is a deployed reality, trying to enforce a limit 
that's so close to the number of addresses that a host might use -- as 
per rfc4941 -- doesn't seem to be a good idea (actually, it's asking for 
breakage).

> (b) most coffee-shop visits are shorter than lifetime.

Where, specificallt, would you expect temporary addresses to be causing 
trouble?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Jan 2020 15:22:58 -0300

> configure addresses, and as you said, the problem is about communicating policy.

Well... right now, we essentially jave three mechanisms for configuring 
addresses:

1) SLAAC
2) DHCPv6
3) Manual configuration

1) could convey policy, but doesn't. And when I proposed it almost ten 
years ago, the group rejected it -- might try again, though.

2) Doesn't need to convey policy, for the most part, because the dhcpv6 
server itself can enforce the policy

3) involves no communication with anyone -- i.e., you do your own thing, 
so there's no place for communicating policy.

If you have a network that might break if, e.g., nodes were to configure 
IPv6 addresses, then you should be doing DHCPv6, and make sure you don't 
lease more addresses than the one your devices can handle. -- this would 
mean universal support of DHCPv6: i.e., update node requirements, and 
make dhcpv6 mandatory.

For slaac, you could certainly flag whether you want hosts to configure 
temporary addresses or not. BUt for other stuff, it's tricky. At the end 
of the day, what matters is the number of addresses in use. So it's not 
just how many addresses a node configures, but also how many nodes 
attack to your network. Restricting 10 addresses per gost when only 5 
hosts attach to your network would seem overly constricting.

Although, if you have multiple routers on the network, and they 
advertise different prefixes, then nodes might direct packets to the 
wrong router, and then you'd be affected by addresses configured for 
prefixes you don't even advertise.

SLAAC is, for better or worse, configuration anarchy. Not sure how much 
sense it makes to stick to anarchy and expect order....

(full disclosure: i have no personal preference for slaac or dhcpv6. I 
personally think each of them have a place. The part I strongly disagree 
with is the religious war where folks seem to believe that you must 
support one xor the other, and that each of them apply well to all 
scenarios).

> I would be happy if the document just said that this is a place for future work.

If you can craft some text for the "future work" part, that'd be 
appreciated.

> start a new a paragraph at "Another site..."

How about:
"An implementation SHOULD provide a way for a trusted administrator to 
enable or disable the use of temporary addresses on a per-ESSID basis. 
This would allow an administrator to enable or disable the use of 
temporary addresses for specific networks."

Thoughts?

> trusted administrator.  Maybe I missed somethinig?

Same as for disabling temporary addresses. (trusted admin)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 15:23:43 -0500

> HOw would that go along with RFC7834/BCP204?

1) Number of Neighbor Cache Entries, not necessarily addresses...
2) there is a different between avoiding the limit of "1" address and
   suppporting NCE 2^8 per host.  A /64 delegation occupies 1 NCE, or
   more accurately, 1 TCAM entry. It's likely that routing and NCE
   occupy the same TCAM.
3) a problem with PD per-host is that the upper bits are now unique for host,
   which makes 4941 somewhat useless, because you can't really hide in a
   crowd of one.

    > that's so close to the number of addresses that a host might use -- as per
    > rfc4941 -- doesn't seem to be a good idea (actually, it's asking for
    > breakage).

I agree.

    > Where, specificallt, would you expect temporary addresses to be causing

On a network like the IETF's, where supporting 1500 laptops winds up
requiring 64K NCE entries in every router, and we have only 8K.
On a campus network I can see there being 30,000 student-devices.
If we allow for 8-16 per device, that's probably manageable, but 200 per
device is not.

What's *really* bad is that the failures are really hard to diagose, do not occur
for IPv4 (makes IPv6 look bad), and are "fixable" by rebooting the device.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 24 Jan 2020 21:12:47 +0000

It takes a bit more than that but agreed.
Really the router needs to know which addresses are used and which cease to exist. Even if the host only uses 8 the router cannot infer which one.

Regards,

Pascal

> Le 24 janv. 2020 à 18:23, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jan 2020 16:22:12 -0500

> > temporary address regeneration would help with stability.

The router in the RA can can set the valid and preferred lifetime if
desired on each subnet for the SLAAC prefix received.  I believe when
that’s done the temporary address inherits the same values.

> you need stable addresses, that's what RFC7217 is for.

When you disable the random station ID the default is Modified EUI64 not
EUI64 for Microsoft and Apple devices.  I agree RFC 7217 stable address is
most preferred however Microsoft and Apple don’t support yet.

> traditional slaac addresses that embed a mac address.

I believe we are saying the same thing.

   I am not trying to mix apples with oranges although it sounds that way
since RFC 7217 does not use temporary address but achieve the same privacy
goals with the alternative algorithm.

Do you agree that RFC 7217 algorithm to generate a stable IID is the best
approach out of all the slaac IID generation options that exist today,

> Agreed.  Understood.  My point is to recommend RFC 7217 stable address as
> currently the best option available.  Also obsolete or deprecate RFC 4941.

> Not sure what you mean. RFC6724 is, in fact, all about leveraging

Yes it is but it does not do I believe what the author envisioned it to
do.  I believe that is to be able to use one slaac source address selected
for certain flows such as intranet internal flows and be able to
simultaneously use another address for different flows.  That is not
possible.  That goes to the point that IPV6 allows for many prefixes to be
sent to the slaac host, however the host does not have any means of using
more then one at a time unfortunately.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jan 2020 11:11:05 +1300

>  I agree RFC 7217 stable address is most preferred however Microsoft and Apple don’t support yet. 

I have no idea for Apple, but afaik MS switched to pseudorandom stable IIDs per interface a long time ago, before Windows 7 possibly. I haven't seen a modified EUI-64 address on my laptop for a very long time. This is not the same thing as RFC7217 from a privacy point of view, but for network operations and neighbour cache size it seems like the same thing.

Anyway, I hope we're all agreed that this topic, however interesting is not worth more than a small comment in RFC4941bis. Isn't it actually a v6ops topic ("Operational impact of numerous addresses per host")?

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 25 Jan 2020 10:02:01 +1100

On Sat, 25 Jan 2020, 09:11 Brian E Carpenter, <[email-masked]>
wrote:

> I have no idea for Apple, but afaik MS switched to pseudorandom stable
> IIDs per interface a long time ago, before Windows 7 possibly.

Going by the URL in RFC7721 it is as early as Windows XP. (RFC URL broken,
however archive.org has a copy.)

I haven't seen a modified EUI-64 address on my laptop for a very long time.
> This is not the same thing as RFC7217 from a privacy point of view, but for
> network operations and neighbour cache size it seems like the same thing.
>
> Anyway, I hope we're all agreed that this topic, however interesting is
> not worth more than a small comment in RFC4941bis. Isn't it actually a
> v6ops topic ("Operational impact of numerous addresses per host")?
>
> Regards
>    Brian
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jan 2020 18:05:03 -0500

> >  I agree RFC 7217 stable address is most preferred however Microsoft and

  Gyan>On my IPv6 roadmap list with Microsoft.  So far no ETA.

> IIDs per interface a long time ago, before Windows 7 possibly. I haven't
> seen a modified EUI-64 address on my laptop for a very long time. This is
> not the same thing as RFC7217 from a privacy point of view, but for network
> operations and neighbour cache size it seems like the same thing.

   Gyan> I think it’s EUI-64 and not modified.

I found this link from Microsoft but it does not state if modified is
supported or not.

> v6ops topic ("Operational impact of numerous addresses per host")?

  Gyan> Agreed

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jan 2020 18:06:08 -0500

Microsoft link - forgot

> I found this link from Microsoft but it does not state if modified is

http://download.microsoft.com/download/F/D/F/FDF4CF55-5FDE-4CFF-8539-3662BB5EB7A0/TD13Basel2-43.pptx

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jan 2020 14:30:17 +1300

On 25-Jan-20 12:06, Gyan Mishra wrote:
> 
> Microsoft link - forgot 
> 
> On Fri, Jan 24, 2020 at 6:05 PM Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On Fri, Jan 24, 2020 at 5:11 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 

No. Here's what my Windows 10 says right now (WAN prefix etc obscured manually). There are no EUI-64 or modified EUI-64 interface identifiers.

Microsoft Windows [Version 10.0.17763.737]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : DESKTOP-xxxx
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : fritz.box

Ethernet adapter Ethernet 4:

   Connection-specific DNS Suffix  . : fritz.box
   Description . . . . . . . . . . . : ASIX AX88772B USB2.0 to Fast Ethernet Adapter #2
   Physical Address. . . . . . . . . : E8-03-9A-3C-67-7A
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2406:e002:xxxx:xxxx:80b2:5c79:2266:e431(Preferred)
   IPv6 Address. . . . . . . . . . . : fd63:45eb:dc14:0:80b2:5c79:2266:e431(Preferred)
   Temporary IPv6 Address. . . . . . : 2406:e002:xxxx:xxxx:89fa:eda3:4d87:293b(Preferred)
   Temporary IPv6 Address. . . . . . : fd63:45eb:dc14:0:89fa:eda3:4d87:293b(Preferred)
   Link-local IPv6 Address . . . . . : fe80::80b2:5c79:2266:e431%7(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.178.30(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Saturday, 25 January, 2020 14:14:02
   Lease Expires . . . . . . . . . . : Tuesday, 4 February, 2020 14:14:02
   Default Gateway . . . . . . . . . : fe80::be05:43ff:fe8e:ce39%7
                                       192.168.178.1
   DHCP Server . . . . . . . . . . . : 192.168.178.1
   DHCPv6 IAID . . . . . . . . . . . : 604000438
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-24-04-A7-BC-9C-DA-3E-8F-05-7F
   DNS Servers . . . . . . . . . . . : fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
                                       192.168.178.1
                                       fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
   NetBIOS over Tcpip. . . . . . . . : Enabled

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : fritz.box
   Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 7265
   Physical Address. . . . . . . . . : 1A-BC-EF-15-F2-27
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2406:e002:xxxx:xxxx:db7:d041:a2d:ce65(Preferred)
   IPv6 Address. . . . . . . . . . . : fd63:45eb:dc14:0:db7:d041:a2d:ce65(Preferred)
   Temporary IPv6 Address. . . . . . : 2406:e002:xxxx:xxxx:6029:b755:ced7:343e(Preferred)
   Temporary IPv6 Address. . . . . . : fd63:45eb:dc14:0:6029:b755:ced7:343e(Preferred)
   Link-local IPv6 Address . . . . . : fe80::db7:d041:a2d:ce65%23(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.178.25(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Saturday, 25 January, 2020 14:13:40
   Lease Expires . . . . . . . . . . : Tuesday, 4 February, 2020 14:13:38
   Default Gateway . . . . . . . . . : fe80::be05:43ff:fe8e:ce39%23
                                       192.168.178.1
   DHCP Server . . . . . . . . . . . : 192.168.178.1
   DHCPv6 IAID . . . . . . . . . . . : 194828862
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-24-04-A7-BC-9C-DA-3E-8F-05-7F
   DNS Servers . . . . . . . . . . . : fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
                                       192.168.178.1
                                       fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
   NetBIOS over Tcpip. . . . . . . . : Enabled

> 
>     I found this link from Microsoft but it does not state if modified is supported or not.
> 
> 

IPv6 has always used "modified EUI-64". What that 2013 presentation does state is very clear:

"Beginning with Windows Vista and Windows Server 2008, a randomized method is utilized to determine the Interface ID instead of EUI-64" (slide 26). 

In the next line it gives you the magic to revert to modified EUI-64:

"netsh int ipv6 set global randomizeidentifiers=enabled|disabled"

Regards
    Brian

>     Email: [email-masked] <mailto:[email-masked]>
> 
> 
> 
> -- 
> 
> Gyan  Mishra
> 
> Email: [email-masked] <mailto:[email-masked]>
> 
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 24 Jan 2020 20:51:26 -0500

On Fri, Jan 24, 2020 at 8:30 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >         I have no idea for Apple, but afaik MS switched to pseudorandom
> stable IIDs per interface a long time ago, before Windows 7 possibly. I
> haven't seen a modified EUI-64 address on my laptop for a very long time.
> No. Here's what my Windows 10 says right now (WAN prefix etc obscured
> manually). There are no EUI-64 or modified EUI-64 interface identifiers.
>
>    IPv6 Address. . . . . . . . . . . :
> 2406:e002:xxxx:xxxx:80b2:5c79:2266:e431(Preferred)
>    IPv6 Address. . . . . . . . . . . :
> fd63:45eb:dc14:0:80b2:5c79:2266:e431(Preferred)
>    Temporary IPv6 Address. . . . . . :
> 2406:e002:xxxx:xxxx:89fa:eda3:4d87:293b(Preferred)
>    Temporary IPv6 Address. . . . . . :
> fd63:45eb:dc14:0:89fa:eda3:4d87:293b(Preferred)
>    DHCPv6 Client DUID. . . . . . . . :
> 00-01-00-01-24-04-A7-BC-9C-DA-3E-8F-05-7F
>    IPv6 Address. . . . . . . . . . . :
> 2406:e002:xxxx:xxxx:db7:d041:a2d:ce65(Preferred)
>    IPv6 Address. . . . . . . . . . . :
> fd63:45eb:dc14:0:db7:d041:a2d:ce65(Preferred)
>    Temporary IPv6 Address. . . . . . :
> 2406:e002:xxxx:xxxx:6029:b755:ced7:343e(Preferred)
>    Temporary IPv6 Address. . . . . . :
> fd63:45eb:dc14:0:6029:b755:ced7:343e(Preferred)
>    DHCPv6 Client DUID. . . . . . . . :
> 00-01-00-01-24-04-A7-BC-9C-DA-3E-8F-05-7F
> "Beginning with Windows Vista and Windows Server 2008, a randomized method
> is utilized to determine the Interface ID instead of EUI-64" (slide 26).
>

  Good catch Brian!!

>
> Regards
>     Brian
>
> >
> >         Anyway, I hope we're all agreed that this topic, however
> interesting is not worth more than a small comment in RFC4941bis. Isn't it
> actually a v6ops topic ("Operational impact of numerous addresses per
> host")?
> >
> >
> >       Gyan> Agreed
> >
> >
> >
> >         Regards
> >            Brian
> >
> >     --
> >
> >     Gyan  Mishra
> >

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Christian Huitema <[email-masked]>
Date: Fri, 24 Jan 2020 21:01:49 -0800

> that 4941 provides is useful privacy when the upper-64 bits are unchanging.

The privacy properties of addresses boil down to the size of the
anonymity set. How many users share this prefix? If the answer is
parents and children in the house, then the anonymity set is quite
small. The observers won't know for sure whether the connection comes
from little Billy or his mother, but the uncertainty factor has dropped
from "one billion people on the Internet" to "4 or 5 people behind that
connection". Changing the bottom 64 bits on that prefix prevent the size
of the anonymity set from shrinking all the way to 1, but that's not
entirely satisfactory. This gets of course better if the anonymity set
is "all students on campus", but campus networks are a bit special. In
most cases, local networks serve a small number of users. Maybe more
than a household, but not that much more.

If we want a privacy preserving address allocation, we have to think
beyond the local network boundary. The anonymity set is just as large as
the number of users served by an address prefix. Suppose an ISP who
really wants to enhance user privacy. Could they make the anonymity set
as big as all subscribers of the ISP? Or maybe all subscribers of the
ISP in a given region? I assume that we could do flat routing with
10,000 or 100,000 addresses in a  region. Might require some extra
hardware, but our friendly router vendors could most probably sell that.
But that would require having a prefix for the region, and doing flat
routing per address on the last hops. That also mean that the prefix
will be shared by multiple local area networks.

Now, what does that do for address allocation?

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Jan 2020 07:45:03 -0500

I really like this way of thinking about the “anonymity set.”   I’ve been a bit obsessed with this problem for a while; I think that flat routing of a bazillion addresses is probably not an ideal solution, however, because in order to get real anonymity, you have to not reuse addresses, and so now you’re looking at a Carl Sagan worth of addresses (billions and billions) in the routing table.

Another solution that could be useful is to do connections through an anonymity concentrator that tunnels your flow to the selected server.   The idea here is that your ISP (but it doesn’t have to be your ISP!) has a bunch of anonymity boxes sitting in their data centers, and when you want to connect to foo.com <http://foo.com/>, you establish a connection to the anonymity server.   The anonymity server constructs a new 5-tuple using its own fixed IP address.   This is effectively a NAT translation, and of course it can maintain a set of IP addresses large enough that it has enough A+P possibilities to make it work.   Now from the perspective of foo.com <http://foo.com/>, all connections from users at your ISP are coming from a very small number of IPv6 source addresses for which the “anonymity” set is quite large.  You don’t even always use the same anonymity server.

I think this is quite a bit easier to do than flat routing of temporary addresses—it’s more on the scale of CGN, but lacks some of the scaling problems of CGN for IPv4 because we have IPv6 addresses.

Of course, the anonymity server is now a new attack surface to think about when worrying about snooping, so we’ve just changed who we’re trusting, not eliminated a need for trust.

Another solution I’ve considered is to have a giant anonymity mesh, with every ISP’s user participating, and forward flows through this mesh, treating each customer as an anonymity server.   I think this is a bad idea, because it could expose an end user to accusations if someone else connects through their anonymity node and does something nefarious that’s traced back to them and not to the original perpetrator.  It’s also suboptimal from a routing perspective.  But it’s an interesting thought experiment.

> On Jan 25, 2020, at 12:01 AM, Christian Huitema <[email-masked]> wrote:
>

---

From: Jared Mauch <[email-masked]>
Date: Sat, 25 Jan 2020 07:51:25 -0500

> On Jan 25, 2020, at 7:45 AM, Ted Lemon <[email-masked]> wrote:
> 

Not in the routing table.  You won’t have billions of routes in the RIB or FIB in the DFZ in my lifetime.

Now what ND does to the local network is quite problematic but also has been discussed at length and we’ve seen that impact on wireless networks at IETF meetings.  The amount of broadcast/multicast background noise gets raised to much higher levels as a result and has practical operational considerations.

One of the things the group may want to work on is finding the right thresholds and providing some operational guidance as a result.

We did a similar experiment at a NANOG meeting with providing the venue network via the hotel and by having IPv6 on it caused the radio noise floor to raise significantly due to the broadcast(multicast) traffic it harmed the throughput of the network greatly.

Operators need the network to function and will disable things until it does.

- Jared

---

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Jan 2020 14:21:19 -0500

Ted Lemon <[email-masked]> wrote:
    > Another solution that could be useful is to do connections through an
    > anonymity concentrator that tunnels your flow to the selected server.
    > The idea here is that your ISP (but it doesn’t have to be your ISP!)
    > has a bunch of anonymity boxes sitting in their data centers, and when
    > you want to connect to foo.com <http://foo.com/>, you establish a
    > connection to the anonymity server.   The anonymity server constructs a
    > new 5-tuple using its own fixed IP address.   This is effectively a NAT
    > translation, and of course it can maintain a set of IP addresses large

Except that instead of doing it at layer 4, you do it with IPsec, and extrude
that /128 to your machine.  This is already a thing :-)

    > Another solution I’ve considered is to have a giant anonymity mesh,
    > with every ISP’s user participating, and forward flows through this
    > mesh, treating each customer as an anonymity server.   I think this is

This is also a thing called Tor.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Jan 2020 14:32:08 -0500

> that /128 to your machine.  This is already a thing :-)

You mean a VPN?   Yes.  But in a VPN, all your flows are going through the same tunnel.

> This is also a thing called Tor.

I know.  And there’s a reason why I don’t run a Tor exit node.   But thinking about how to do this without that problem seems worthwhile.

---

From: Tom Herbert <[email-masked]>
Date: Sat, 25 Jan 2020 11:48:16 -0800

> This is also a thing called Tor.
Michael,

Doesn't that require that the users must explicitly configure when
they want privacy? I think a general solution should be transparent to
the user and "just works" to ensure their privacy. That in fact is one
of the arguments for NAT. If there is a significantly large enough
pool of users behind a NAT device, then the obfuscation is transparent
to the use and seems to be pretty good privacy (good enough that law
enforcement is concerned about NAT). I suppose a similar effect could
be achieved with a transparent proxy.

You might want to take a look at draft-herbert-ipv6-prefix-address-privacy-00.

Tom

---

From: Ca By <[email-masked]>
Date: Sat, 25 Jan 2020 11:57:21 -0800

> > This is also a thing called Tor.

+1, dont re-invent Tor

> be achieved with a transparent proxy.

CGN/NAT logs all your sources and destinations.

The network operators will say they must do it for LEA compliance.

But once it is logged and stored it is available for nefarious hackers and
big data marketing folks.

That said, most of you in north america have ipv6 on your phones. Do you
feel that behavior of cycling addresses is not sufficient (barring ATT
which proxies all HTTP afaik) ?

> You might want to take a look at
> draft-herbert-ipv6-prefix-address-privacy-00.
>
> Tom
>
> > --

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 25 Jan 2020 15:05:29 -0500

>    Default Gateway . . . . . . . . . : fe80::be05:43ff:fe8e:ce39%7

   Gyan> I did some research on this v6ops related topic as far as
operational impact of RFC 4941 privacy extension.

So Microsoft as stated in the 2013 presentation has implemented RFC 4941
starting with Vista with the MD5 randomize generated IID that is stored and
persistent across reboot and only changes if the prefix changes with
mobility and a new 128 bit address stable address is generated.

The Privacy temporary address is generated from the Ethernet interface
random IID and the first time generated after initial boot the temporary
address is the same as the interface IID.  The temporary valid and
preferred lifetimes are set based on a formula and is less then the LAN
interface random IID.

So what was envisioned by the author of RFC 4941 was to use the “stable”
LAN  Random IID “Public” address for incoming connections which would be
published via DDNS and outgoing connections for user privacy use the
“privacy” temporary address.  The analogy used in the draft is the stable
LAN address in the PSTN world is like publishing your phone number in the
white pages, and your private temporary address is analogous to called ID
block for anonymity.

The operational complexity behind this approach of using multiple addresses
is during regeneration is when the temporary address becomes depreciated it
may still be used for existing outgoing connections while the new preferred
address now active is being used for new outgoing connections.  At the same
time all incoming connections are using the dns public published “stable”
lan interface random IID.

Imagine if you have multiple prefixes sent in PIO options to the host - 4x
times the number of SLAAC prefixes received.  Way complex troubleshooting
for operations.  Imagine a help desk rep asking a user “what’s your IPv6
address”

What Microsoft did not follow in their implementation is RFC 4941
deployment considerations is that the temporary address should be disabled
by default due to operational impact.

Quoted from RFC 4941

The use of temporary addresses may cause unexpected difficulties with
   some applications.  As described below, some servers refuse to accept
   communications from clients for which they cannot map the IP address
   into a DNS name.  In addition, some applications may not behave
   robustly if temporary addresses are used and an address expires
   before the application has terminated, or if it opens multiple
   sessions, but expects them to all use the same addresses.
   Consequently, the use of temporary addresses SHOULD be disabled by
   default in order to minimize potential disruptions.

Disable RFC 4941 LAN interface “stable” Random IID = This should never be
done as you revert back to OUI Mac based IID

netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

Disable temporary address:  Microsoft should have made this default.

netsh interface ipv6 set privacy state=disabled store=persistent

I will forward comment on  v6ops and OPSEC WGs and kick of a draft related
to this critical topic.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 25 Jan 2020 15:28:08 -0500

On Sat, Jan 25, 2020 at 3:05 PM Gyan Mishra <[email-masked]> wrote:

>> "Beginning with Windows Vista and Windows Server 2008, a randomized
>> method is utilized to determine the Interface ID instead of EUI-64" (slide
>> 26).
>>
> The operational complexity behind this approach of using multiple
> addresses is during regeneration is when the temporary address becomes
> depreciated it may still be used for existing outgoing connections while
> the new preferred address now active is being used for new outgoing
> connections.  At the same time all incoming connections are using the dns
> public published “stable” lan interface random IID.
>
>       Gyan> Fernando - As the author of RFC 7217 I am wondering as to the
reason why Microsoft and Apple have not adopted your draft for “stable”
IPv6 address.

My guess is that since the Random MD5 generated LAN IID is “stable” and OS
vendors have the option of disabling the temporary address - once that is
done you now have a “stable” random IID and best of both worlds ; single
traceable IPv6 address for incoming and outgoing connections for operations
as the IID does not change ; unless the device moves to a different LAN
drop ; with random MD5 hash generated LAN IID you have the user privacy
concerns met.  I did notice that RFC 7217 also does not preclude use of
temporary address.  So that is even more reason to stay course with RFC
4941.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Tom Herbert <[email-masked]>
Date: Sat, 25 Jan 2020 12:53:02 -0800

> The network operators will say they must do it for LEA compliance.
Ca,

Yes, but beyond the operator boundary the addresses are obfuscated. At
some level it seems we need to trust the provider which is the entity
delegating addresses to users.

> But once it is logged and stored it is available for nefarious hackers and big data marketing folks.
>
That's a problem for any collected PII. Those collecting the
information may not implement sufficient safeguards to protect the
information. That's a more general problem that we can't solve in the
context of 6man or probably even IETF.

> That said, most of you in north america have ipv6 on your phones. Do you feel that behavior of cycling addresses is not sufficient (barring ATT which proxies all HTTP afaik) ?

Without a quantitative analysis of the privacy attributes offered to
the user I wouldn't venture to say whether it's sufficient. This is
the problem with RFC 4941 and 4941bis, the techniques for improving
privacy are only described and analyzed in qualitative terms. For
instance, 4941bis states:

"Using temporary address alone may not be sufficient to prevent all
forms of tracking. It is however quite clear that some usage of
temporary addresses is necessary to improve user privacy."

It's intuitive that temporary addresses improve privacy. But the
question quickly becomes _how_ do temporary addresses improve privacy,
and more specifically what is the lifetime of temporary addresses
needed to ensure any level of privacy. For instance, if one user has
an address lifetime of 2 hrs. and one has a lifetime of 1 hr. does
that mean that the user with 1 hr. address has 50% the risk of privacy
being compromised? I very much doubt it works that way, but I'm not
even sure that we can say there's any material difference in user
privacy between them. Without a way to quantify the effects, we're
only left with heuristics and intuition. Note the contrast with
security in this, for instance the effects of crypto algorithms and
correlation between key length and breakability is well studied. I
wish there was an equivalent study of privacy.

Tom

---

From: Warren Kumari <[email-masked]>
Date: Sat, 25 Jan 2020 18:35:32 -0500

> We did a similar experiment at a NANOG meeting with providing the venue network via the hotel and by having IPv6 on it caused the radio noise floor to raise significantly due to the broadcast(multi…

... see the ietf-hotel network in Singapore as another example of
having to disable V6 because of the broadcast load.
https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/
talks about the interaction of broadcast/multicast on 802.11
networks...

W

---

From: Jared Mauch <[email-masked]>
Date: Sat, 25 Jan 2020 19:18:20 -0500

I'm not convinced that I get more privacy by using the privacy addresses and more than encoding my emails with rot13. 

The industry has far more advanced ways to fingerprint users. The data done by https://amiunique.org/ folks as well as others make it clear that IP addresses aren't the means of tracking that I believe the concerns that introduced privacy addresses were attempting to solve. 

Sent from my iCar

> On Jan 25, 2020, at 3:53 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 25 Jan 2020 22:07:24 -0500

O’Reilly is a famous author that has written many books on networking
technology and had written this draft on criminal attribution
characteristics of IPv6 address assignment.

He is talking about how RFC 4941 privacy extension temporary address user
privacy requirements directly impacts law enforcement   in tracking down
criminal activity using the web and/or any cyber crimes.

After reading this you really have to think hard as to why as to why users
connected to the internet require privacy of their IPv6 address so it
cannot be tracked,

All electronic commerce is secure and so why does you IPv6 address have to
be private so it’s untraceable.

Other then criminal intent and not leaving an IPv6 trail that can be traced
to the criminal activity of the perpetrators by law enforcement I cannot
think of a reason for IPv6 address privacy.

Please enlightened me.

Analysis of the Crime Attribution Characteristics of Various IPv6 Address
Assignment Techniques
draft-daveor-ipv6-crime-attribution-00
Abstract
<https://tools.ietf.org/id/draft-daveor-ipv6-crime-attribution-00.html#rfc.abstract>

The migration from IPv4 to IPv6 is intended to fix a large number of
problems with IPv4 that have been identified through many years of global
use, not least of which is the shortage of available IPv4 addresses. One of
the challenges with IPv4 that has not, apparently, been adequately
considered is the crime attribution characteristics of IPv6 technologies.

The challenge of crime attribution on the Internet is an important one and
a careful balance needs to be struck between the needs of law enforcement,
the rights of crime victims and the right to privacy of the vast majority
of Internet users who have no involvement in any sort of criminality.

The purpose of this document is to consider the crime attribution
characteristics of various IPv6 address assignment techniques.

https://tools.ietf.org/id/draft-daveor-ipv6-crime-attribution-00.html

On Sat, Jan 25, 2020 at 7:18 PM Jared Mauch <[email-masked]> wrote:

> I'm not convinced that I get more privacy by using the privacy addresses
> and more than encoding my emails with rot13.
>
> The industry has far more advanced ways to fingerprint users. The data
> done by https://amiunique.org/ folks as well as others make it clear that
> IP addresses aren't the means of tracking that I believe the concerns that
> introduced privacy addresses were attempting to solve.
>
> Sent from my iCar
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 25 Jan 2020 22:32:19 -0500

End user privacy comes into play when connected to the internet.  I would
think privacy concerns from an end user prospective is “data privacy” and
any attacks from viruses or malware or port scan attack.  Most desktop are
windows based and Microsoft has default Windows firewall and windows
defender for virus and malware protection.  Also we transaction should be
done with https as a best practice for end users to protect personal
information.  All broadband routers have NAT built where internal hosts sit
on a private RFC 1918 lan typically 192.168.1.0/24 and port forwarding
rules are required for access from the outside to inside.  All broadband
routers have built in firewalls these days although most users don’t enable.

So give the above basic SOHO network security out of the box for all
homeowners on their home broadband internet connection, what additional
security is gained my making this IPv6 address private and untraceable via
a regeneration of a temporary address.

Kind regards,

Gyan

On Sat, Jan 25, 2020 at 10:07 PM Gyan Mishra <[email-masked]> wrote:

> Other then criminal intent and not leaving an IPv6 trail that can be
> traced to the criminal activity of the perpetrators by law enforcement I
> cannot think of a reason for IPv6 address privacy.
>
> Please enlightened me.
>
>> done by https://amiunique.org/ folks as well as others make it clear
>> that IP addresses aren't the means of tracking that I believe the concerns
>> that introduced privacy addresses were attempting to solve.
>>
>> Sent from my iCar
>>

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Christian Huitema <[email-masked]>
Date: Sat, 25 Jan 2020 21:41:03 -0800

On 1/25/2020 4:18 PM, Jared Mauch wrote:

> I'm not convinced that I get more privacy by using the privacy
> addresses and more than encoding my emails with rot13. 
>
> that IP addresses aren't the means of tracking that I believe the
> concerns that introduced privacy addresses were attempting to solve.

Yes, there are many leaks. That not a reason to not plug our own leak,
i.e. the use of IP addresses as unique identifiers. As the web leaks are
progressively plugged by privacy oriented browsers or by fingerprint
blocking add-ons, the importance of address privacy increases.

-- Christian Huitema

---

From: Ole Troan <[email-masked]>
Date: Sun, 26 Jan 2020 08:13:44 +0100

> On 26 Jan 2020, at 06:41, Christian Huitema <[email-masked]> wrote:
> 

I do wonder if rotating the iid is significantly better than a stable per-link 7217 iid. 

Isn’t the first thing an application does to use the temporary address to authenticate with a service, that then turns around and sells the information abo the user to address mapping on the open market?
Ignoring all the cookies and other tracking mechanisms already in place...

Ole

---

From: Jared Mauch <[email-masked]>
Date: Sun, 26 Jan 2020 06:56:07 -0500

> On Jan 26, 2020, at 12:41 AM, Christian Huitema <[email-masked]> wrote:
> 
> the importance of address privacy increases.

What you are saying is the cost to operate the network increases, sometimes to the point where the privacy makes the network unusable. This is the operational experience. 

It also means things like my ssh sessions can't last long enough to do large transfers as the address is rotated away. 

There is more to the internet than browser activity. The noise of NDP for all these addresses has a real cost. Some of the problems are documented in 6583. 

A network that doesn't work is not the goal but it will have the privacy you seem to be reaching for.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 26 Jan 2020 08:26:19 -0500

On Sun, Jan 26, 2020 at 6:56 AM Jared Mauch <[email-masked]> wrote:

> What you are saying is the cost to operate the network increases,
> sometimes to the point where the privacy makes the network unusable. This
> is the operational experience.
>
> It also means things like my ssh sessions can't last long enough to do
> large transfers as the address is rotated away.
>
> There is more to the internet than browser activity. The noise of NDP for
> all these addresses has a real cost. Some of the problems are documented in
> 6583.
>

  Gyan> I did some research on this v6ops related topic as far as
operational impact of RFC 4941 privacy extension and Microsoft’s
implementation.

Microorganisms 2013 presentation
http://download.microsoft.com/download/F/D/F/FDF4CF55-5FDE-4CFF-8539-3662BB5EB7A0/TD13Basel2-43.pptx

So Microsoft, still being a major stakeholder In the desktop OS arena, as
stated in the 2013 presentation above, has implemented RFC 4941 starting
with Vista with the MD5 randomize generated IID that is stored and
persistent across reboot and only changes if the prefix changes with
mobility and a new 128 bit address stable address is generated.

interface random IID.  I believe it’s 24 hours valid and 7 days preferred
lifetimes by default.

“privacy” temporary address.  The analogy used in the draft is, the stable

The operational complexity behind this approach of using multiple addresses
is during regeneration is when the temporary address becomes depreciated,
it may still be used for existing outgoing connections, while the new
preferred address now active is being used for new outgoing connections.
At the same time all incoming connections are using the dns public
published “stable” lan interface random IID.

Imagine if you have multiple prefixes sent in PIO options to the host - {
link local, lan IID, depreciated temp, Preferred temp) 4x times the number
of SLAAC RA prefixes received.  Way complex troubleshooting for
operations.  Imagine a help desk rep asking a user “what’s your IPv6
address”.  Not to mention doing a wireshark Trace and trying to understand
the flow, with the end host using 4 different addresses simultaneously per
SLAAC address.

What Microsoft did not follow in their implementation is RFC 4941
deployment considerations, is that the temporary address should be disabled
by default due to operational impact.  I think this is huge and the crux of
the issue the IPv6 community has been faced with Day 1.

Quoted from RFC 4941

Microsoft sill having a majority of the desktop marketplace ; if Microsoft
had deployed by correctly following RFC 4941 - We would not have
operational impact and now this discussion.

However, Microsoft did follow RFC 4941 in providing the capability to
enable or disable both the lan interface random IID or the temporary
address show above.  So now given that the temporary address is a solid
workaround that most enterprises use for stability, in essence provides a
“stable” address which is similar to what RFC 7217 provides.  I have been
wondering why RFC 7217 has not taken off with OS vendors and I think the
above is the reason why.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Jared Mauch <[email-masked]>
Date: Sun, 26 Jan 2020 08:40:54 -0500

> On Jan 23, 2020, at 9:08 AM, Fernando Gont <[email-masked]> wrote:
> 

This for me is an example of one of the problems around IPv6.

The IPv6 solution space includes things like:

* Don’t do DHCPv6, do SLAAC
** We forgot to include DNS, so RDNSS
* Do DHCPv6, don’t do SLAAC
** Some hosts won’t do DHCPv6
** Not all hardware does DHCPv6-PD properly
** Not all software does DHCPv6-PD properly
** Not all networks can support DHCPv6-PD

The general discussion for me here is we need to ensure we’re not violating rfc1925[1] 2.1 which at times seems to be blame shifted to operators or vendors.  While everyone has their weaknesses we need to ensure the ecosystem we specify is robust enough.

- Jared

[1] - Yes I know, doesn’t make it any less true though.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 26 Jan 2020 08:40:56 -0500

On Sun, Jan 26, 2020 at 8:26 AM Gyan Mishra <[email-masked]> wrote:

> “privacy” temporary address.  The analogy used in the draft is, the
> stable LAN address in the PSTN world is like publishing your phone number
> in the white pages, and your private temporary address is analogous to
> called ID block for anonymity.
>
> depreciated, it may still be used for existing outgoing connections, while
> deployment considerations, is that the temporary address should be
> disabled by default due to operational impact.  I think this is huge and
> the crux of the issue the IPv6 community has been faced with Day 1.
>
> Quoted from RFC 4941
>
> address show above.  So now given that “disabling” the temporary address is
> a solid workaround that most enterprises use for stability, in essence
> provides a “stable” address which is similar to what RFC 7217 provides.  I
> have been wondering why RFC 7217 has not taken off with OS vendors and I
> think the above is the reason why.
>

    (sorry - Typo above added “disabling” the temp address)

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 26 Jan 2020 08:52:58 -0500

On Sun, Jan 26, 2020 at 8:41 AM Jared Mauch <[email-masked]> wrote:

> The general discussion for me here is we need to ensure we’re not
> violating rfc1925[1] 2.1 which at times seems to be blame shifted to
> operators or vendors.  While everyone has their weaknesses we need to
> ensure the ecosystem we specify is robust enough.
>
> - Jared
>

    Gyan> Agreed.

The beauty behind SLAAC is that it works “out of the box” PNP like features
makes it very user friendly to initiatally deploy.  However, what’s sitting
under the covers in the black box ends up being an operational nightmare.

See my email reply to the last thread and what boils down to the crux of
the issue.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Jan 2020 10:28:52 -0500

> It also means things like my ssh sessions can't last long enough to do large transfers as the address is rotated away. 

If there’s a TCP session holding a reference count on the address, why is it being deleted?  That sounds like a bug, not a problem with privacy addresses.

---

From: Jared Mauch <[email-masked]>
Date: Sun, 26 Jan 2020 11:16:02 -0500

The systems rotate them away over the course of a week. You may not see this in a environment where you use many different networks. If your network is stable, such as an enterprise you will see this. 

Call it a bug if you want to dismiss the design principle but the privacy folks have it wrong here when you break the user with forced rotation for the sake of a principle that may not apply in an enterprise (you generally have no right to privacy here).  

Sent from my iCar

> On Jan 26, 2020, at 10:28 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 Jan 2020 12:42:38 -0500

> they want privacy? I think a general solution should be transparent to

Yes, I agree, it requires explicit configuration.
I agree that this is not a good thing.

    > be achieved with a transparent proxy.

Yes, and I think that more and more LEA will grow ever concerned about this
situation, and it *is* pushing IPv6 adoption.  So, how can we find a happy medium?

    > You might want to take a look at draft-herbert-ipv6-prefix-address-privacy-00.

An interesting read. I'm not sure where it goes.

I would like Locator/Identifier separation.
I wanted SHIM6. LISP would work, I think.
Then privacy needs don't need to screw up efficient routing at the edge.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 26 Jan 2020 11:51:16 -0800

> Then privacy needs don't need to screw up efficient routing at the edge.
Hi Michael,

The problem of LISP is that it potentially includes a cache in the
operator network that can be driven by downstream untrusted users--
hence there is possibility of DOS attack on the cache (this is the
primary reason why LISP hasn't been accepted into Linux).

What we really want is Identifier/Locator routing that neither
requires per flow state to be maintained in the network nor relies on
caches to get reasonable performance.
draft-herbert-ipv6-prefix-address-privacy suggests crypto functions to
map identifiers to locators at the edge.

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 26 Jan 2020 14:59:46 -0500

Tom, your description is somewhat misleading.

On the one hand, LISP replies on per-flow state only in the mapping 
entity.  Not at arbitrary places in the network.

Secondly, if hosts work in terms of identifiers, and the network works 
in temrs of locators, someone has to map them.  You can cache (including 
caching the whole thing), you can ask the host to hold the cache itself. 
  There are other tradeoffs you can make, moving things around.  But you 
can't just magically make the problem disappear.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Sun, 26 Jan 2020 12:16:04 -0800

> can't just magically make the problem disappear.

Joel,

It comes down to how many addresses need to be mapped. It's intuitive
that a higher frequency of address rotation yields more privacy. But
higher frequency of address rotation means more active addresses in
the network. This degenerates to the greatest frequency of change
which would be to give each flow it's own unique address, and this is
also the one case of temporary addresses where we can quantify the
privacy characteristics.

However, giving each flow its own address quickly becomes a scaling
and management problem-- we're talking several billions of active
addresses in some provider networks. Hence, I believe we need mapping
functions that are more N:1 than 1:1 (the latter doesn't scale).
Similar, the ability of the network to delegate and map bundles of
uncorrelated addresses to devices would be useful.

Tom

---

From: Ole Troan <[email-masked]>
Date: Sun, 26 Jan 2020 21:20:23 +0100

The obvious answer is to put the source address in the encrypted payload. It does not have to be in the core header. 
There’s a paper on it somewhere, although I am not sure if that’s where the idea originated. 

Cheers 
Ole

> On 26 Jan 2020, at 21:16, Tom Herbert <[email-masked]> wrote:
>

---

From: Simon Hobson <[email-masked]>
Date: Sun, 26 Jan 2020 20:22:33 +0000

Gyan Mishra <[email-masked]> wrote:

> The beauty behind SLAAC is that it works “out of the box” PNP like features makes it very user friendly to initiatally deploy.

Remember that DHCP for IPv4 generally works "out of the box" for most users. Certainly in the SOHO market, the presence of a built in, auto-configured, and enabled DHCP server in the route means that the user just "plugs it in and it works". By the time you get to a level of network complexity where that isn't the case, then there is normally a network admin either on the staff or hired n as needed.

If that isn't working reliably for users in the IPv6 world then that suggests the various components needed haven't reached the same level of completeness & correctness "mostly" available in the IPv4 world. It isn't an argument that DHCPv6 "doesn't work".

Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jan 2020 09:47:07 +1300

> If that isn't working reliably for users in the IPv6 world then that suggests the various components needed haven't reached the same level of completeness & correctness "mostly" available in the IP…

It's actually a historical accident. At the time that SLAAC was designed, DHCP(v4) wasn't mature and the state of the art in autoconfiguration was Appletalk, Novell IPX, and DECnet Phase IV. It really doesn't matter now. We can't roll the clock back.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jan 2020 09:53:34 +1300

> There’s a paper on it somewhere, although I am not sure if that’s where the idea originated.

Google "SNA: Sourceless Network Architecture" and "IPv6 source addresses considered harmful"

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Sun, 26 Jan 2020 13:35:15 -0800

> Google "SNA: Sourceless Network Architecture" and "IPv6 source addresses considered harmful"

There's also the possibility of putting location information into a
modifiable HBH option (part of draft-herbert-fast-04). Something like:

- End host sends packet with HBH option for location
- First hop in network writes its location into the HBH option. The
location information identifies the hop (e.g. base station in a mobile
network) and is only interpretable in the local network (encrypted for
instance).
- Packet is routed to destination with HBH option in tact.
- At the destination, the HBH option is reflected on return packets
for a flow. End host doesn't do anything else than just reflect.
- At the ingress node to the network, the location information is
decoded. Given this, the ingress forwards the packet to the locator
node by address translation of encapsulation.
- At the locator node, i.e. first network hop upstream of destination
node, the encapsulation or translation is undone and packet is
forwarded to the final destination.

I think this method was first proposed to ensure consistent routing to
the same backend in L4 load balancing. Obvious downsides are the we
need EH to work in the network and there are changes needed in the
hosts.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 26 Jan 2020 21:37:08 +0000

Tom Herbert wrote on 26/01/2020 20:16:
> It's intuitive
> that a higher frequency of address rotation yields more privacy

intuitive, but probably inaccurate because of the a priori assumption 
that privacy is strongly associated with the endpoint identifier.

Nick

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 26 Jan 2020 21:39:30 +0000

From: ipv6 <[email-masked]> On Behalf Of Gyan Mishra

>
> So Microsoft, still being a major stakeholder In the desktop OS arena, as stated in the 2013 presentation above, has implemented RFC 4941 starting with Vista with the MD5 randomize generated IID that is stored and persistent across reboot and only changes if the prefix changes with mobility and a new 128 bit address stable address is generated.

This seems like a good default, no? The business about "privacy" concerns not so much the type of privacy that data encryption would provide, but rather, being able to track an individual in his/her travels. Changing the IID only when the prefix changes should prevent that well enough?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jan 2020 10:59:55 +1300

On 27-Jan-20 10:39, Manfredi (US), Albert E wrote:
...
> This seems like a good default, no? The business about "privacy" concerns not so much the type of privacy that data encryption would provide, but rather, being able to track an individual in his/he…

The IID is normally set *before* the host generates its Link Local address, which is normally before it starts to listen for RAs from which it will learn the current prefix(es).

So you'd have to make the IID for SLAAC independent of the IID for LL (which is of course exactly what RFC4941 does).

   Brian

---

From: Jared Mauch <[email-masked]>
Date: Sun, 26 Jan 2020 19:04:02 -0500

And makes debugging router hashing issues much harder. What is your source address? Which one does the machine use now?

The operation of a network is much harder as a result. Not impossible but harder. Add in the limited value as tracking is far more sophisticated and then scaling issues of ND and this is how you end up with networks without v6. 

I am not a v6 hater, I see it on public WiFi which makes me super happy but I've also had to debug these things and it's very painful. 

Sent from my iCar

> On Jan 26, 2020, at 4:37 PM, Nick Hilliard <[email-masked]> wrote:
> 
> intuitive, but probably inaccurate because of the a priori assumption that privacy is strongly associated with the endpoint identifier.
> 
> Nick
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 26 Jan 2020 19:05:27 -0500

On Sun, Jan 26, 2020 at 5:00 PM Brian E Carpenter <
[email-masked]> wrote:

> ....
> > This seems like a good default, no? The business about "privacy"
> concerns not so much the type of privacy that data encryption would
> provide, but rather, being able to track an individual in his/her travels.
> Changing the IID only when the prefix changes should prevent that well
> enough?
>
> The IID is normally set *before* the host generates its Link Local
> address, which is normally before it starts to listen for RAs from which it
> will learn the current prefix(es).
>
> So you'd have to make the IID for SLAAC independent of the IID for LL
> (which is of course exactly what RFC4941 does).

  Gyan>  Agreed.  So the happy medium achieved for two camps on opposite
ends of the spectrum.

1.  End user privacy on mobile device connected at home or

2.  End user privacy within an enterprise- non existent as IT security and
availability for mission critical applications -IPv6 stability and tracking
ability is the primary objective.

Happy medium achieved:
For both scenarios following RFC 4941 disabling the temporary address and
keeping the modified EUI-64 random IID - provides both privacy with MD5
randomized IID - and with the IID only changing with mobility when you
receive an new RA for SLAAC with mobility from a different subnet which is
what we want from and IT stability perspective.  If you reboot with
permanent storage as most devices have the IID does not change as long as
the prefix is the same.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 26 Jan 2020 20:39:04 -0500

On Sun, Jan 26, 2020 at 7:05 PM Gyan Mishra <[email-masked]> wrote:

> Gyan> Is anyone aware of this vulnerability with RFC 4941 privacy
> algorithm stated below in this RIPE blog.   From this blog it appears that
> OS vendors are using a random number instead thus providing a sufficient
> level of protection.
>

https://labs.ripe.net/Members/johanna_ullrich/ipv6-addresses-security-and-privacy

RFC 4941 <https://tools.ietf.org/html/rfc4941> specifies however a
vulnerable algorithm for the Privacy Extension's interface identifier
generation. Adversaries are able to gain the algorithm's internal state via
a side channel, and predict all future addresses of a host afterwards
contradicting the intended privacy protection. The algorithm has not been
officially revised yet; nevertheless operating systems implementing the
IPv6 Privacy Extension appear to use random numbers instead and thus
provide a sufficient level of protection. Initially, the temporary
addresses of the Privacy Extension have been intended to be assigned in
addition to some sort of static addresses; nowadays, they are also assigned
in absence of static addresses. The latter fact significantly improves
protection against active scanning: the adversary now has to find the
(random or pseudo-random) temporary address instead of the static one which
is a more tedious task.

Kind Regards

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 27 Jan 2020 02:27:07 +0000

From: Gyan Mishra <[email-masked]> 

On Sun, Jan 26, 2020 at 5:00 PM Brian E Carpenter <mailto:[email-masked]> wrote:

> Gyan>  Agreed.  So the happy medium achieved for two camps on opposite ends of the spectrum.

Right. My reaction to Brian's response was, "Exactly!" This holds for any new address the OS wants to configure, obviously including, if it wants for any reason, two addresses with the same prefix.

> 2.  End user privacy within an enterprise- non-existent as IT security and availability for mission critical applications -IPv6 stability and tracking ability is the primary objective.

Or, we should add, the end user privacy when he takes his phone or laptop to Starbucks, and uses it while eating a croissant.

Two more points:

Even finding a way to hide the IP source address does not solve this privacy issue. A hacker can monitor destination addresses too, in that Starbucks joint, to see where someone might be, if IIDs were completely permanent.

And the other, less important point, has anyone else noticed that TV shows have finally gotten a bit of a clue about IP addresses? At least some. Used to be that the presumption was, the source IP address, even on the move, identified an individual, so you could obtain his name. I've noticed lately, the IP address identifies where the bad guy is, at the moment. Progress.

(The addresses are still IPv4, sort of, such as 354.939.535.434. Still haven't found the RFC that describes these. Maybe, IPv7.)

Bert

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Jan 2020 07:43:46 +0000

Hello Tom

This looks similar to the idea of using Mobile IPv6 inside a domain: Hosts in the domain get only ULAs buy default. 
Hosts that need reach back from outside the domain obtain GUAs from common Home Agent that serves the domain.
That GUA becomes their home address. The ULA is the CareOf.
The MIP tunnel happens within the domain unbeknownst of the outside

This way:
- you get a better aggregation factor for privacy, mixed amongst the other devices in the domain.
- the network structure is hidden from the outside observer. It effectively appears as a flat /64.

Cheers,

Pascal

> From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
> Sent: dimanche 26 janvier 2020 22:35
> To: Brian E Carpenter <[email-masked]>
> Cc: 6man <[email-masked]>
> Subject: Re: Address privacy
> 
> There's also the possibility of putting location information into a modifiable HBH
> option (part of draft-herbert-fast-04). Something like:
> 
> - First hop in network writes its location into the HBH option. The location
> information identifies the hop (e.g. base station in a mobile
> network) and is only interpretable in the local network (encrypted for instance).
> - At the destination, the HBH option is reflected on return packets for a flow.
> End host doesn't do anything else than just reflect.
> - At the ingress node to the network, the location information is decoded. Given
> this, the ingress forwards the packet to the locator node by address translation
> of encapsulation.
> - At the locator node, i.e. first network hop upstream of destination node, the
> encapsulation or translation is undone and packet is forwarded to the final
> destination.
> 
> I think this method was first proposed to ensure consistent routing to the same
> backend in L4 load balancing. Obvious downsides are the we need EH to work in
> the network and there are changes needed in the hosts.
> 
> Tom
> 
> >    Brian
> >
> > >
> > > Cheers
> > > Ole
> > >
> > >>> On the one hand, LISP replies on per-flow state only in the
> > >>> mapping entity.  Not at arbitrary places in the network.
> > >>>
> > >>> Secondly, if hosts work in terms of identifiers, and the network
> > >>> works in temrs of locators, someone has to map them.  You can
> > >>> cache (including caching the whole thing), you can ask the host to hold
> the cache itself.
> > >>>  There are other tradeoffs you can make, moving things around.
> > >>> But you can't just magically make the problem disappear.
> > >>
> > >> Joel,
> > >>
> > >> It comes down to how many addresses need to be mapped. It's
> > >> intuitive that a higher frequency of address rotation yields more
> > >> privacy. But higher frequency of address rotation means more active
> > >> addresses in the network. This degenerates to the greatest
> > >> frequency of change which would be to give each flow it's own
> > >> unique address, and this is also the one case of temporary
> > >> addresses where we can quantify the privacy characteristics.
> > >>
> > >> addresses in some provider networks. Hence, I believe we need
> > >> mapping functions that are more N:1 than 1:1 (the latter doesn't scale).
> > >>>>>>> Except that instead of doing it at layer 4, you do it with
> > >>>>>>> IPsec, and extrude that /128 to your machine.  This is already
> > >>>>>>> a thing :-)
> > >>>>>>>
> > >>>>>>>> Another solution I’ve considered is to have a giant anonymity
> > >>>>>>>> mesh, with every ISP’s user participating, and forward flows
> through this
> > >>>>>> Doesn't that require that the users must explicitly configure
> > >>>>>> when they want privacy? I think a general solution should be
> > >>>>>> transparent to
> > >>>>>
> > >>>>>> the user and "just works" to ensure their privacy. That in fact
> > >>>>>> is one of the arguments for NAT. If there is a significantly
> > >>>>>> large enough pool of users behind a NAT device, then the
> > >>>>>> obfuscation is transparent to the use and seems to be pretty
> > >>>>>> good privacy (good enough that law enforcement is concerned
> > >>>>>> about NAT). I suppose a similar effect could be achieved with a
> transparent proxy.
> > >>>>>
> > >>>>> Yes, and I think that more and more LEA will grow ever concerned
> > >>>>> about this situation, and it *is* pushing IPv6 adoption.  So, how can we
> find a happy medium?
> > >>>>>
> > >>>> The problem of LISP is that it potentially includes a cache in
> > >>>> the operator network that can be driven by downstream untrusted
> > >>>> users-- hence there is possibility of DOS attack on the cache
> > >>>> (this is the primary reason why LISP hasn't been accepted into Linux).
> > >>>>
> > >>>> requires per flow state to be maintained in the network nor
> > >>>> relies on caches to get reasonable performance.
> > >>>> draft-herbert-ipv6-prefix-address-privacy suggests crypto
> > >>>> functions to map identifiers to locators at the edge.
> > >>>>
> > >>>> Tom
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> --
> > >>>>> Michael Richardson <[email-masked]>, Sandelman Software
> > >>>>> Works  -= IPv6 IoT consulting =-
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> ----------------------------------------------------------------
> > >>>>> ---- IETF IPv6 working group mailing list [email-masked]
> > >>>>> Administrative Requests:
> > >>>> -----------------------------------------------------------------
> > >>>> --- IETF IPv6 working group mailing list [email-masked]
> > >>>> Administrative Requests:
> > >> -------------------------------------------------------------------
> > >> - IETF IPv6 working group mailing list [email-masked] Administrative

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Jan 2020 16:11:19 +0100

Le 25/01/2020 à 20:57, Ca By a écrit :
> 
> 
> On Sat, Jan 25, 2020 at 11:48 AM Tom Herbert <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      >
>      > Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>      >     > Another solution that could be useful is to do connections
>     through an
>      >     > anonymity concentrator that tunnels your flow to the
>     selected server.
>      >     > The idea here is that your ISP (but it doesn’t have to be
>     your ISP!)
>      >     > has a bunch of anonymity boxes sitting in their data
>     centers, and when
>      >     > you want to connect to foo.com <http://foo.com>
>     <http://foo.com/>, you establish a
>      >     > connection to the anonymity server.   The anonymity server
>     constructs a
>      >     > new 5-tuple using its own fixed IP address.   This is
>     effectively a NAT
>      >     > translation, and of course it can maintain a set of IP
>     addresses large
>      >
>      >     > Another solution I’ve considered is to have a giant
>     anonymity mesh,
>      >     > with every ISP’s user participating, and forward flows
>     through this
>      >     > mesh, treating each customer as an anonymity server.   I
>     think this is
>      >

Re-invent a Tor that's well accepted by society.

Alex

>      > Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>, Sandelman Software Works
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Jan 2020 14:32:44 +0100

Le 28/01/2020 à 02:25, Fernando Gont a écrit :
> On 27/1/20 20:36, Brian E Carpenter wrote:
>> On 28-Jan-20 10:44, Fernando Gont wrote:
>>> On 26/1/20 17:47, Brian E Carpenter wrote:
>>>>>> The beauty behind SLAAC is that it works “out of the box” PNP like 
>>>>>> features makes it very user friendly to initiatally deploy.
>>>>>
>>>>> Remember that DHCP for IPv4 generally works "out of the box" for 
>>>>> most users. Certainly in the SOHO market, the presence of a built 
>>>>> in, auto-configured, and enabled DHCP server in the route means 
>>>>> that the user just "plugs it in and it works". By the time you get 
>>>>> to a level of network complexity where that isn't the case, then 
>>>>> there is normally a network admin either on the staff or hired n as 
>>>>> needed.
>>>>>
>>>>> If that isn't working reliably for users in the IPv6 world then 
>>>>> that suggests the various components needed haven't reached the 
>>>>> same level of completeness & correctness "mostly" available in the 
>>>>> IPv4 world. It isn't an argument that DHCPv6 "doesn't work".
>>>>
>>>> It's actually a historical accident. At the time that SLAAC was 
>>>> designed, DHCP(v4) wasn't mature and the state of the art in 
>>>> autoconfiguration was Appletalk, Novell IPX, and DECnet Phase IV. It 
>>>> really doesn't matter now. We can't roll the clock back.
>>>
>>> Well, we *could* end the pointless religious battle, mandate both SLAAC
>>> and DHCPv6, and let admins and operators run their networks in whatever
>>> way they please.
>>
>> That still doesn't resolve the issue of the lack of feature 
>> equivalence between RAs and DHCPv6,
> 
> Indeed. At the very least, one would have a DHCPv6 route option.
> 
> So far, IIRC the arguments against this have been that a DHCPv6 server 
> couldn't be ain a good position to tell where packets should be routed. 
> However, a number of proposals recently discussed in this working group 
> have failed that criteria (if it ever existed).
> 
> Folks that need/want to "enforce" policy, should be able to do so. 
> Besides, they should be able to rely on any automatic configuration 
> mechanism rather than having to duplicate the effort in both protocols.
> 
> e,g,-, My ISPs CPE does network configuration (addresses `other info) 
> with both SLAAC and DHCPv6 -- because they have to make sure it works 
> with whatever stuff their users plug.
> 
> Part of the outcome is that while my box does rfc7217+rfc4941, I also 
> configure dhcpv6 addresses, and the dhcpv6 server generates IIDs in a 
> predictable manner.
> 
> 
>> and there would some interesting discussions around which options need 
>> to be MTI. For example, is 
>  > PD mandatory to implement? It would be interesting to see a draft 
> (v6ops, perhaps?). However, I imagine that the constrained node people 
> would have something to say if we changed this to a MUST:
>>
>> "...all hosts SHOULD implement address configuration via DHCPv6." 
>> [RFC8504, section 6.5]
> 
> My understanding is that the constrained node folks already have to 
> deviate a bit from plain IPv6. So I guess that could be worked out.
> 
> It would seem to me the problem here is more of Android than anything else.

It is good to try to identify and describe a problem.

To me, there is indeed a problem of lack of support of DHCPv6 in Android.

This problem is materialized at home, and in cellular networks.

At home, the use of DHCPv6 by my CPE makes that Android gets disconnected.

On cellular, the lack of DHCPv6 in Android makes that chip manufacturer 
does not allow DHCPv6 through for anybody else, including DHCPv6-PD 
which has no equivalency in SLAAC.

These are facets of a problem.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 Jan 2020 13:38:55 +0000

Lorenzo Colitti wrote on 28/01/2020 10:14:
> Second: for many networks, the desired saturation point is one
> address. I think we here all agree that is a bad idea

This seems to be a curiously simplistic view of a complex policy issue 
for which there is no single answer.

Specifically we don't all agree that this is a bad idea and many people 
in this working group and others have been very clear that whether this 
is a good or a bad idea depends on the situation.

Nick

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 Jan 2020 14:24:05 +0000

Exactly!

Also, I hope this discussion does not turn into a router vendor against a host vendor for who takes the blame in case of an outage. The real question is what gets us the best IPv6 service for the end user and the network admin. 

As you point out, this discussion has already isolated environments, e.g., home when all must work automagically but the multicast pressure is low, and corporate/marge conference where there's a control center and a need for visibility. 

For home, there are a limited number of devices and if the hosts respect whatever best practice, there should not be a problem in normal conditions. There can be misbehavior on the host side, leaks on the router side. I guess the router would malloc to death and reboot when saturated, and at home that would be OK if rare enough. So I just expect "no limits" by default in the home GW. Which mean that the router would automagically have a state maintained for the user addresses for their requested lifetimes, with a better user experience when the address is allocated - Jen's point-, but not much difference.

In a managed environment things are different. If a NOC configures the router to say "sorry, network is full" when the host has one address, and the users complain, it will be between the users and the NOC, not between the router and the host. The network, devices and protocols are not to blame. The NOC can already set that limit today on a variety of products. But for the lack of explicit signaling, the addresses that the network maintains may not be the ones the device wants to use.

On the SAVI point, RFC 8505 makes SAVI more efficient by maintaining a real state as opposed to snooping protocols. Current SAVI experience shows limitations with silent hosts (e.g., a printer that does not expose an address, did DAD last year and still expects to be reachable on that address), mobility (hard to differentiate with impersonation attack), and others. See also with https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/ how it is a lot easier to do a SEND equivalent with a registration.

Cheers;

Pascal

> From: ipv6 <[email-masked]> On Behalf Of Nick Hilliard
> Sent: mardi 28 janvier 2020 14:39
> To: Lorenzo Colitti <lorenzo=[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: SLAAC vs DHCPv6 (II)
> 
> This seems to be a curiously simplistic view of a complex policy issue for which
> there is no single answer.
> 
> Specifically we don't all agree that this is a bad idea and many people in this
> working group and others have been very clear that whether this is a good or a
> bad idea depends on the situation.
> 
> Nick
>

---

From: [email-masked]
Date: Tue, 28 Jan 2020 15:27:10 +0100

> This seems to be a curiously simplistic view of a complex policy issue for which there is no single answer.
> 
> Specifically we don't all agree that this is a bad idea and many people in this working group and others have been very clear that whether this is a good or a bad idea depends on the situation.

Indeed.

In the context of 4941bis last call, it might be prudent of us to revisit this change:

https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-05#section-8
6.  Temporary addresses are *not* disabled by default.

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Jan 2020 23:59:00 +0900

Changing subject because many participants are likely to just ignore yet
another "SLAAC vs DHCPv6" thread. :-)

> 6.  Temporary addresses are *not* disabled by default.

Saying that temporary addresses should be disabled by default (assuming
hosts actually do that) seems like a terrible privacy problem. It means
that by default, a host that doesn't change prefix will use the same IPv6
address to communicate with *everyone* on the internet until the end of
time. That provides lots of opportunities for cross-site tracking, and the
user can do very little to protect themselves because they don't have
control over IP addressing like they do over higher-layer identifiers
(e.g., users can clear cookies, or use different browser profiles or
different browsers/apps for different sites).

I don't think 4191bis should advance if it says that privacy addresses are
disabled by default. It would be a strong statement by the IETF that we
don't care about privacy of IP addresses and would be a terrible signal to
send.

Instead of disabling, why not change the default of the number of addresses
maintained? For example, instead of maintaining 1 permanent + 1 valid + 7
deprecated, why not just default to maintaining 1 permanent + 1 valid + 1
deprecated. That means that applications would have to re-establish their
connections once a day instead of once every 7 days. But if they use
privacy addresses, they already need to re-establish connections after 7
days. And they can always use not to use privacy addresses via the
appropriate socket option.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2020 10:13:38 -0500

I suspect this has been considered before, but I’m curious if it just died because NAT66==evil: why not have the obfuscation happen at the first hop?

The way this would work is that you’d just do SLAAC and get an address.   If you want to receive connections, they come to that address; nothing need be done.  According to local policy, outgoing connections could be mapped, so that at the first hop router, the source address is translated from the fixed source address to a temporary per-flow address.  Or they could be not mapped, depending on the host policy.  This would require added functionality on the router, and obviously doesn’t give the same privacy characteristics on the first hop link, but also doesn’t require multicast defense of every temporary address.

---

From: Richard Patterson <[email-masked]>
Date: Tue, 28 Jan 2020 15:14:11 +0000

On Tue, 28 Jan 2020 at 14:59, Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

>
> Instead of disabling, why not change the default of the number of
> addresses maintained? For example, instead of maintaining 1 permanent + 1
> valid + 7 deprecated, why not just default to maintaining 1 permanent + 1
> valid + 1 deprecated. That means that applications would have to
> re-establish their connections once a day instead of once every 7 days. But
> if they use privacy addresses, they already need to re-establish
> connections after 7 days. And they can always use not to use privacy
> addresses via the appropriate socket option.
>

So simply recommending that Valid Lifetime is no more than 2x Preferred
Lifetime?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jan 2020 00:31:37 +0900

On Wed, Jan 29, 2020 at 12:13 AM Ted Lemon <[email-masked]> wrote:

> why not have the obfuscation happen at the first hop?

For outgoing connections, that's what we do in IPv4, and it has the same
disadvantages. I'd say the most important are: a) it breaks protocols that
encode the IP address in the stream and requires those protocols to
implement NAT traversal, and b) it requires periodic keepalives to keep the
mapping alive.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2020 10:40:37 -0500

On Jan 28, 2020, at 10:31 AM, Lorenzo Colitti <[email-masked]> wrote:
> For outgoing connections, that's what we do in IPv4, and it has the same disadvantages. I'd say the most important are: a) it breaks protocols that encode the IP address in the stream and requires those protocols to implement NAT traversal, and b) it requires periodic keepalives to keep the mapping alive.

Hopefully we’re not doing (a) anymore, although I suppose maybe SIP still does.  So for protocols that do this, you don’t get privacy.   Since HTTP doesn’t do it, that takes care of 99.99% of the use cases an end user cares about.   O(0) end users use SIP or FTP.

As for (b), sure, but that’s not really such a big deal in modern times.   Just keep a fast working set and a slow swapped-out set; if something hasn’t been active in the past fifteen minutes, remove it from the working set to keep lookups fast, but if you get something targeted for an unknown address that looks sensible, as time permits look it up in the slow table.  If somebody DDoSes you, long-lived idle connections might suffer, but otherwise it works, and when you are being DDoSed, you can easily do lookups at whatever rate is appopriate, and drop traffic to unknown addresses in excess of that rate on the floor.

Of course, all of this assumes that router vendors get it right (Hi, UNH!).

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 12:55:34 -0300

On 28/1/20 03:13, Lorenzo Colitti wrote:
> On Tue, Jan 28, 2020 at 2:59 PM Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > Well, the whole thread entitled "RFC4941bis: consequences of many
>     addresses for the network" seem to be in conflict with RFC7934. --
>     i.e., folks have concerns about nodes configuring an arbitrary
>     number of addresses at will.
> 
> I think we should try to dig deeper into the reasons for this and see if 
> we can come to a compromise on some of them.

My view is that this is out of scope for rfc4941bis (being RFC4941 a 
widely implemented and deployed spec), but the topic certainly deserves 
analysis in a different document.

> 
>   * If the concern is that the host could configure "too many addresses"
>     - This sort of behaviour is not in anyone's interest (either host or
>     network), so I don't think it will happen in practice. There's also
>     an easy way to fix it: just drop the packets past N addresses.

The question is that the host does not know what's "too many". To many, 
in a way, is in the eyes of the operator or network admin, that run the 
network and possibly know what may break if the group of connected hosts 
exceed some number of configured addresses.

COnveying some sort of policy information in SLAAC helps hosts what's 
"too many". Similarly, a DHCPv6 server can "enforce" such policy, based 
on its knowledge of the network.

>   * If the concern is load on the network or tracking, I think we can
>     come up with a reasonable engineering compromise here.

I'm curious what would such compromise be.

>   * If the concern is that the host should use exactly the single
>     address (or low-N number of addresses) that is assigned by the
>     network, then that has the downsides discussed in RFC 7934 and
>     that's a problem.

As noted, I think that when it comes to RFC4941, the cat is out of the 
box, already. Besides, we're talking about a dozen address per host, 
which I guess is the minimum one could expect in the context of RFC7934.

That said, the issue is worth exploring, because it certainly affects 
more agressive approaches such as "one address per application".

> 
>     I agree. I see GRAND as a useful hack for the lack of the real
>     thing. It does not maintain nor tears down a binding. It is lacking
>     essential ingredients like a lifetime. It does not prevent address
>     theft and impersonation.
> 
>     Could this group seriously consider RFC 8505?
> 
> 
> The problem with RFC 8505 is the conflict with the text in RFC 7934 
> section 8 which recommends that networks allow devices to create 
> addresses at will. Requiring use of RFC 8505 by general purpose hosts 
> violates those recommendations.

Creating addresses at will seems, exactly, the concern being expressed 
by operators on this list. I'm not arguing one way or another, but just 
noting that "creating addresses at will" seems to be at odds with what 
the ops people are expressing.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 28 Jan 2020 08:27:32 -0800

On Jan 28, 2020, at 6:59 AM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> Instead of disabling, why not change the default of the number of addresses maintained? For example, instead of maintaining 1 permanent + 1 valid + 7 deprecated, why not just default to maintaining 1 permanent + 1 valid + 1 deprecated. That means that applications would have to re-establish their connections once a day instead of once every 7 days. But if they use privacy addresses, they already need to re-establish connections after 7 days. And they can always use not to use privacy addresses via the appropriate socket option.

That seems plausible, but how about going one step further and for clients just have one temporary and one deprecated address, without any stable address? If the client is not running any server, that makes address management much simpler.

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2020 11:45:15 -0500

> That seems plausible, but how about going one step further and for clients just have one temporary and one deprecated address, without any stable address? If the client is not running any server, t…

And breaks any stable sessions at the expiry interval, unless the protocol adds a session layer.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 Jan 2020 16:51:03 +0000

Tom Herbert wrote on 28/01/2020 03:10:
> Yes, that's the "always on" network application that would allow
> address tracking and identification at even high frequency of address
> change. An exploit based on that is described in section 4.4 of
> draft-herbert-ipv6-prefix-address-privacy-00. I believe the only way
> to defeat this exploit would be single use (per flow), uncorrelated
> address.

persistent identification for apps (browser / mobile / etc) is handled 
using a variety of mechanisms, primarily client fingerprinting.  The 
best known example of client fingerprinting would be application 
cookies.  IP addressing information is only one input source and 
probably one of the less important ones because of the poor correlation 
between ip addresses and end users (e.g. large 1:n nats), and ip address 
changes (office to train wifi, to in-car cellular to home broadband, to 
coffee shop, etc).

Overall privacy addresses fall into the category of things that seemed 
like a good idea at the time but in retrospect their usefulness fell 
away as people worked out other, more accurate ways to track end users 
and end user devices.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 Jan 2020 16:51:45 +0000

> protocol adds a session layer.

in which case you've defeated the entire purpose of the privacy address.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 13:44:28 -0300

On 28/1/20 06:02, Lorenzo Colitti wrote:
> But it does violate the recommendation if you use it to enforce how many 
> addresses the host can use. The text is:
> 
>     Due to the drawbacks imposed by requiring explicit requests for
>     address space (seeSection 4  <https://tools.ietf.org/html/rfc7934#section-4>), it is RECOMMENDED that the network
>     give the host the ability to use new addresses without requiring
>     explicit requests.  This can be achieved either by allowing the host
>     to form new addresses autonomously (e.g., via SLAAC) or by providing
>     the host with a dedicated /64 prefix.  The prefix MAY be provided
>     using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
> 
> 
> If the network is able to deny a registration, then it's not a 
> registration, it's a request.

The network always wins. Folks could run SAVI, and enforce one addrees 
per node, even with SLAAC. Yes, you're address wouldn't be rejected .. 
it just wouldn't work. The outcome is the same.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jan 2020 09:03:19 -0800

> changes (office to train wifi, to in-car cellular to home broadband, to

Nick,

The problem isn't in identification for apps, it's that the fact that
the logs created by the app correlate user identity with an IP
address. Given that correlation, the log could conceivably be used to
identify participants in completely unrelated communications. Using IP
addresses to identify individuals involved in communications does
happen, there are a number of instances noted on the web particularly
in law enforcement.

Tom

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Jan 2020 12:04:19 -0500

Fernando Gont <[email-masked]> wrote:
    >> IIRC that was tried a few years ago and did not go anywhere (I think Suresh
    >> has more details). >
    >> We could try again, though - if it's true that the main reason that
    >> operators want DHCPv6 is tracking, then it could be a good middle ground
    >> between devices that want SLAAC's ability to form addresses without
    >> permission and networks that want DHCPv6's tracking abilities.

    > I don't believe the motivation is tracking, but some sort of control,
    > including:
    > * logging

I think that the key activity they want is auditing.
(Sorry to be pendantic here, but I think it might matter to future direction)

The log provides that, but if you can come up with a different mechanism then
that would be fine too.  DHCPv6 provides the audit through a log.

But for instance, if SEND were used, such that the address could be linked
to a public key/certificate which was in a certificate used for 802.1X
(perhaps enrolled autonomically), then that would satisfy the audit needs
without necessarily resulting in a new source of data with a vulnerability to
exfiltratration.

    >> If we do this it's important that the semantics only support tracking
    >> existing addresses and not requesting addresses. Otherwise there will be a
    >> conflict with the recommendations in RFC 7934 section 8 - and it would
    >> basically be identical to IA_NA which is already a standard.

    > Well, the whole thread entitled "RFC4941bis: consequences of many addresses
    > for the network" seem to be in conflict with RFC7934. -- i.e., folks have
    > concerns about nodes configuring an arbitrary number of addresses at will.

Yes.
I think that the thing that we are realizing is that 4941 doesn't give us
that much privacy for residential (or 3G/LTE!) situations.

Stable private addresses which are not manufacturer assigned EUI-48/64
derived are probably almost as good.  Per-provider-domain randomized L2 MAC
addresses with EUI-derived IIDs are possibly equivalent, except that we don't
have a direct DAD mechanism for that layer. (The IPv6 LL DAD is good here, as
much as it is rather a layer violation)

On the other hand, the places where 4941 works, it works because the
anonymity set is large.   In those situations, where it works, we need to make
sure that we do not wind up with hard-to-diagnose failure cases due to
policies (or implementation bugs) on routers with respect to number of NCE.

There are interactions that we should be aware of with L2 bridging and
Proxy-ND such that the IPv6-address:L2-address ratios could legitimately
vary a *lot*.

So, I'm not entirely sure what the motivation for 4941bis is (Internet
Standard?), but it seems to me that we are not solving the right problem
here.

I actually think that there is an entire WG worth of effort here.

    >> Note that 6man is working another way of getting this information to the
    >> network, see the "multicast NA to ff02::2 whenever an address is
    >> configured" proposal in draft-linkova-6man-grand.

    > I don't think that's registration in the same sense. For Jen's proposal, it's
    > "best effort" registration. For logging, you need to implement a reliability
    > mechanism. As we keep putting more state into SLAAC, it becomes more of AAC
    > than SLAAC. And IPv6 automatic configuration as a whole becomes harder and
    > harder to explain to newcomers, so to speak.

Agreed, because AFAIK, the router can't send a NAK.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 14:06:14 -0300

> That seems plausible, but how about going one step further and for clients just have one temporary and one deprecated address, without any stable address? If the client is not running any server, t…

rfc4041 bis already allows for that.

The only thing is that if the Preferred Lifetime is 1 day, and Valid 
Lifetime is 2*Preferred Lifetime, and you only do temporary addresses, 
then your sessions (e.g. SSH) cannot span past one day, *unless* we 
recommend that invalid addresses are still okay for established connections.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 14:11:22 -0300

On 28/1/20 14:04, Michael Richardson wrote:
[....]
> Standard?), but it seems to me that we are not solving the right problem

In summary:

* Address flaws in RFC4941

* Allow for temporary-only deployments

* Enable temporary addresses by default, following deployed practice

Thanks,

---

From: Fred Baker <[email-masked]>
Date: Tue, 28 Jan 2020 09:44:39 -0800

+1 on this. We can discuss whether a temporary address should have a limited lifetime or whether a given interface might have at most some number of temporary addresses at any given time, but to say that in the default (e.g., usual) case each system has zero seems like a bad idea.

> Changing subject because many participants are likely to just ignore yet another "SLAAC vs DHCPv6" thread. :-)
> 
> Saying that temporary addresses should be disabled by default (assuming hosts actually do that) seems like a terrible privacy problem. It means that by default, a host that doesn't change prefix will use the same IPv6 address to communicate with *everyone* on the internet until the end of time. That provides lots of opportunities for cross-site tracking, and the user can do very little to protect themselves because they don't have control over IP addressing like they do over higher-layer identifiers (e.g., users can clear cookies, or use different browser profiles or different browsers/apps for different sites).
> 
> I don't think 4191bis should advance if it says that privacy addresses are disabled by default. It would be a strong statement by the IETF that we don't care about privacy of IP addresses and would be a terrible signal to send.
>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Jan 2020 12:46:31 -0500

On Tue, Jan 28, 2020 at 12:11 PM Fernando Gont <[email-masked]>
wrote:

> > That seems plausible, but how about going one step further and for
> clients just have one temporary and one deprecated address, without any
> stable address? If the client is not running any server, that makes address
> management much simpler.
>

   The main reason this topic comes has up is due to possible impact of
usage of the temporary address when it gets deprecated with long lived
session.  That’s the crux of why this topic is critical and has severe
operational impact. When the address changes for long lived connections
from the deprecated temporary address to the new preferred address, the
session would terminate and have to re-establish, which is impacts the
user.  Maybe a change to the behavior as how this works is that the long
lived flow remains active on the deprecated temporary address indefinitely
until the flow is terminated via graceful TCP close.  This would allow us
to maintain privacy extension temporary address enabled by default change
to benefit privacy advocates and also eliminate impact for enterprise users
where availability and stability is utmost importance.  The second issue is
maintaining of a multiple addresses on the end host from an operations
perspective if that can be limited.  One idea to accomplish this is that if
the privacy temporary address is enabled by default, that is if we are able
to resolve the operational impact of long lived sessions when the temporary
address changes - how can we minimize the number of active addresses per RA
slaac address.  Allow the interface stable random address to be active only
if the temporary privacy address is disabled - non default scenario.   Once
the temporary address is enabled default scenario- and preferred, it is now
used for both incoming and outgoing connections and the interface “stable”
random address is now disabled.  This will help from an operations
perspective that all flows in/out now all use the same privacy address.  We
can limit the number of temporary addresses to 2 which would only occur
during transition to the new preferred address.  In a normal state when the
address has not hit the lifetime expire timer, only a single GUI address
exists on the host plus the link local.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Jan 2020 12:59:58 -0500

On Tue, Jan 28, 2020 at 12:46 PM Gyan Mishra <[email-masked]> wrote:

>> This operational impact issue with the temporary address changing for
>> long lived sessions  actually existed as well with DHCPv6 with  server
>> redundancy when state sharing did not exist and required a split scope
>> configuration.
>
>
Now with DHCPv6 failover protocol for redundancy the same scope can be used
between servers as stare sharing now works.

DHCPv6 failover protocol
https://tools.ietf.org/html/rfc8156

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Jan 2020 07:23:58 +1300

On Wed, 29 Jan 2020, 06:47 Gyan Mishra, <[email-masked]> wrote:

>> recommend that invalid addresses are still okay for established
>> connections..
>
>
>
> session.

Devices and their end-users that desire address privacy are unlikely to
have long lived connections.

Can you provide an example of a common long lived connection that would
occur with a laptop or smartphone? I can't think of one.

Even back in the early 1990s, when fixed location desktops were the main
personal computing device, long lived client connections were rare. If you
wanted a reliable long lived connection for something, you didn't use your
desktop, you used the hosts/servers that were in computer rooms protected
by UPS.

That’s the crux of why this topic is critical and has severe operational
> impact. When the address changes for long lived connections from the
> deprecated temporary address to the new preferred address, the session
> would terminate and have to re-establish, which is impacts the user.  Maybe
> a change to the behavior as how this works is that the long lived flow
> remains active on the deprecated temporary address indefinitely until the
> flow is terminated via graceful TCP close.  This would allow us to maintain
> privacy extension temporary address enabled by default change to benefit
> privacy advocates and also eliminate impact for enterprise users where
> availability and stability is utmost importance.  The second issue is

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2020 13:31:13 -0500

> in which case you've defeated the entire purpose of the privacy address.

No, you haven’t.  You just aren’t getting privacy with that connection.  You still get it with all your HTTP connections.   When I ssh into my server at work, they know who I am; this isn’t a problem for me.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 15:21:12 -0300

On 28/1/20 14:46, Gyan Mishra wrote:
> 
> 
> On Tue, Jan 28, 2020 at 12:11 PM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
[....]
>      > That seems plausible, but how about going one step further and
>     for clients just have one temporary and one deprecated address,
>     without any stable address? If the client is not running any server,
>     that makes address management much simpler.
> 

FWIW, this was a typo (I meant "RFC4941").

>     connections.

BUt the problem is not in RFC4941, but in the lack of an API for apps to 
specify the properties they expect from the underlying addresses.

>  That’s the crux of why this topic is critical and has severe 
> user. 

If anything, the session would break when the address becomes invalid 
(the Valid Lifetime" expires) -- not when another address becomes 
"preferred".

That said, one can always recommend or give the option to maintain 
established sessions that employ invalid addresses.

> Maybe a change to the behavior as how this works is that the long 
> lived flow remains active on the deprecated temporary address 
> indefinitely until the flow is terminated via graceful TCP close.

You don't need to care about TCP state. Just check if there's a PCB 
associated with the address (whatever the upper protocol is).

>  This 
> would allow us to maintain privacy extension temporary address enabled 
> by default change to benefit privacy advocates and also eliminate impact 
> for enterprise users where availability and stability is utmost 
> importance.  The second issue is maintaining of a multiple addresses on 
> the end host from an operations perspective if that can be limited.  One 
> idea to accomplish this is that if the privacy temporary address is 
> enabled by default, that is if we are able to resolve the operational 
> impact of long lived sessions when the temporary address changes - how 
> can we minimize the number of active addresses per RA slaac address.  
> Allow the interface stable random address to be active only if the 
> temporary privacy address is disabled - non default scenario. 

That's not correct: the stable address is there for a reason: e.g. 
receiving incoming connections.

>  Once the 
> temporary address is enabled default scenario- and preferred, it is now 
> used for both incoming and outgoing connections and the interface 
> “stable” random address is now disabled.

Quite the contrary: if possible, you would *prevent* incoming 
connections on temporary addresses. -- e.g. there's no reason to allow 
port-scans on your temporary addresses just because you happened to 
communicate with a rogue web site.

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 Jan 2020 20:19:19 +0100

> On 28 Jan 2020, at 19:31, Ted Lemon <[email-masked]> wrote:
> 

We should probably be a bit more careful with terms here. A temporary address does not give the user privileges. It might at best avoid leaking an identifier that can be used to correlate the user’s activity. 

Cheers 
Ole

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jan 2020 11:50:44 -0800

On Mon, Jan 27, 2020, 7:57 PM Fernando Gont <[email-masked]> wrote:

> On 28/1/20 00:10, Tom Herbert wrote:
> > On Mon, Jan 27, 2020 at 5:36 PM Fernando Gont <[email-masked]>
> wrote:
> >>
> >> On 26/1/20 18:37, Nick Hilliard wrote:
> >> In many cases, it is: you log in to fb with a given address, and reuse
> >> that address to do other stuf
> >>
> Agreed. That said, temporary addresses, for obvious reasons mitigates
> activity correlation over time -- certainly not to the same extent that
> the paranoid "one address per flow" would.
>

Fernando,

The rationale for temporary addresses may be obvious, but I don't believe
anyone has yet quantified the effects. For instance, RFC4941 is thirteen
years old, is there any evidence that it has materially improved anyone's
privacy? (I'm not being cynical, but I think it's a fair question).

One might compare this to the policy of some sys admins that users need to
change passwords regularly. The rationale is similar, but that practice has
been most debunked as not improving security and in fact is more of a
burden to users that providing any real value.

Tom

---

From: [email-masked]
Date: Tue, 28 Jan 2020 21:09:51 +0100

Tom,

> happen, there are a number of instances noted on the web particularly

is your concern about correlation done by a man in the middle?
or is it the end-points? The operators of those end-points have built an enormous marketplace to trade this information behind your back. temporary addresses will not help against surveillance capitalism.

Temporary addresses doesn't in it's default setting solve the problem of correlation either.
Or should users ensure that they used services that shouldn't be correlated on different days? ;-)
And ensure that they never tainted an address by using it for authentication somewhere.

7217 iids and temporary addresses have the same privacy properties, if you look in table 1 in 7721.
separated by the address lifetime.

A natural consequence of this is that to protect against correlation at layer 3 (all the other tracking would still happen) you need a new address per connection. with a lifetime equal to the connection lifetime.
The network's response to that is likely to assign a static /64 to each host. So now, you can correlate on the prefix instead.

“Addressing can follow topology or topology can follow addressing; choose one” – Y. Rekhter

Ole

---

From: Ca By <[email-masked]>
Date: Tue, 28 Jan 2020 12:13:46 -0800

> privacy? (I'm not being cynical, but I think it's a fair question).

Anecdotally, i would say unequivocally yes at a large scale eyeballs
network, random iid has materially improved security of the host. The
inability to do network scanning is huge.

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Jan 2020 09:38:37 +1300

> privacy? (I'm not being cynical, but I think it's a fair question).

It depends. What were the privacy goals RFC3041/4241 designed to achieve
and does it achieve them?

It isn't reasonable to come up with a different set of privacy goals that
RFC3041/4241 weren't designed to satisfy and then declare 3041/4241 is a
privacy failure because it doesn't satisfy them.

Privacy isn't binary, there are different privacy threats and different
parties to be private from. That means needing different privacy mechanisms
to suit the different privacy threat models.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jan 2020 12:57:00 -0800

On Tue, Jan 28, 2020 at 12:38 PM Mark Smith <[email-masked]> wrote:
>>> > On Mon, Jan 27, 2020 at 5:36 PM Fernando Gont <[email-masked]> wrote:
>>> >>
>> The rationale for temporary addresses may be obvious, but I don't believe anyone has yet quantified the effects. For instance, RFC4941 is thirteen years old, is there any evidence that it has materially improved anyone's privacy? (I'm not being cynical, but I think it's a fair question).
>
>
> It depends. What were the privacy goals RFC3041/4241 designed to achieve and does it achieve them?
>
> It isn't reasonable to come up with a different set of privacy goals that RFC3041/4241 weren't designed to satisfy and then declare 3041/4241 is a privacy failure because it doesn't satisfy them.
>
> Privacy isn't binary, there are different privacy threats and different parties to be private from. That means needing different privacy mechanisms to suit the different privacy threat models.
>
Ole,

I think the privacy goals of RFC4941 are clearly articulated as
addressing the problem of correlations that can be made on
identifiers. From the draft:

"
Anytime a fixed identifier is used in multiple contexts, it becomes
possible to correlate seemingly unrelated activity using this
identifier.

   The correlation can be performed by

   o  An attacker who is in the path between the node in question and
      the peer(s) to which it is communicating, and who can view the
      IPv6 addresses present in the datagrams.

   o  An attacker who can access the communication logs of the peers
      with which the node has communicated.
"

I think this should read "Anytime an identifier is used in multiple
contexts", that is drop the "fixed".

The proposed solution is temporary addresses. But then the question
quickly becomes how temporary do those addresses need to be to address
the problem of correlations? The draft only says "Temporary addresses
are used for a short period of time (typically hours to days) and are
subsequently deprecated.". That's pretty vague. For instance, suppose
a specifically user asks "How often do I need to change addresses to
ensure my privacy?".  Section 3.5 tries to address the question, but,
again is non-committal and makes no normative recommendation. I'd also
note that the text in RFC4941 is pretty much unchanged from RFC4941,
however the sophistication and data collection capabilities of would
be attackers surely have changed since 2013 so it seems like this
section should be revisited in light of that.

Tom

>
>>
>> One might compare this to the policy of some sys admins that users need to change passwords regularly. The rationale is similar, but that practice has been most debunked as not improving security and in fact is more of a burden to users that providing any real value.
>>
>> Tom
>>
>>
>>>
>>> Thanks,
>>> --
>>> Fernando Gont
>>> SI6 Networks

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Jan 2020 15:57:54 -0500

On Tue, Jan 28, 2020 at 1:24 PM Mark Smith <[email-masked]> wrote:

> Gyan> For the home or Starbucks user it would be rare to have long lived
> connections.  Maybe a weekend or all week gaming marathon.
>

   Joking aside, enterprise space is the camp that would have long lived
connections primarily for 24x7 client/server mission critical revenue
generating applications, Point of sale applications, 24x7 Call Centers to
name a few.  I am sure there are many other enterprise scenarios.  Cloud
servers  using Cloud Foundary or Openstack Neutron or any logical
virtualization network layer for server to server communications using
SLAAC.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Bob Hinden <[email-masked]>
Date: Tue, 28 Jan 2020 13:35:52 -0800

I agree.

> Instead of disabling, why not change the default of the number of addresses maintained? For example, instead of maintaining 1 permanent + 1 valid + 7 deprecated, why not just default to maintaining…

If the concern with privacy addresses is that a node might have a large number of these addresses, then this seems reasonable to me.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 18:13:25 -0300

On 28/1/20 16:50, Tom Herbert wrote:
> 
> 
> On Mon, Jan 27, 2020, 7:57 PM Fernando Gont <[email-masked] 
>      > On Mon, Jan 27, 2020 at 5:36 PM Fernando Gont
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >>
> The rationale for temporary addresses may be obvious, but I don't 
> believe anyone has yet quantified the effects. For instance, RFC4941 is 
> thirteen years old, is there any evidence that it has materially 
> improved anyone's privacy? (I'm not being cynical, but I think it's a 
> fair question).

I don't think you can quantify privacy. What would be the units for that?

There's secrecy and not-secrecy. But with these things, you simply 
mitigate (to some extent) the ability to correlate network activity.

> One might compare this to the policy of some sys admins that users need 
> to change passwords regularly. The rationale is similar, but that 
> practice has been most debunked as not improving security and in fact is 
> more of a burden to users that providing any real value.

I don't think it has been debunked. Certainly, if you change your 
password, you limit the ability of the attacker that had obtained your 
password from re-using the same credentials. (assuming they are not used 
for a system where they can install backdoors, etc.). Most things we 
emply for security have an associated lifetime...

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 18:24:04 -0300

> or is it the end-points? The operators of those end-points have built an enormous marketplace to trade this information behind your back. temporary addresses will not help against surveillance capi…

Like everything, given enough capacity/budget, you're always toast.

The fact that a mitigation does not work for more powerful actors 
doesn't mean that it's not worth doing.

If temporary addresses limit, to some extent, correlation, they are 
doing their thing. Whether that's perfect or far from perfect is a 
different thing.

> And ensure that they never tainted an address by using it for authentication somewhere.

Indeed. Temporary addresses are sort of a middle-ground between stable 
addresses, and one-address-per-flow.

> A natural consequence of this is that to protect against correlation at layer 3 (all the other tracking would still happen) you need a new address per connection. with a lifetime equal to the conne…

Indeed. Please see above.

> The network's response to that is likely to assign a static /64 to each host. So now, you can correlate on the prefix instead.

That depends on the scenario. For small/medium sized networks, they may 
employ a flat /64 for all, in which case temporary addresses do their thing.

In other networks, they may employ a different strategy. One size 
doesn't need to fit all.

> “Addressing can follow topology or topology can follow addressing; choose one” – Y. Rekhter

Indeed, the bits you get to play with are the ones that are *not* 
topology-dependent. When you do play with the topology-dependent bits, 
that's when things become much more complex.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 19:07:47 -0300

On 28/1/20 17:57, Tom Herbert wrote:
> subsequently deprecated.". That's pretty vague. 

The timer definition is pretty specific, on the other hand.

> For instance, suppose
> again is non-committal and makes no normative recommendation. 

The answer is obviously: the more you reuse an address, the more you 
allow the window/ability of correlation. Only the app knows the specific 
needs.

Temporary addresses are a middle-ground: even the app being unaware 
about the underlying mechanisms, you get some mitigation. Obviously, 
temporary addresses are time-bound as opposed to flow-bound, since that 
leads to fewer addresses in use, at the expense of allowing some 
correlation.

RFC4941 is a "default" mechanism that improves things a bit. If we were 
also to stress that they shouldn't be used for receiving connections, 
and hint OSes that they are free to drop e.g. incoming SYNs on them, 
then you get a lot more of value.

And yes, if you want to improve things even better, you need an API for 
the addressing capabilities. Shame on us that have produced so many 
different address properties without a way for apps to properly leverage 
them.

> I'd also

Please flag the text.

(One thing that did change is people's awareness... not necessarily the 
capabilities)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 19:42:45 -0300

On 28/1/20 18:35, Bob Hinden wrote:
[....]
> If the concern with privacy addresses is that a node might have a large number of these addresses, then this seems reasonable to me.

In this respect, we have a few knobs to play with:

1) Valid Lifetime and Temporary Lifetime timers

In principle, N = Valid Lifetime / Preferred Lifetime, is the maxium 
number of addresses that a host may have at a given time. So far, we 
have a VL of one week, and a PL of 1 day, resulting in seven addresses.

If we change that ratio, as Lorenzo suggested, that would change the 
maximum number of addresses at any given time.

That said, the maximum number of N addresses should only actually be 
seen on the network if long-lived sessions were employing each of the N 
addresses. Otherwise, the host would *have* N addresses, but only emit 
traffic with the currently "Preferred" addresses. (i.e., configured 
addresses that are not actively used are not a problem).

2) Whether ongoing sessions should be allowed to continue using invalid 
addresses

By default (SLAAC-wise), they are not allowed. But section "Future Work" 
of RFC4941 hints on that as "future work". This could address the 
concerns of sessions that break up, but at the same time possible 
increase the number of concurrent addresses (you keep the addresses that 
are in use, but keep generating new ones).

One should note that this possible problem can be addressed by the app 
specifying preference of the address type to be used (i.e., override the 
default).

Based on the above, the options kind of become:

Option #1: Reduce the N ratio above, and disallow the use of invalid 
addresses for ongoing sessions. Apps that need long-lived sessions and 
that have not properly overriden the system default will have their 
connections torn down, and we'll have a hard limit on the maximum number 
of addresses.

Option #2: Reduce the N ratio, but allow ongoing sessions to use invalid 
addresses. This could be worse than legacy RFC4941 (if long lived 
sessions last more than a week), since now temporary addresses would not 
have a limited lifetime (the lifetime would only be limited wrt the 
ability to employ them for new transport protocol instances)

Option #3: Keep current N ratio, don't allow apps to use invalid 
addresses. This is the status quo, and enforces a limit  on the maximum 
number of addresses. But obviously this "N" is larger than that of #1 above.

Option #4: Keep the current N ratio, and allow apps to use invalid 
addresses. This is *not* RFC4941. I wonder if any implementations do 
this. This would obviously be worse in terms of the number of addresses 
than legacy RFC4941bis.

If I had to choose, I'd go for #1 or #3 above. If apps hint the network 
layer about the addresses to use (e.g. stable addresses if they mean to 
use long-lived connections), #1 is fine. OTOH, #3, the status quo, is 
more concervative in this respect.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jan 2020 14:45:18 -0800

Fernando,

In the case of single use addresses, that is each flow gets its own
addresses, the privacy effects are quantifiable. Since each flow has a
different source address, no two flows or communications can be
correlated to being sourced from the same user. In this case, the
identifiers are not reused is used in multiple contexts, so it isn't
possible to correlate seemingly unrelated activity using an
identifier. When an identifier is reused for the same node, even once,
then the possibility of correlations exists.

> emply for security have an associated lifetime...
It's a false sense of security. Here's a good analysis:
https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes

Tom

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 20:02:31 -0300

On 28/1/20 19:45, Tom Herbert wrote:
[...]
> then the possibility of correlations exists.

You are not quantifying privacy: that's still qualitative description.

> https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes

Forcing password changes exacerbate some human aspects, and at times 
leads to trouble. That doesn't say it doesn't have a place.

Folks also argue that firewalls are a false sense of security. Some 
argue the same about resistance to address-scan -- even when the #1 task 
to hack a system is normally to find it. IMO, whatever makes the 
attacker's life harder has a place and a use.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jan 2020 16:17:04 -0800

> You are not quantifying privacy: that's still qualitative description.
It is quantified. If a flow uses a unique address then the risk of
using the address of packets in the flow to correlate to other flows
is zero.

> attacker's life harder has a place and a use.

For things like address-scan and breaking a key, the risk of attack
can be quantified based on existing processing capabilities needed for
brute force attack. Deriving correlations between flows based on
addresses isn't quantifiable in the same way since it's not a brute
force attack.

Regardless, I still haven't seen a reasonable answer to user's obvious
question regarding temporary address: "What should my frequency of
address change be to ensure my privacy?"

Tom

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2020 19:35:27 -0500

> using the address of packets in the flow to correlate to other flows

Er, no, because the address contains a lot of bits that don’t change.  64, typically.  Those bits can be used to correlate other flows.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 21:36:02 -0300

> using the address of packets in the flow to correlate to other flows

What are the units? And what would "1" (or for instance "100") of such 
units mean?

(for the sake of exercise, even if you were "quantifying" this in terms 
of probability, 0 would be "impossible", 1 would mean 100% chance, and 
the rest would be impossible to specify, given factors such as network 
activity patterns, different kinds of applications, etc.)

[...]
> brute force attack.

I was noting that different people have different views regarding what 
is useful, and what is not. Some discourage address-scan resistance as a 
technique of "security through obscurity".

> address change be to ensure my privacy?"

If what you want is inability of correlation (and assuming you cannot 
correlate based on the prefix), then it's not a matter of time. It's a 
matter of addresses being bound to flows.

Any other measures depend on so many factors (network activity patterns, 
etc.) that it's virtually impossible to specify.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jan 2020 16:47:17 -0800

> Er, no, because the address contains a lot of bits that don’t change.  64, typically.  Those bits can be used to correlate other flows.

Addresses might be correlated to a provider, but no correlations can
be made between addresses within the provider space so attributing
different flows to the same user cannot be done. A NAT device with a
large number backend users would exhibit these properties even in
IPv4.

Tom

---

From: Sander Steffann <[email-masked]>
Date: Wed, 29 Jan 2020 01:56:27 +0100

Hi,

> large number backend users would exhibit these properties even in

It's the "with a large number backend users" bit. In many many situations that's not the case.

Cheers,
Sander

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jan 2020 17:03:47 -0800

> matter of addresses being bound to flows.
Yes, the problem statement in sec. 1.5 in RFC4941bis describes the
address correlation problem and that presumably the intent of
temporary addresses is to prevent unwanted correlation.

> etc.) that it's virtually impossible to specify.

Those are out of scope of RFC4941.

So, if we restrict the concern to just address correlations, then what
value should be set for the address expiration to achieve privacy in
addressing? Is 1 day, 1 hour, 1 minute, etc. good enough?

Tom

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2020 20:04:59 -0500

> large number backend users would exhibit these properties even in

Are we talking about privacy addresses, or something else?   If privacy addresses, the /64 that you have configured on your home network is a pretty good identifier; at least as good as the IPv4 address you have configured on the northbound interface of your NAT home gateway.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jan 2020 17:24:28 -0800

> It's the "with a large number backend users" bit. In many many situations that's not the case.
Yes, that's not a general solution and I'm not advocating it. However,
I do believe when it comes to privacy in addressing, NAT can better
properties than temporary IP addresses because it is effectively
single use addresses that prevent correlations between independent
communications. Law enforcements push to eliminate CGNAT is
testimonial to that
(https://www.theregister.co.uk/2017/10/18/europol_cgnat/).

Tom

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Jan 2020 15:01:13 +1300

On Wed, 29 Jan 2020, 13:47 Tom Herbert, <[email-masked]> wrote:

> > Er, no, because the address contains a lot of bits that don’t change.
> 64, typically.  Those bits can be used to correlate other flows.
>
> different flows to the same user cannot be done.

A NAT device with a
> large number backend users would exhibit these properties even in

I think this is assuming that IP addresses are the only way to identify
people and their devices

NAT made people resort to much smarter ways that don't rely on IP addresses.

https://panopticlick.eff.org

Internet search for "browser fingerprinting" for other examples.

All we can do, being limited to the IPv6 layer, is improve baseline and
default privacy, while also trying to avoid it impacting typical end-user
experience. The conservative 24 hour preferred lifetime should cover the
maximum length of any typical end-user's transport layer connection.

RFC4291bis is "better than nothing" IID privacy.

If an end user wants assured privacy they need to have mechanisms and
methods that work at all layers from IPv6 upwards.

That could include running the connection through an application layer
anonymising proxy that strips out all possible identifiers at all layers.

To the external destination, the anonymising proxy would be
indistinguishable from a single native client.

Ideally the anonymising proxy is reached internally with ULA addresses, and
hosts only have ULA addresses. That should mean failing safe if the
application layer anonymising proxy fails.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 28 Jan 2020 19:06:19 -0800

On Tue, Jan 28, 2020 at 6:01 PM Mark Smith <[email-masked]> wrote:
> I think this is assuming that IP addresses are the only way to identify people and their devices
>
> All we can do, being limited to the IPv6 layer, is improve baseline and default privacy, while also trying to avoid it impacting typical end-user experience. The conservative 24 hour preferred lifetime should cover the maximum length of any typical end-user's transport layer connection.
>
Mark,

I don't understand why 24 hours is considered the preferred lifetime.
Is this based on some empirical or at least theoretical analysis of
the attack vector described in the problem statement. Also it looks
like the default is a carry over from RFC4941 which is over twelve
years old, shouldn't the defaults be reevaluated to see if they are
still reasonable in today's environment (i.e. the capabilities of
would be attackers only increase over time, so what was good enough
twelve years ago might not be good enough today).

Tom

> If an end user wants assured privacy they need to have mechanisms and methods that work at all layers from IPv6 upwards.
>
> That could include running the connection through an application layer anonymising proxy that strips out all possible identifiers at all layers.
>
> To the external destination, the anonymising proxy would be indistinguishable from a single native client.
>
> Ideally the anonymising proxy is reached internally with ULA addresses, and hosts only have ULA addresses. That should mean failing safe if the application layer anonymising proxy fails.
>
>
> Regards,
> Mark.
>
>
>>
>> Tom
>>
>> >
>>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jan 2020 22:20:36 -0500

> twelve years ago might not be good enough today).

A couple of years ago I was looking into how to satisfy EU privacy requirements around IP addresses in a way that would actually accomplish anything.  I looked into doing a rolling renumber every 24 hours as a way to address this use case.  Even there, without having a giant routing table, it honestly just seemed futile.  Too many bits in the prefix would remain unchanged, and as you say, 24 hours is a long time.  If the ad companies can tell who I am whether I’m using cellular or WiFi, they can tell who I am when I roll my prefix every 24 hours.  I would be really interested to see an analysis of the actual privacy benefits of temporary addresses, but I never have.

Fernando, Stephen Farrell, do you have any data?  Any back-of-the-envelope calculations?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 28 Jan 2020 21:46:47 -0800

On 1/28/2020 9:46 AM, Gyan Mishra wrote:
>
>    The main reason this topic comes has up is due to possible impact
> of usage of the temporary address when it gets deprecated with long
> lived session.  That’s the crux of why this topic is critical and has
> severe operational impact. When the address changes for long lived
> connections from the deprecated temporary address to the new preferred
> address, the session would terminate and have to re-establish, which
> is impacts the user. 

OK, but on the other hand, necessity is the mother of invention. If the
applications that depend on long-lived addressed today realized that
addresses are not long lived in practice, they would most probably
adapt. And there are lots of possible adaptations. For example, TLS
sessions can be resumed quickly. Quic connections can migrate to a new
address. TCP multipath allows for smooth transition from one address to
another. Etc.

-- Christian Huitema

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jan 2020 07:05:43 +0100

Yes.

But passive sentences are bad.

“Can be used” — by whom?

Both the peer of the connection and a monitor (wiretapper, network operator) may be interested in that stable identifier; in many cases the peer already knows more (ssh example) but the monitor doesn’t, so we should separate these two issues.

Grüße, Carsten

---

From: [email-masked]
Date: Wed, 29 Jan 2020 10:04:17 +0100

Lorenzo, et al,

> Saying that temporary addresses should be disabled by default (assuming hosts actually do that) seems like a terrible privacy problem. It means that by default, a host that doesn't change prefix wi…

This seems like an exaggeration. Temporary addresses does not provide privacy. They provide a small piece of a much larger and complex puzzle. One which likely requires not technological solutions but regulatory ones.

How efficient and useful that piece is compared to e.g. 7217 iids I have not seen any data on.
If we don't have any data for the 4941 effectiveness, operational experience and implementation experience (ICE, MPTCP, applications), then all we can do here is to offer our anecdotal data. Although given your affiliation perhaps you could tell us how little or how much value temporary addresses have for tracking?

> Instead of disabling, why not change the default of the number of addresses maintained? For example, instead of maintaining 1 permanent + 1 valid + 7 deprecated, why not just default to maintaining…

The current (draft standard) text in 4941 is:
   "Consequently, the use of temporary addresses SHOULD be disabled by
   default in order to minimize potential disruptions.  Individual
   applications, which have specific knowledge about the normal duration
   of connections, MAY override this as appropriate."

I would like to understand the rationale for removing that text.
Note, 4941bis in it's current form does not have an opinion regarding a default.

Best regards,
Ole

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 Jan 2020 10:08:02 +0000

On 29 Jan 2020, at 09:04, [email-masked]<mailto:[email-masked]> wrote:

<snip>

Well, in practice some OSes do not follow that SHOULD, but the use or non use is typically governed by the scenario; there is no one-size-fits-all default here, e.g., data centre servers vs users in coffee shops.

RFC 6724 says nothing about the default, being just about address selection not generation, but that "For source address selection, temporary addresses [RFC4941<https://tools.ietf.org/html/rfc4941>] are preferred over public addresses."

RFC 8504 also says nothing about the default, but does say that "devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of such temporary addresses.”

So together in principle any user can enable privacy addresses and in doing so they will be preferred over non-temporary addresses.

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jan 2020 20:13:17 +0900

On Wed, Jan 29, 2020 at 2:46 AM Gyan Mishra <[email-masked]> wrote:

> session would terminate and have to re-establish, which is impacts the user.
>

If there is a permanent address as well, then an application that is not
able to deal with session resets (like SSH) can use
the IPV6_PREFER_SRC_PUBLIC socket options to use the permanent address
instead.

> This would allow us to maintain privacy extension temporary address
> enabled by default change to benefit privacy advocates and also eliminate
> impact for enterprise users where availability and stability is utmost
> importance.
>

But don't enterprises care about not leaking the habits of their employees?
If I was on an enterprise security team, I would be pretty concerned about
the levels of leakage and cross-site tracking that are enabled by never
changing the IPv6 addresses of a host. This doesn't happen in IPv4 because
we use NAT, but it will definitely happen in IPv6.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jan 2020 20:19:16 +0900

> ability to employ them for new transport protocol instances)

ISTM that "using invalid addresses" is poorly defined and likely difficult
to implement. It also isn't not much (if at all) different from the current
status quo with lots of deprecated addresses. The only difference is that
it forbids allow applications from purposely binding to an expired address.
But applications don't do that - why would they? The current privacy
address is better than that address in every way.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Jan 2020 11:25:23 +0000

> But don't enterprises care about not leaking the habits of their employees?

This is only a problem in SLAAC environments where privacy addresses are 
turned off.  In DHCP environments, the network operator can change 
endpoint addresses by policy if this is what they want to do.

Nick

---

From: [email-masked]
Date: Wed, 29 Jan 2020 12:28:17 +0100

> On 29 Jan 2020, at 12:13, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
>    The main reason this topic comes has up is due to possible impact of usage of the temporary address when it gets deprecated with long lived session.  That’s the crux of why this topic is critical and has severe operational impact. When the address changes for long lived connections from the deprecated temporary address to the new preferred address, the session would terminate and have to re-establish, which is impacts the user.
> 
> If there is a permanent address as well, then an application that is not able to deal with session resets (like SSH) can use the IPV6_PREFER_SRC_PUBLIC socket options to use the permanent address instead.
>  
> This would allow us to maintain privacy extension temporary address enabled by default change to benefit privacy advocates and also eliminate impact for enterprise users where availability and stability is utmost importance.
> 
> But don't enterprises care about not leaking the habits of their employees? If I was on an enterprise security team, I would be pretty concerned about the levels of leakage and cross-site tracking that are enabled by never changing the IPv6 addresses of a host. This doesn't happen in IPv4 because we use NAT, but it will definitely happen in IPv6.

So, are you saying that using temporary addresses does not leak the habits of employees?
Can you ellaborate on that please? Preferably with some data points.

Worth reading ISBN-13: 978-1610395694 if you are interested in a more thorough discussion of the problem.

Enterprises use web proxies and SSL intercepting gateways anyway, don't they (sigh).

Cheers,
Ole

---

From: Jared Mauch <[email-masked]>
Date: Wed, 29 Jan 2020 06:39:07 -0500

> On Jan 29, 2020, at 6:28 AM, [email-masked] wrote:
> 

Some do. I've worked places that did for non-SSL. Keep in mind the operator of that network tends to only allow devices managed by them so they are not user devices. A user generally has no right to privacy on equipment they do not own. 

(This is a controversial position to state in the IETF but is still valid). 

- Jared

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Jan 2020 11:40:18 +0000

Jared Mauch wrote on 29/01/2020 11:39:
> A user generally has no right to privacy on equipment they do not own.

that may be the case in some jurisdictions, but is categorically not in 
others.

Way off topic though.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jan 2020 20:43:58 +0900

> So, are you saying that using temporary addresses does not leak the habits

I'm saying using temporary addresses makes a number of attacks, including
cross-site tracking, more difficult, infeasible, or defeatable by the
employee or IT admin. If you believe that to be false, you can always try
to see if you can get consensus on a document that says that privacy
addresses are not useful and declares RFC 4941 historic. :-)

---

From: [email-masked]
Date: Wed, 29 Jan 2020 12:48:54 +0100

> (This is a controversial position to state in the IETF but is still valid). 

And just to be clear. I am not against a document specifying temporary addresses.
The IETF published RFC3041 back in 2001, as a response to information leakage caused by EUI-64 based IIDs.
Quite a lot has changed since then. I am trying to get some answers to the following questions:

 - what are the operational consequences of temporary addresses
 - how effective are temporary addresses in making correlation harder?
 - are applications clever enough to not re-use tainted addresses for example?
 - do protocols like ICE, MPTCP, QUIC bundle together stable and temporary addresses?
 - implementations that allow for the use of many addresses might get into trouble with the network,
   can they deal with those failure cases in an acceptable way?

4941bis is being demoted to proposed standard. Which means we might live with these questions being unanswered, but I think we need to have some of the discussion around these in the deployment considerations.
And the issues with temporary addresses might still warrant that we keep the general recommendation of off by default. TBD.

Best regards,
Ole

---

From: [email-masked]
Date: Wed, 29 Jan 2020 12:54:37 +0100

Lorenzo,

> I'm saying using temporary addresses makes a number of attacks, including cross-site tracking, more difficult, infeasible, or defeatable by the employee or IT admin. If you believe that to be false, you can always try to see if you can get consensus on a document that says that privacy addresses are not useful and declares RFC 4941 historic. :-)

Anything you can cite here?
Just because you state it does not make it fact.
After almost 20 years of temporary addressing, it seems there is very little data available.
cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Jan 2020 20:59:34 +0900

On Wed, Jan 29, 2020 at 8:54 PM <[email-masked]> wrote:

> > I'm saying using temporary addresses makes a number of attacks,
> including cross-site tracking, more difficult, infeasible, or defeatable by
> the employee or IT admin. If you believe that to be false, you can always
> try to see if you can get consensus on a document that says that privacy

RFC 4941 section 2.1?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Jan 2020 13:42:28 +0000

What problems are we talking about? I’ve seen several things:

A) On the host:
   1) desire to avoid leaking user info and network info around the us
   2) simplicity in address allocation
   3) match address lifetime with session needs

B) On the network:
   1) avoid misusing wireless resources (broadcasts)
   2) match the state in the network with the needs of the client adapt resource allocation
   3) maintain a complete picture of the addresses in use to set up forwarding (think overlays) and provide visibility to ops
   4) SAVI, protecting the hosts against addresses impersonation and stealing

The number of temp addresses is only remote to most of these issues.

A1) temp addresses beyond one session leaks information. The ideal would thus be one address per session. Since there can be a number of concurrent sessions it is hard to provide an upper bound to the number of addresses a host may use at one point of time, but certainly there could be several.
A2) Multiplying the mechanisms creates hassle and possible interactions between the mechanisms. The ideal would be a simple exchange where the host may provide an address or get one back, the address being guaranteed unique and inserted in the access routers by the end of the exchange so it is usable immediately.

A3) The lifetime of a session may vary. If the duration is unknown then the address should be renewable whereas RFC 4941 just deprecates its.

B1) The more addresses a node uses with classical ND, the more broadcast churn on the Wi-Fi. Having multiple addresses exacerbates the problem but it’s really a protocol issue more than a conceptual issue with having multiple addresses.

B2) On the network side, there’s a lot of memory available to maintain state. What hurts is that the network does not know when the hosts creates a new address and when it releases it. The more BCPs we change over time the less the network can guess. The network cannot even recognize a permanent and a temporary address.

B3) Because it is blind with IPv6 ND, the network maintains state for addresses that are not used any more, and may release state for addresses that are still in use. It has to resorts to LRU and limits the count of addresses per MAC. Then again the amount of addresses in use only exacerbates the problem, but it is really a protocol issue.

B4) If the network maintains a state about the address, that state can be associated with a proof of ownership. This simplifies dramatically the SEND problem, since the proof is done onece with the network as opposed to individually with each peer, and the token can be larger than 64 bits.

The problem is thus NOT that the node has too many addresses, and it is thus NOT to define how many address a node should have, and what would be the default lifetime. There is no good answer for that, this thread has been quite clear about that. The problem is to keep the network in sync with the needs of the hosts so the network can serve them optimally within resources.

The ideal would be that the host maintains a state with the network for all the addresses in use, with a sense of lifetime, mobility, and possibly a proof of ownership of the resources that it claims.

One can get a lot more by being polite and just asking.

So I’m asking. Please look at RFC 8505.

Pascal

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Jan 2020 14:39:11 +0000

Lorenzo Colitti wrote on 29/01/2020 11:59:
>     including cross-site tracking, more difficult, infeasible, or
>     defeatable by the employee or IT admin. If you believe that to be
>     false, you can always try to see if you can get consensus on a
>     document that says that privacy addresses are not useful and
>     declares RFC 4941 historic. :-)
> 

wasn't Ole looking for data rather than canon?

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Jan 2020 07:41:15 +0900

> wasn't Ole looking for data rather than canon?

I don't see how asking for data in the abstract is helpful given that we
already have an engineering document about this. If anyone thinks that
document is wrong, that's fine, but they should point out where and how it
is wrong and we can discuss that.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Jan 2020 14:56:45 -0800

Ole,

I agree these are important questions, I would also add that there
should be more discussion and analysis as to the real effect that
temporary addresses has had on privacy in addressing-- specifically,
whether temporary addresses as defined in RFC4941 has sufficiently
addressed the problem posed in the Problem Statement (section 1.2 of
that RFC).

Tom

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 29 Jan 2020 18:06:39 -0500

(I'm going to hate myself in the morning for this, but..)

> After almost 20 years of temporary addressing, it seems there is very little data available.

If we're talking about 'employees' and 'employers' (you can extend
this to the ISP if you like easily enough)
  1) you can see port / mac / neighbor maps on
switches/routers/brouters/swouters  (this gets you a
person/desk/machine)
  2) you can link DNS requests and firewall logs to the IP address(es)
  3) you can be even simpler by just logging the IP src-address on any
'single sign-on' (or access to authenticated corporate resource) to
ensure you mapped the things in 1 correctly
  4) you can sort / sift / alert on that data to your heart's content.

This isn't rocket science... Is there data for this? kinda? there are
products which do this today, One even I think made by the Cisco /
Talos folks for 'idp / ids / exfiltration detection' and similar uses.
Heck, any SEIM today can/does do this work trivially.

Now, extend that to your ISP? sure, same problem, larger userbase and
higher feeds/speeds.

---

From: David Farmer <[email-masked]>
Date: Wed, 29 Jan 2020 17:17:12 -0600

On Wed, Jan 29, 2020 at 3:04 AM <[email-masked]> wrote:

> This seems like an exaggeration. Temporary addresses does not provide
> privacy. They provide a small piece of a much larger and complex puzzle.
> One which likely requires not technological solutions but regulatory ones.
>
> If we don't have any data for the 4941 effectiveness, operational
> experience and implementation experience (ICE, MPTCP, applications), then
> all we can do here is to offer our anecdotal data. Although given your
> affiliation perhaps you could tell us how little or how much value
> temporary addresses have for tracking?
>
> > I don't think 4191bis should advance if it says that privacy addresses
> are disabled by default. It would be a strong statement by the IETF that we

This is all about trade-offs, the use of temporary addresses by no means
guarantees privacy, there is no perfect privacy, it's not an absolute,
privacy is relative. Furthermore, the only way to provide perfect privacy
is to not communicate with anyone over the Internet or by any other means
for that matter. All communications risks interception,
information leakage, that compromise your privacy. We risk this
interception, information leakage and compromise of privacy, for the
rewards communications bring us.

That said, using the same address over an extended period of time (months
to years) is an obvious and unwarranted threat to privacy, in my opinion.
The use of temporary addresses helps prevent this, and while they are not
appropriate in all cases, neither is saying that that temporary addresses
should be disabled by default.

I think something like the following needs to be added to RFC4941bis;

While using the same address over an extended period of time (months to
years) is an obvious and unwarranted threat to privacy, in that it allows
for an easy correlation of a user to an address over this extended period
of time. However, this same correlation of user to an address, at least in
the short-term (hours to days), that this technique seeks to limit, is
frequently a necessary first step in most troubleshooting activities.
Therefore, changing temporary addresses too frequently will likely
exacerbate operational problems, frustrating attempts to correct them, and
in extreme cases could impact the operational stability of networks.
Furthermore, the successful troubleshooting of intermittent problems
occurring over a period of time (especially over several days) may require
a stable address and at least the short-term disabling of the use of
temporary addresses.

The choice of default timers in this document attempts to balance this
trade-off between privacy, the effective troubleshooting of problems, and
the operational stability of networks, all of which are in individual
users' and network operators' mutual interest.

Finally, changing temporary addresses at a high-frequency (minutes to
hours) will have operational impacts especially in troubleshooting as
discussed above. However, changing temporary addresses at these
high-frequencies will also likely impact network stability and host
performance due to the unreasonably high levels of neighbor discovery
traffic necessitated by such high-frequency changing of
temporary addresses, this is especially true when amplified by a large
number of hosts changing their temporary addresses at a high-frequency.

If I were to make any changes to the default timers in the document I would
shorten the TEMP_VALID_LIFETIME from 1 week to something like 2 or 2.5
days. I think TEMP_PREFERRED_LIFETIME of 1 day is a reasonable compromise
between privacy, the effective troubleshooting of problems, and the
operational stability of networks.

Thanks.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Jan 2020 15:20:59 -0800

> Heck, any SEIM today can/does do this work trivially.
Christopher,

The Internet equivalent for #3 would be login services (like FB,
gmail, etc.) as well as the use of cookies that include an identifying
cookie (like ads). It's likely that even just a few seconds after an
address is changed some third party has already logged the association
of IP address to user or device. Exploiting this information, step 4,
is a matter of applying the logs to make correlations and
identifications in completely uncorrelated traffic. Increasing the
frequency of address change problem does little more than increase the
number of log entries that an attacker needs to process (and that's
only a problem for them if everyone is changing addresses a high
frequency).

Tom

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 09:18:25 -0500

> session.  That’s the crux of why this topic is critical and has severe

So I thought that the Linux kernel did this, but I discovered my long-lived
SSH session on my newly-re-installed laptop (with temporary addresses enabled
by default. I had turned them off on the prevous install) died yesterday
morning.

My opinion is that we should re-open the SHIM6 work.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 09:33:05 -0500

> occur with a laptop or smartphone? I can't think of one.

Maybe you could ask the question differently;

_Can you provide an example of a common long lived connection that would
 occur with an Android or Linux based wireless device?_

(Yes, I've just excluded Apple iOS, because AFAIK, there are no iOS based IoT
devices other than smartphones)

So, let me give you my list now:
1) Point of Sale tablet in store (iPad or Android)
2) (smart)TV for use in the living room
3) (smart)TV used as screen for security system
4) Laptop at home with SSH connection, or VPN to office. (Networks are fast
   enough/low-enough latency today to do X-windows over SSH across town)
5) Billions of IoT devices using MQTT.
6) NFS, SSHFS
7) All the HTTP/1.1 stuff using push notifications, for devices that don't
   leave the home: Smart Fridge, kids tablet, reading tablet, 

Do these devices benefit from the privacy that temporary addresses provide?
That's a different question.  Have most of these devices had to learn to
reconnect? Or to point it another way, have applications had to learn to make
up for a layer-3/4 which is was rendered unreliable by NAT44? yes. 
Is that well architected? No.

I would argue that we (Ubuntu,Android,etc.) have moved forward with temporary
addresses by default without enough work around the side.  Meanwhile, PLPTMU
is still not enabled by default, which I think is a significantly more
important thing.

    > Even back in the early 1990s, when fixed location desktops were the
    > main personal computing device, long lived client connections were
    > rare. If you wanted a reliable long lived connection for something, you
    > didn't use your desktop, you used the hosts/servers that were in
    > computer rooms protected by UPS.

I disagree.

In the 1990s my office desktop had long lived connections (logins, X-windows
sessions, even RDP sessions) that lived for weeks.  Between power
interruptions, or OS patches.  More the later actually, but this was the
1990s, so it wasn't automatic.

Yes, you are right, power failures are an annoyance, especially when it's 90
seconds every Sunday night at 5pm {I'm looking at you UQO.ca}, but a $80 UPS
solved that.

I stopped lugging a laptop around around in 2010, opting for a desktop system
(with many monitors and ergonomic keyboard) at each major location,
plus... well.. Internet.   I tried no-laptop (tablet only), but projecting
slides at IETF was one of the pain points, and I now have a capable laptop,
but it's not my, as you said, my primary location.  The desktop at the office
with UPS is.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 30 Jan 2020 11:52:15 -0500

> endpoint addresses by policy if this is what they want to do.

   Gyan> Enterprises fall into a totally different camp altogether as far
as “employee” privacy as that is non existent as all traffic is monitored
to be business related traffic to the extent of web content blocking which
most all companies implement.   The use of temporary addresses does not
make sense for enterprises to employ as operations stability and 99.99999%
available and MTTR( mean time to recovery) is of utmost importance.  By
disabling the temporary address - simplified the enterprise network
troubleshooting tremendously as only a single “stable” random address
exists at all times.  As far as temporary address and “long lived”
connections for enterprise business critical applications that can all be
solved by disabling the temporary address.

RFC 4941bis should have verbiage to that extent something like this below:

Enterprise networks have different requirements for privacy as far as cross
site address tracking correlation, or IID leaking concerns that exist when
connected to the internet.  For enterprises availability and operational
stability and MTTR(mean time to recovery) is of utmost importance.  The
temporary address due to the complexity added with the N= Preferred / Valid
addresses that get generated complicates operations ability to resolve
network issue with the number of active addresses.  It is recommended that
enterprises disable the temporary address as privacy from and end user
privacy standpoint, address correlation is a requirement for IT security.

By adding this text we can exclude “enterprise” from the equation ; thus
the finalized options N=Preferred/ Valid option that Fernando put together
need only address end user privacy when connected directly to the
internet.  Since end user at home broadband or connected to the internet at
a hotspot don’t have to worry as much about business critical applications
that are revenue generating and millions of $$ lost as a result of an
outage.  So the “long lived” connections discussion although it can exist
in a home network, the impact is not the same as with an enterprise.   So
from my standpoint, VPN, ssh or your TV STB disconnecting with “long lived”
connections is not as big a deal as “ip address identity theft”.

I will reply to Fernando’s options separately as if everyone agrees  that
enterprise can be pulled out of the equation it does make it easier to come
up a solution that is truly geared towards “end user” privacy and address
correlation and “ip address identity theft” to commit crimes by address
spoofing your public IP.  This does allow us to play more with the N=
numbers and maybe tweak the default to maximum for end user privacy.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Erik Kline <[email-masked]>
Date: Thu, 30 Jan 2020 09:09:54 -0800

On Thu, Jan 30, 2020 at 8:52 AM Gyan Mishra <[email-masked]> wrote:

> solved by disabling the temporary address..
>

There's difference between "the enterprise can track the employees' work
devices' connections" and "the whole word can track the enterprise's
employees' work devices' connections".  Disabling temporary addresses
altogether is more in the 2nd category.  Temporary addresses + enterprise
logging (on premises' equipment and on the devices themselves) fits
comfortably in the first category.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 09:12:39 -0500

Fernando Gont <[email-masked]> wrote:
    >> back. temporary addresses will not help against surveillance
    >> capitalism.

    > doing their thing. Whether that's perfect or far from perfect is a

Quantizine the value of the benefit is important when determining how much to
spend to mitigate issues.

I think that we should not oversell the benefits, but that doesn't mean there
are none. (I think that the benefits have been oversold within the IETF)

I'd like to see 6man look to better APIs for address selection.
That would include outreach (which means listening to user communities, not
telling them what to do), hackathons, BCPs and evangelism/promotion.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 09:14:17 -0500

Fernando Gont <[email-masked]> wrote:
    >> But it does violate the recommendation if you use it to enforce how
    >> many addresses the host can use. The text is:
    >> 
    >> address space (seeSection 4
    >> <https://tools.ietf.org/html/rfc7934#section-4>), it is RECOMMENDED
    >> that the network give the host the ability to use new addresses
    >> without requiring explicit requests.  This can be achieved either by
    >> allowing the host to form new addresses autonomously (e.g., via SLAAC)
    >> or by providing the host with a dedicated /64 prefix.  The prefix MAY
    >> be provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other
    >> means.
    >> 
    >> 

    > per node, even with SLAAC. Yes, you're address wouldn't be rejected
    > .. it just wouldn't work. The outcome is the same.

It would be impossible to debug, so the user turns off IPv6, and we all lose.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 12:53:49 -0500

Fred Baker <[email-masked]> wrote:
    > +1 on this. We can discuss whether a temporary address should have a
    > limited lifetime or whether a given interface might have at most some
    > number of temporary addresses at any given time, but to say that in the
    > default (e.g., usual) case each system has zero seems like a bad idea.

I agree with what you said, and the way that you said it.

In particular, I think that it would be better to have a temporary address
per user and/or threadish-pool (e.g. Chrome) and/or container, and keep this
for a longer time.
I think that if a host/network is going to support multiple temporary
addresses, that they should be used in parallel and used for a long time.

I'm aware that Android (Lorenzo, Jen, etc.) been resistant to supporting
DHCPv6.  This is causing a bit of schism, because we of how we have made the
stateful/stateless split.  Maybe we need a stateful SLAAC that isn't DHCPv6
to make this work.  Or something like that.  Or find a way to address the
issues that Android has with supporting DHCPv6 client.

(Please feel free to point me again to some summary discussion from 2003,
when the objection was first detailed)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 13:00:10 -0500

> inability to do network scanning is huge.

This feels like an anecdotal observation.

Have you been able to quantify the difference in script-kiddie/scanning
attacks over the years?    A graph of ND traffic from the router out
would probably be one way to measure this.

The IETF NOC struggled with arp-exhaustion due to scanners, but then got
solutions in the APs/routers for IPv4, which I think worked eventually for
IPv6.   But, do we get any data on this?

Did anyone actually try to scan IPv6 subnets before privacy addresses?
My IPv4/28 is continously being probed, but I rately see any IPv6 scan
traffic.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Jan 2020 13:03:05 -0500

> This feels like an anecdotal observation.

Furthermore, it’s mathematically simply wrong or else a non-sequitur.   If I have N addresses out of a space M, my chance of getting hit randomly is N/M.  So the more temporary addresses I have, the higher the change of a probe hitting me.

Contrariwise, if my address contains a predictable value, then that relationship no longer holds.   So the IID really does need to be randomly generated.   And then the fewer addresses I have, the less risk of getting probed.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 15:15:28 -0300

> It would be impossible to debug, so the user turns off IPv6, and we all lose.

Well, if the network tries to convey policy, and a host stubbornly wants 
to violate that policy... the host will be shot down, yes.

It would seem to me that:
* We did a BCP saying "host should be able to configure as many 
addresses as possible". -- that's fine... IPv6 is all about the extra 
addresses, right?

* Vendors ship devices with a few Ks of NCE. Maybe we should do 
something in this area?

* Multicast doesn't seem to be playing so nice, either.

The two don't work well with each other. And we don't give the ops 
people the tools that could make the above bullets be nice with each other.

No wonder about the outcome.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 15:20:04 -0300

On 30/1/20 11:12, Michael Richardson wrote:
[..]
> I'd like to see 6man look to better APIs for address selection.

Good grief. We did this: 
https://tools.ietf.org/id/draft-gont-6man-address-usage-recommendations-04.txt

This work would have lead to the *real* issues for which some are 
blaming temporary addresses in this thread.

I presented it once in 6man, and was suggested it belonged elsewhere. I 
tried elsewhere (taps), but it seems they believe it belonged elsewhere.

So I guess the problem we are dealing with with be solved by someone, 
somewhere (someday? :-) ).

Thanks,

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 14:03:15 -0500

> I don't understand why 24 hours is considered the preferred lifetime.

I think that this is a good and definite RFC4941bis comment that we should go
into.

I think that using temporary addresses in series, for short periods of time,
is useless: WHEN IT COMES TO PREVENTING TRACKING WHEN NOT MOBILE.

To be clear, we have made significant progress for devices which are mobile
or nomadic.  We should celebrate this and move on, but recognize that a
'temporary" address that lasts as long as the device is at a specific
location is good.
A stable private address may be good enough, if it is okay for the device to
resume the same address whenever it returns to that location. 

For the reasons Ted gave (upper-64 at home network), but also because the
risk is providing trivial tracking to a MITM observer who sees connection A
to facebook, to pr0n site Q, human rights organization Y, VPN service N and
then connection B to service X. As Tom and Mark have pointed out, if the MITM
can coordinate userinfo with service X, then they can determine the set of
things that the user has done.

*IF* we are trying to deal with tracking when a device is not moving, then we
 might need a different strategy.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Jan 2020 14:10:32 -0500

> resume the same address whenever it returns to that location. 

One thing to think about is /why/ the device needs the same address over and over again.  It’s because something wants to contact it.  In order for something to contact it, that something has to have a pointer to it.   Where did it get the pointer?   If that’s a public place, then privacy is somewhat out the window, but nevermind that for the moment.   If it’s a /private/ place, then as long as, when your address changes because you moved locations, you update that registration, then there’s no need to return to the address you had before at a particular location when you return to that location.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 14:12:16 -0500

> 1) Valid Lifetime and Temporary Lifetime timers

Agreed, and this is an important knob.

    > 2) Whether ongoing sessions should be allowed to continue using invalid

I was initially surprised that the old addresses were called invalid.
Non-temporary addresses do not go invalid at the end of the lifetime, as long
as the host receives another RA.

Clearly the host made them up, as long as it continues to defend them, it
seems like it is wrong to call them invalid.

I think that N=1 is the right value, but that hosts should be told how many
concurrent temporary addresses the network will tolerate.  We can, if you
like, define the counter to be X+1, so a value of "0" means the host can use
one temporary address, and you can't specify zero :-)

    > addresses. This could be worse than legacy RFC4941 (if long lived sessions
    > last more than a week), since now temporary addresses would not have a
    > limited lifetime (the lifetime would only be limited wrt the ability to
    > employ them for new transport protocol instances)

That was, btw, always my historical understanding.  It turns to be wrong.

    > If I had to choose, I'd go for #1 or #3 above. If apps hint the network layer
    > about the addresses to use (e.g. stable addresses if they mean to use
    > long-lived connections), #1 is fine. OTOH, #3, the status quo, is more
    > concervative in this respect.

Maybe we suggest that OSes provide a knob to determine what kind of address
is provided to an application that expresses no preference, I could live with
this.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 14:14:15 -0500

> address is better than that address in every way.

So, I have an FTP control channel open for two weeks.
I want to bind a new socket for data tranfers... and now I can't bind the IP
address that I want.  Okay, FTP is ancient dead.  Replace with SIP.
Yes, HTTP/2 and/or QUIC knows how to do this easier.
I don't know that I want to force everything to convert to QUIC.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2020 14:37:51 -0500

Pascal Thubert (pthubert) <[email-masked]> made many good points, and said:
    > The problem is thus NOT that the node has too many addresses, and it is
    > thus NOT to define how many address a node should have, and what would
    > be the default lifetime. There is no good answer for that, this thread
    > has been quite clear about that. The problem is to keep the network in
    > sync with the needs of the hosts so the network can serve them
    > optimally within resources.

    > The ideal would be that the host maintains a state with the network for
    > all the addresses in use, with a sense of lifetime, mobility, and
    > possibly a proof of ownership of the resources that it claims.

    > So I’m asking. Please look at RFC 8505.

I agree.
And if not 8505, then we need another mechanism to synchronize host/router
state, but first, please take a look.  It's not DHCPv6.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 16:50:15 -0300

On 30/1/20 15:03, Ted Lemon wrote:
> On Jan 30, 2020, at 1:00 PM, Michael Richardson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> Furthermore, it’s mathematically simply wrong or else a non-sequitur.   
> If I have N addresses out of a space M, my chance of getting hit 
> randomly is N/M.  So the more temporary addresses I have, the higher the 
> change of a probe hitting me.

Of course attacker's don't think that way: Attackers don't randomly scan 
the IPv6 address space. That's a waste of time.

That said, what has addressed the problem of address scanning is 
RFC7217, *not* RFC4941. -- since attackers were after addresses that 
follow patterns, not the random ones.

On the other hand, when you consume information from the Internet, you 
are exposing your address. Host can simply not bind any ports to 
temporary addresses: -- this means that even if you expose your address 
for *consuming information* none of such nodes can contact you back. 
This would be a big improvement achieved via RFC4941.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 16:54:33 -0300

On 30/1/20 16:10, Ted Lemon wrote:
> One thing to think about is /why/ the device needs the same address over and over again.  It’s because something wants to contact it.  In order for something to contact it, that something has to have a pointer to it.   Where did it get the pointer?   If that’s a public place, then privacy is somewhat out the window, but nevermind that for the moment. 

The two are unrelated. I may be running a web site, and have an address 
posted on the DNS. That doesn't mean that it should be trivial for folks 
to correlate the information I consume with that machine with the web 
site I host.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 18:01:07 -0300

On 30/1/20 16:14, Michael Richardson wrote:
> address that I want. 

In that case, set the appropriate socket option, and override the 
default such that all your connections use a stable address.

---

From: David Farmer <[email-masked]>
Date: Thu, 30 Jan 2020 15:32:48 -0600

> is useless: WHEN IT COMES TO PREVENTING TRACKING WHEN NOT MOBILE.

I agree RFC4941 does little to prevent sophisticated tracking
especially when a device is stationary, what it does do is prevent trivial
tracking especially over time frames of months or years. Without RFC4941, a
stationary device could be using the same address for months or even years
at a time, making it trivial to track these devices.

Devices that are linked to or primarily used by humans frequently have
diurnal cycles just as the humans that are using them usually do. Changing
addresses once a day is unlikely to cause too much disruption to
these diurnal cycles, the more frequent the changes the more likely there
will be unanticipated consequences. Even today most applications are
written using an always-on model of networking, where addresses never
change.  And, since most applications are used by humans in a diurnal
cycle, a daily address change is likely to go completely unnoticed by an
application, or at least not have any impact that is noticed by the actual
human user.

In my opinion, anything between 8 and 24 hours in most cases will be more
or less equivalent in most use cases, from privacy and disruption
perspective. Going shorter than 8 hours could provide minor privacy
benefits but is likely to create much more disruption.

Finally, I doubt changing addresses will have any
significant impact on sophisticated tracking even at change frequencies in
the range of minutes and at those change frequencies, network stability is
likely to be impacted, especially with many hosts making address changes at
those frequencies.

Basically, temporary addresses changing on a daily basis seems like a
prudent thing to do, this shouldn't cause too many problems and should
prevent the most trivial forms tracking especially over long time periods
like months and years.

By the way, I think calling them privacy addresses sets the bar way too
high, maybe the title should be changed as well, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6" is probably setting the bar
too high.   Maybe "Temporary Address Extensions for ..."

Thanks

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 18:44:03 -0300

>   - what are the operational consequences of temporary addresses

I proposed a paragraph about this one.

>   - how effective are temporary addresses in making correlation harder?

They limit the lifetime of the address, and in doing so the limit the 
amount of time that network activity correlation can be performed.

>   - are applications clever enough to not re-use tainted addresses for example?

This is out of scope for rfc4941bis. We raised this here 
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations 
. I presented in 6man, and the suggestion was that this belonged 
elsewhere. Maybe it's time to work on it?

>   - do protocols like ICE, MPTCP, QUIC bundle together stable and temporary addresses?

At the very least, temporary addresses came way before MPTCP and QUIC. 
So I think this is out of scope for this document. -- it *might* be in 
scope for draft-gont-6man-address-usage-recommendations

>     can they deal with those failure cases in an acceptable way?

Maybe this was in scope for RFC7934? -- That's the RFC that says host 
should be free to employ addresses as they wish. If anything, RFC4941 is 
below the umbrella of RFC7934.

> 4941bis is being demoted to proposed standard. 

As a non-native English speaker, I had to look up what "demoted" means. 
The dictionary says "move (someone) to a lower position or rank, usually 
as a punishment".

You can argue that in terms of rank, it has been lowered (does anybody 
care?). However, it worries me the idea that addressing flaws in a 
protocol is a kind of punishment.

> Which means we might live with these questions being unanswered, but I think we need to have some of the discussion around these in the deployment considerations.

I think discussion does not belong here (other than the note about 
possible effects of many addresses). The topic is a much larger topic, 
and involves many other aspects. Please see: 
draft-gont-6man-address-usage-recommendations

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 18:45:24 -0300

> addressed the problem posed in the Problem Statement (section 1.2 of

We devoted the whole RFC7721 to that.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 18:53:02 -0300

> Did anyone actually try to scan IPv6 subnets before privacy addresses?

I assume by "privacy" you meant "temporary" (RFC4941). If so: temporary 
addresses are irrelevant. They key change here was RFC7217. Pre-rfc7217, 
addresses still had patterns. Nowadays, slaac addresses don't.

FWIW, I have scanned IPv6 networks both before and after RFC7217.

> My IPv4/28 is continously being probed, but I rately see any IPv6 scan

Scan of your /64, or port scan of your IPv6 address(es)?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 18:57:24 -0300

> too high.   Maybe "Temporary Address Extensions for ..."

I agree. In fact, the title has always seemed confusing or misleading to 
me.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Jan 2020 18:54:03 -0300

> addresses, that they should be used in parallel and used for a long time.

The topic is much larger than rfc4941. Please see: 
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations

Thanks,

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jan 2020 09:45:21 +0100

> One thing to think about is /why/ the device needs the same address
    > over and over again.  It’s because something wants to contact it.  In
    > order for something to contact it, that something has to have a pointer
    > to it.   Where did it get the pointer?   If that’s a public place, then
    > privacy is somewhat out the window, but nevermind that for the moment.
    > If it’s a /private/ place, then as long as, when your address changes
    > because you moved locations, you update that registration, then there’s
    > no need to return to the address you had before at a particular
    > location when you return to that location.

Your battery powered device resumed from suspend, noticed it was in the same
place as before, so it configured the same address, and continued with the
TCP/DTLS/QUIC/etc. connection that was still up.