Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2016 08:32:56 +1200

>    [RFC4941] implies,
>    throughout the specification, that temporary addresses are generated
>    and employed along with temporary addresses.

s/temporary/stable/ in the last line.

Apart from that, I suspect that this draft tries to do too much and will
therefore be controversial.

An alternative is for it to say much less, e.g. only this, replacing
sections 3 through 7 and most of 9.

3. Update to RFC4941

   The temporary addresses specified in [RFC4941] MAY be used alone,
   without configuring any stable addresses. In particular the word
   'additional' is deleted from bullet 2 in Section 3 of RFC 4941.

Regards
   Brian

P.S. My personal experiment in running my laptop for several days
with no stable address has been completely successful. Including the
fact that my prototype of the Anima signaling protocol crashed after
a while, because the address it was relying on went away, which is of
course the expected behaviour.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 18:38:07 -0400

>    'additional' is deleted from bullet 2 in Section 3 of RFC 4941.

If we don't set requirements, then using the same IID in multiple
prefixes is fine, and  activities that employ different addresses
configured on the same interface could be correlated.

Besides, there would be no guidance other than RFC4941.

> course the expected behaviour.

So, the question is: can this be considered "acceptable" behavior?

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 May 2016 13:45:44 +0900

> So, the question is: can this be considered "acceptable" behavior?

Yes, because IPv6 address can expire and be replaced at any time in a
renumbering event.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 May 2016 16:54:21 +1200

> Yes, because IPv6 address can expire and be replaced at any time in a

Need I add that we will be putting some words about address stability or
its absence into the appropriate Anima documents. Obviously, we want the
autonomic networking infrastructure to be both stable and self-repairing.
But then I think we'd like all applications to have those properties.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 May 2016 18:34:47 -0400

On 05/26/2016 12:45 AM, Lorenzo Colitti wrote:
> On Tue, May 24, 2016 at 7:38 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

So... is, in your opinion, the likeliness of a renumbering event similar
to that of a node simply staying connected to the network for, say, one day?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 May 2016 10:57:22 +1200

> to that of a node simply staying connected to the network for, say, one day?

Allegedly, with some ISPs in some countries (Germany was mentioned), yes,
that is the case. My ISP in NZ gives me a new prefix each time the ADSL
reconnects, which with a poor quality circuit could be a frequent
occurrence. We really need all layers of the protocol stack to cope
elegantly with unplanned renumbering.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 May 2016 08:00:14 +0900

> to that of a node simply staying connected to the network for, say, one

Given the default lifetimes used by implementations, s/one day/one week/ .

Most apps don't need to care about IP addresses, but for the ones that do:
sorry, yes, IPv6 is not IPv4, and addresses can and do change. Failure to
deal with that is a bug.

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 May 2016 11:27:35 +1000

On 27 May 2016 8:57 AM, "Brian E Carpenter" <[email-masked]>
wrote:
> occurrence.

A business decision might be behind that.

Here in AU, it is common to use a fixed verses dynamic IPv4 address as the
major technical difference between residential and higher priced SOHO
plans, so it wouldn't surprise me of that thinking followed though to IPv6
delegated prefixes.

That thinking will probably encourage NAT66 to gain back address stability
that was provided by NAT44 in a similar situation, which I think is
unfortunately a simpler solution than to incorporate into all apps code to
cope with unexpected addressing changes.

This wasn't the model for the production residential deployment I worked on
in 2010 - the /64 on the PPPoE session was dynamic, while the delegated /56
was fixed for the customer.

Regards,
Mark.

>We really need all layers of the protocol stack to cope
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 May 2016 11:31:03 +0900

> A business decision might be behind that.
Actually reason I've heard given most often (definitely in Germany) is
privacy. Not sure if that is because it's easier to justify something by
saying "it's better for your privacy" than "it's better for our business
model" or because people do believe that this it's important to do it for
privacy reasons.

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 May 2016 13:16:54 +1000

> model" or because people do believe that this it's important to do it for

I understand it for the privacy reasons. I think it would be reasonable for
an ISP to provide customers, perhaps as a default with an opt out, periodic
phased change of delegated prefix over a time period that also provides
address stability for most applications e.g., once a day or possibly once a
week which would align with the preferred or valid lifetimes of RFC4941
addresses. A customer could be given an option to either switch that
changing off completely, initiate it manually, or be able to change the
default time period.

The trouble with what Brian's ISP is doing is that a transient fault is
causing the prefixes to change abruptly and that is fatal to existing TCP
connections using addresses from those prefixes. The point of attachment to
the network hasn't changed, so the prefixes shouldn't change in response to
the transient fault. Persistent prefixes across these sort of faults
wouldn't be contrary to the phased and intended changing over time of
delegated prefixes as above.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 May 2016 15:53:20 +1200

> delegated prefixes as above.

Next time I'm the sole user in the apartment, I'll try a very brief
disconnection just to check if the prefix really changes on a transient.
Normally the ADSL service stays up nicely, unless we power down the FritzBox.

   Brian

---

From: [email-masked]
Date: Mon, 30 May 2016 09:00:36 +0200

>   'additional' is deleted from bullet 2 in Section 3 of RFC 4941.

do we agree that the privacy of a given address is compromised as soon as it is used in a way that identifies the user?

that would imply that any address used to reach facebook, google, etc is tainted and cannot be used for any other connection.

pretty much all my devices have umbilical cords back to the "cloud" for applications, software updates, management, data dumping etc. those cords are also connected to an identity.

I'd argue that there are no deployed hosts / application combinations that can only use privacy addresses
(they might use privacy addresses as short lived stable addresses, but in that case they would be better off with stable addresses).

if the consequence of this is that a temporary address can only be used within a single connection, then I can guarantee you that there will be many networks that will not support that. bridges do not have unlimited space.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 May 2016 16:12:57 +0900

On Mon, May 30, 2016 at 4:00 PM, <[email-masked]> wrote:

> do we agree that the privacy of a given address is compromised as soon as
> it is used in a way that identifies the user?
>

In some sense, maybe, but...

> that would imply that any address used to reach facebook, google, etc is
> tainted and cannot be used for any other connection.
>

... privacy is not binary. An identifier is valid for 1 day poses much less
risk than one that is permanent for the life of the device. A party that
has *realtime* access to $COMPANY's webserver logs can track visitors to
$COMPANY's webservers all the time. But if you uninstall the $COMPANY app
and don't use $COMPANY's website for 1 day, that party cannot track you any
more via those means.

> can only use privacy addresses

Privacy addresses as defined by RFC4941? Perhaps not today, but it's not
hard to change that.

> if the consequence of this is that a temporary address can only be used
> within a single connection, then I can guarantee you that there will be
> many networks that will not support that. bridges do not have unlimited
> space.

But some can. 3GPP mobile networks and
draft-ietf-v6ops-unique-ipv6-prefix-per-host networks, need not be limited.
Residential networks aren't limited but they might have space for thousands
of ND cache entries, so thousands of addresses.

---

From: [email-masked]
Date: Mon, 30 May 2016 09:32:33 +0200

Lorenzo,

> ... privacy is not binary. An identifier is valid for 1 day poses much less risk than one that is permanent for the life of the device. A party that has *realtime* access to $COMPANY's webserver logs can track visitors to $COMPANY's webservers all the time. But if you uninstall the $COMPANY app and don't use $COMPANY's website for 1 day, that party cannot track you any more via those means.
> 
> Privacy addresses as defined by RFC4941? Perhaps not today, but it's not hard to change that.

give me a functioning host that has no umbilical cord somewhere that leaks identity...

> But some can. 3GPP mobile networks and draft-ietf-v6ops-unique-ipv6-prefix-per-host networks, need not be limited. Residential networks aren't limited but they might have space for thousands of ND cache entries, so thousands of addresses.

in 3GPP networks the subscriber is identified by the first 64 bits anyway.
there is no standardised way for a host to know if it is getting a unique /64 is it?
we're currently lacking a mechanism for the network to inform hosts that they aren't getting any addresses.

and I'm sure we can argue over the privacy properties of unique /64 per host.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 May 2016 12:00:54 +1200

> and I'm sure we can argue over the privacy properties of unique /64 per host.

Yes. But all I suggested is to remove the assumption in 4941 that there is always
a stable address. That is not the same thing as making a rule that there is
no stable address. It simply leaves the door open for an implementation to
allow no stable address, which is tricky at the moment.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 May 2016 09:43:55 +0900

> give me a functioning host that has no umbilical cord somewhere that leaks

What are you suggesting? That RFC4941 addresses don't provide any useful
privacy? Or that hosts can't use only RFC4941 addresses? Something else?

But that usually changes across disconnects, which can be initiated by the
host.

> there is no standardised way for a host to know if it is getting a unique

No, and I think it would be useful to have one.

---

From: [email-masked]
Date: Tue, 31 May 2016 09:23:28 +0200

Lorenzo,

> What are you suggesting? That RFC4941 addresses don't provide any useful privacy? Or that hosts can't use only RFC4941 addresses? Something else?

I'm making the observation that if you have a host with only RFC4941 addresses, you will end up using 4941 addresses as public addresses. and that you cannot reuse an address you have coupled identity with for any other connection.

4941 may improve privacy, but it clearly isn't sufficient in itself.

> But that usually changes across disconnects, which can be initiated by the host.
> 

DHCP PD?
we also need a mechanism to inform hosts that the network is out of addresses.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 May 2016 17:04:10 +0900

On Tue, May 31, 2016 at 4:23 PM, <[email-masked]> wrote:

> I'm making the observation that if you have a host with only RFC4941
> addresses, you will end up using 4941 addresses as public addresses.

Your statement does not mean much unless you define "public". The
difference between RFC 4941 addresses and other addresses is not are that
RFC 4941 addresses are not persistent.

> and that you cannot reuse an address you have coupled identity with for
> any other connection.
>

Can you explain the threat you're trying to counter? From what you say I
assume it has to involve some party with realtime access to part of your
communications that is able to correlate temporary addresses before they
change, but I'm not sure exactly what the threat model is. There is one
party that can always track 100% of what you do at the IP layer, and that
is the first-hop router. Is that what you're talking about?

> > No, and I think it would be useful to have one.

PD works, but most "/64 per host" deployments today do not use DHCPv6 PD
because they are 3GPP networks that use RAs. I would expect /64 per host
deployments to continue to be mostly RA-based, as discussed
in draft-ietf-v6ops-unique-ipv6-prefix-per-host. I think a "this prefix is
dedicated to you" flag in the RA would be useful.

we also need a mechanism to inform hosts that the network is out of
> addresses.

That's NOT RECOMMENDED by draft-ietf-v6ops-host-addr-availability.

---

From: [email-masked]
Date: Tue, 31 May 2016 10:36:52 +0200

Lorenzo,

> I'm making the observation that if you have a host with only RFC4941 addresses, you will end up using 4941 addresses as public addresses.
> 
> Your statement does not mean much unless you define "public". The difference between RFC 4941 addresses and other addresses is not are that RFC 4941 addresses are not persistent.

IPv6 addresses are not persistent. they are all ephemeral. it is just a matter of the lifetime.

a public address is one registered in DNS or some other external registry.
I would argue that the address you use to reach facebook (and thereby couple address and identity) you have made that address a public address.

> and that you cannot reuse an address you have coupled identity with for any other connection.
> 
> Can you explain the threat you're trying to counter? From what you say I assume it has to involve some party with realtime access to part of your communications that is able to correlate temporary addresses before they change, but I'm not sure exactly what the threat model is. There is one party that can always track 100% of what you do at the IP layer, and that is the first-hop router. Is that what you're talking about?
> 
> PD works, but most "/64 per host" deployments today do not use DHCPv6 PD because they are 3GPP networks that use RAs. I would expect /64 per host deployments to continue to be mostly RA-based, as discussed in draft-ietf-v6ops-unique-ipv6-prefix-per-host. I think a "this prefix is dedicated to you" flag in the RA would be useful.

that would likely require a change to the subnet model.

> That's NOT RECOMMENDED by draft-ietf-v6ops-host-addr-availability.

it doesn't really matter if that draft says that. in reality there is a limit. an address can either fail silently (possibly with an ICMP) or explicitly.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 May 2016 18:05:17 +0900

> IPv6 addresses are not persistent. they are all ephemeral. it is just a

Right, but there are many orders of magnitude differences between EUI-64
(~= life of the device) and RFC4941 (1 day).

> I would argue that the address you use to reach facebook (and thereby
> couple address and identity) you have made that address a public address.
>

I don't think it's the same. The DNS comes with no expectation of privacy.
If you use an address to talk to Facebook, it's not public in that people
cannot look it up. Facebook knows it, just like everyone else whom you
choose to talk to knows the address you used to talk to them. Your ISP
might know it. The NSA might know it. But again, what's the threat model?
Facebook telling someone else what address you used? For what purpose, and
what would happen if it did?

> I think a "this prefix is dedicated to you" flag in the RA would be useful.
>

Really? How is it different from, say, 127.0.0.0/8, or the delegated subnet
on a CPE router?

> it doesn't really matter if that draft says that. in reality there is a
> limit. an address can either fail silently (possibly with an ICMP) or
> explicitly.
>

I think failing silently is better.

---

From: [email-masked]
Date: Tue, 31 May 2016 11:19:23 +0200 (CEST)

> IPv6 addresses are not persistent. they are all ephemeral. it is just a matter of the lifetime.

While that may be technically true, it certainly goes against the way
a lot of people *think* about IPv6 addresses, and could easily lead to
misunderstanding.

For example, I have a fixed /64 for the link to my home server, and
another fixed /64 (out of a /56) for my home LAN. The server has these
two /64 addresses statically configured on separate Ethernet interfaces.
To me it's not particularly useful to think of these addresses as
ephemeral.

Steinar Haug, AS2116

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 31 May 2016 15:23:41 +0200

> To me it's not particularly useful to think of these addresses as

I think I agree.

Here too I have multiple addresses very persistent.

In the past there could have been some tendency to believe that in IPv6 
- contrary to IPv4 (nuance) - each address had a lifetime attached to 
it; because many IPv6 addresses in the initial deployments were 
auto-configured statelessly; that was a new - convenient at that time 
(nuance) - feature of IPv6, an argument persuading to migrate; it was 
better than having to install a DHCP server.  And these IPv6 addresses 
depend on the lifetime of the prefix in the RA.

But, since then, many IPv6 addresses are configured without receiving a 
prefix in an RA.  The manually configured addresses on linux last 
forever; there is no need to even type an argument to tell the lifetime 
is infinity.  Just type ifconfig eth0 1::1/64 and it's there forever.

(I dont know in cisco ios or bsd).

Alex

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 31 May 2016 18:33:47 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]

> To me it's not particularly useful to think of these addresses as

+1. I think that all IP addresses have trended to ephemeral, but only in part. The original model was stable addresses exclusively, and then things evolved. But the existence of stable addresses continues to be a fact of life. For instance, my home modem's IPv4 address changes (a) every time I reboot it, and (b) at some seemingly random interval, with no action required on my part.

At the same time, DHCPv6 certainly presumes address stability. That's the whole point. Equally, the client identifier option of DHCPv4 and v6 also presumes a known and stable IP address, based on the client's identity (function).

So I think it's problematic to assume that there's something fundamentally about IPv6 addresses, on this stability aspect.

Bert