Subject: Deprecating EUI-64 Based IPv6 Addresses (Fwd: New Version Notification for draft-gont-6man-deprecate-eui64-based-addresses-00.txt)

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Oct 2013 14:50:22 -0300

Folks,

We have posted a new I-D entitled "Deprecating EUI-64 Based IPv6
Addresses"
(http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-eui64-based-addresses-00.txt).

It's a spin-off of the work we've been doing on IPv6 addressing
secuity/privacy considerations
(draft-ietf-6man-ipv6-address-generation-privacy and
draft-ietf-6man-stable-privacy-addresses), and the idea had already been
discussed among several folks mstly off-list and at IETF meeting corridors.

Any comments will be appreciated.

Thanks!

Best regards,
Fernando

-------- Original Message --------
Subject: New Version Notification for
draft-gont-6man-deprecate-eui64-based-addresses-00.txt
Date: Mon, 21 Oct 2013 15:43:46 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, Will Liu
<[email-masked]>, Alissa Cooper <[email-masked]>, Dave Thaler
<[email-masked]>

A new version of I-D, draft-gont-6man-deprecate-eui64-based-addresses-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Filename:	 draft-gont-6man-deprecate-eui64-based-addresses
Revision:	 00
Title:		 Deprecating EUI-64 Based IPv6 Addresses
Creation date:	 2013-10-22
Group:		 Individual Submission
Number of pages: 6
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-eui64-based-addresses-00.txt
Status:
http://datatracker.ietf.org/doc/draft-gont-6man-deprecate-eui64-based-addresses
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses-00

Abstract:
   Stateless Address Autoconfiguration (SLAAC) for IPv6 typically
   results in hosts configuring one or more stable addresses composed of
   a network prefix advertised by a local router, and an Interface
   Identifier that typically embeds a hardware address (e.g., an IEEE
   LAN MAC address).  The security and privacy implications of embedding
   hardware addresses in the Interface Identifier have been known and
   understood for some time now, and some popular IPv6 implementations
   have already deviated from such scheme to mitigate these issues.
   This document deprecates the use of hardware addresses in IPv6
   Interface Identifiers, and recommends the use of an alternative
   scheme ([I-D.ietf-6man-stable-privacy-addresses]) for the generation
   of IPv6 stable addresses.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 24 Oct 2013 20:22:16 +0200

Hi,

I guess you also included the section regarding ra-privacy draft in this
draft.  Are you going to merge my draft with yours? 

@Alissia: Did I missed something? I guess we discussed to keep this in my
draft (the email that Ole and others were also included)

I am not totally disagree with deprecating the use of EUI-64 but I would
like to clarify the status of my draft that was active for some months.
Thanks,

-----------smile----------
Hosnieh
. success is a journey, not a destination..
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fernando Gont
Sent: Thursday, October 24, 2013 7:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: Deprecating EUI-64 Based IPv6 Addresses (Fwd: New Version
Notification for draft-gont-6man-deprecate-eui64-based-addresses-00.txt)

Folks,

We have posted a new I-D entitled "Deprecating EUI-64 Based IPv6 Addresses"
(http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-eui64-based-a
ddresses-00.txt).

Thanks!

Best regards,
Fernando

-------- Original Message --------

A new version of I-D, draft-gont-6man-deprecate-eui64-based-addresses-00.txt
has been successfully submitted by Fernando Gont and posted to the IETF
repository.

Filename:	 draft-gont-6man-deprecate-eui64-based-addresses
Revision:	 00
Title:		 Deprecating EUI-64 Based IPv6 Addresses
Creation date:	 2013-10-22
Group:		 Individual Submission
Number of pages: 6
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-eui64-based-ad
dresses-00.txt
Status:
http://datatracker.ietf.org/doc/draft-gont-6man-deprecate-eui64-based-addres
ses
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses-0
0

Abstract:

The IETF Secretariat

--
Fernando Gont
e-mail: [email-masked] || [email-masked] PGP Fingerprint: 7809
84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 25 Oct 2013 05:16:58 +0000

IMHO, we don't need to deprecate the address type. It's OK to have it. Deprecating it is a little more difficult than saying "oops", it means rethinking the link-local address, which even on non-Ethernet links stupidly presumes the presence of a MAC address and has no alternative. At most, we need to say that the use of EUI-64 addresses is optional.

Speaking for myself, I personally don't see the value of forcing a 64 bit IID on a LAN type that uses 48 bit MAC addresses anyway. RFC 1884 used the 48 bit MAC address, and I don't see a problem with saying that on LANs that use a MAC address of a certain length, SLAAC can presume that the IID (which might be optionally derived from the MAC address as a seed or value) would be the same length, and in general recommending that DHCP-assigned addresses do similarly as link-local addresses and legacy equipment are likely to use or be derived from the MAC address. Recall that the change to EUI-64 was in response to the IEEE's observation that MAC addresses would be moving to 64 bit on new technologies, and note that the IEEE is now (I'm told) discussing 128 bit MAC Addresses.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2013 04:39:57 -0300

Hi, Fred,

On 10/25/2013 02:16 AM, Fred Baker (fred) wrote:
> IMHO, we don't need to deprecate the address type. It's OK to have 
> it. Deprecating it is a little more difficult than saying "oops",
> it means rethinking the link-local address, which even on
> non-Ethernet links stupidly presumes the presence of a MAC address
> and has no alternative.

draft-ietf-6man-stable-privacy-addresses can be used for those... and
is albeit a more general scheme that can be still be employed if the
underlying interface doesn't have a MAC address.

> At most, we need to say that the use of EUI-64 addresses is
> optional.

You mean the advice should be "SHOULD do
draft-ietf-6man-stable-privacy-addresses but MAY do Modified EUI-64"?
or something else?

Me, I'd say that the propoer advice would seem to be "SHOULD NOT do
EUI-64", thus meaning that you can do it if you have a very good
reason to.

I don't personally bother if Modified EUI-64 is an option, as long as
it's not the default option (and as long as the consequences are
understood when overriding a more sane default).

> Speaking for myself, I personally don't see the value of forcing a
> 64 bit IID on a LAN type that uses 48 bit MAC addresses anyway.

Given that MAC address duplication is a fact, and that the
implications of embedding MAC addresses in the IID are well-known, I'm
not sure why the length of the underlying addresses should affect the
IPv6 subnet size. It results in less flexibility with no obvious gain
(but yes, subnet size is unrelated to this ID, and I understand it's a
controversial topic for some).

Thanks!

Cheers,

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 25 Oct 2013 18:54:39 +0200

If we're again at deprecating things one aspect that I'd really like
removed is this 64bit border for SLAAC over Ethernet.

One should be able to do SLAAC over Ethernet (and all its backward
compatible IEEE links) with Interface Identifiers optionally  shorter
than 64bit.

Alex

Le 24/10/2013 19:50, Fernando Gont a écrit :
> draft-ietf-6man-stable-privacy-addresses), and the idea had already
> been discussed among several folks mstly off-list and at IETF meeting
> corridors.
>
> Best regards, Fernando
> -------- Original Message -------- Subject: New Version Notification
> for draft-gont-6man-deprecate-eui64-based-addresses-00.txt Date: Mon,
> 21 Oct 2013 15:43:46 -0700 From: [email-masked] To:
> Fernando Gont <[email-masked]>, Will Liu
> <[email-masked]>, Alissa Cooper <[email-masked]>, Dave
> Thaler <[email-masked]>
>
>
> A new version of I-D,
> draft-gont-6man-deprecate-eui64-based-addresses-00.txt has been
> successfully submitted by Fernando Gont and posted to the IETF
> repository.
>
> Filename:	 draft-gont-6man-deprecate-eui64-based-addresses Revision:
> 00 Title:		 Deprecating EUI-64 Based IPv6 Addresses Creation date:
> 2013-10-22 Group:		 Individual Submission Number of pages: 6 URL:
Htmlized:
> Abstract: Stateless Address Autoconfiguration (SLAAC) for IPv6
> typically results in hosts configuring one or more stable addresses
> composed of a network prefix advertised by a local router, and an
> Interface Identifier that typically embeds a hardware address (e.g.,
> an IEEE LAN MAC address).  The security and privacy implications of
> embedding hardware addresses in the Interface Identifier have been
> known and understood for some time now, and some popular IPv6
> implementations have already deviated from such scheme to mitigate
> these issues. This document deprecates the use of hardware addresses
> in IPv6 Interface Identifiers, and recommends the use of an
> alternative scheme ([I-D.ietf-6man-stable-privacy-addresses]) for the
> generation of IPv6 stable addresses.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
>

---

From: Sander Steffann <[email-masked]>
Date: Fri, 25 Oct 2013 19:09:24 +0200

Hi,

> compatible IEEE links) with Interface Identifiers optionally  shorter

Now *that* would make those poor souls that only get one /64 from their ISP very happy :-)

I actually would like to see prefix lengths larger than 64 be supported for SLAAC. Is there actually a technical reason that it is not allowed? (hardware optimising for /64s come to mind now)  Otherwise I think it would be nice to make the specs a bit more flexible and allow it.

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2013 14:38:45 -0300

> compatible IEEE links) with Interface Identifiers optionally  shorter

If there's something else that needs to be fixed, then please:

1) Write an I-D that analyzes the problem, and proposes a workaround, and,

2) start a new thread. :-)

Let's keep this thread on-topic. ;-)

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

---

From: Tim Chown <[email-masked]>
Date: Fri, 25 Oct 2013 20:30:15 +0100

> Let's keep this thread on-topic. ;-)

Well, you're proposing deprecating EUI-64, so there is no longer any reason to be constrained to /64.... so your replacement should consider the possibility of it being used with longer subnet prefixes at some point in the future?

Tim

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2013 16:38:23 -0300

On 10/25/2013 04:30 PM, Tim Chown wrote:
>>> One should be able to do SLAAC over Ethernet (and all its
>>> backward compatible IEEE links) with Interface Identifiers
>>> optionally  shorter than 64bit.
>> 
> Well, you're proposing deprecating EUI-64, so there is no longer any
> reason to be constrained to /64.... 

Is this the sole reason for requiring subnets to be a /64?

> so your replacement should
> consider the possibility of it being used with longer subnet prefixes
> at some point in the future?

It is considered in draft-ietf-6man-stable-privacy-addresses, already
(although it notes that IPv6 are currently required to be 64 bits long)
-- i.e., if the /64 requirement were to change, we're still fine with
draft-ietf-6man-stable-privacy-addresses.

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Oct 2013 13:17:52 +1300

1. Why do people find it so hard to change the Subject when changing the subject?

2. Since we have a bunch of IID specs that all assume /64, and a large bunch of
code (and, I suspect, silicon) that assumes /64, we really need a very serious
practical analysis document before any possible decision.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2013 21:34:29 -0300

> practical analysis document before any possible decision.

That's why I think that relaxing the /64 requirement is a whole
different game. -- If anything, a first step would be to relax this for
hosts, and *at some point in the future*, relax it for routers --
otherwise, a "legacy" host that expects a /64 might break or fail to do
SLAAC if an updated router where to advertise, say, a /80.

OTOH, deprecating Modified EUI-64 is a local policy which is
incrementally-deployable.

Thanks,

---

From: Tim Chown <[email-masked]>
Date: Sat, 26 Oct 2013 08:41:42 +0100

> incrementally-deployable.

Well yes, there’s obviously a large deployed code base where /64 has been assumed. And changing that assumption may simply not be practical.

But… for example, some people who were concerned over the ND cache problem have run with /120 and DHCPv6. I’m not advocating that. Indeed the homenet arch text specifically mentions not using such “tricks" where the ISP only allocates one /64 to a home which requires multiple subnets.

I’m just suggesting it would be interesting to spend a little time to figure out where the /64 really is “burnt in” so that, if there were a desire to explore proposing a /80 or /96 or whatever for a future SLAAC, we would have a clearer idea of what the implications would be, and how/if an incremental progression to variable length SLAAC could be facilitated.

Tim

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 26 Oct 2013 07:56:49 +0000

> practical analysis document before any possible decision.

I find that less compelling than you, in that people can and do assign addresses using DHCP/DHCPv6, and for the most part use the addresses DNS or their communications peer tells them to use. For example, in data centers, I have heard suggestions from a number of quarters that would assign a /64 to a rack and /80's in tenants within it, using a /48 assigned by tenant-aware DHCP services in SDN networks. This would allow general data center routing to be stable (one routes to the rack) and leaves the differentiation among subnets for tenants local to the rack. The IPv6 prefix is a CIDR prefix, of a length selected by the operator, in a DHCP world.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 26 Oct 2013 08:42:50 +0000

> Is this the sole reason for requiring subnets to be a /64?

It was the driver for the change from RFC 1884's /80 (with a 48 bit MAC in the IID) to RFC 2373's /64 (with an EUI-64). I would think that any argument today about the /64 would be about inertia if not the EUI-64.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Oct 2013 11:40:51 +0200

On 25 Oct 2013, at 19:09, Sander Steffann <[email-masked]> wrote:

> make the specs a bit more flexible

Flexibility is overrated.

If you make it easier for a site to live with a /64 by making it easier to split that into /80 networks, the next thing you’ll notice that sites start to be allocated /80s.

There has never been a reason to give a site a /64.  So arguing “there is no reason to give a site a /80” is besides the point.  It is just a logical consequence of the principle of pushing out work to others.

Grüße, Carsten

PS.: Besides, a 64-bit IID is the minimum size where the birthday paradox is unlikely to bite you.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 26 Oct 2013 11:24:03 +0000

> PS.: Besides, a 64-bit IID is the minimum size where the birthday paradox is unlikely to bite you.

Given that, in the EUI-64 as we use it, 16 bits are absolutely predictable (we insert a well-known 16 bits), I'd be interested to see the proof that the modified EUI-64 and the EUI-48 are even *different* with respect to the birthday paradox.

Further, a discussion of the length of a field with respect to the birthday paradox depends on a lot of things. If the NICs in use tend to come from a single vendor (How many Lenovo PCs are their in your company?), 22 bits are highly likely to be that vendor's Vendor Code. 2 bits are predictable from the fact that it is an assigned unicast address. So the probability of a collision in that case is determined by 24 bits of the original MAC address, not the fact that it is represented in a 48 or 64 bit container.

If the birthday paradox tells us that a 64 bit Modified EUI-64 is adequate, then a random (24 + log2(number of vendor codes in use on a given LAN)) bit number is adequate.

This is also non-responsive to the DHCP question; the probability of assigning the same IID to two different interfaces in that case correlates with the ability of the operator to manage IIDs, not probability functions.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 26 Oct 2013 11:45:58 +0000

On Oct 25, 2013, at 9:39 AM, Fernando Gont <[email-masked]> wrote:

> You mean the advice should be "SHOULD do draft-ietf-6man-stable-privacy-addresses but MAY do Modified EUI-64"? or something else?
> 
> Me, I'd say that the propoer advice would seem to be "SHOULD NOT do EUI-64", thus meaning that you can do it if you have a very good reason to.
> 
> I don't personally bother if Modified EUI-64 is an option, as long as it's not the default option (and as long as the consequences are understood when overriding a more sane default).

I'll agree with you that it is fine as an option if not the default. Like you, I prefer a random number when SLAAC is in use. I find a lot of the discussion of "but you can't randomize the <whatever> bit" tiresome; there is no case that I'm aware of in which we look at individual bits in the IID to determine how it was generated, and we certainly do not try to extract a MAC address from it. So imposing MAC Address definitions on bits in the IID is an unreasonable hobble.

But "MAY" vs "SHOULD NOT"? If it can happen at all, then the vast majority of systems, that base the IID on a MAC address, have every reason to continue to do so. Until they have all been retired (how many systems in the world still run Windows 95?) we will have some that do. And by the way, the fact that someone in the IETF wrote an RFC tends to not motivate vendors; customer requirements motivate vendors. The MAC Address basis will get changed in time, but will do so when customers ask about it, not when the RFC Editor has finished the document publication process. From my very pragmatic perspective, there is value in recognizing the fact.

Oh, by the way, there will be those that think that cryptographically generated and therefore secure (for some definition of that term) addresses have value, and the IETF will continue to recommend that. And then there are addresses that are manually or DHCP/DHCPv6 assigned. You're welcome to your opinions; they're not going away soon.

So I would not quibble over the status of the RFC 4291/4862 model beyond saying that *IF* SLAAC is in use, one *SHOULD* use RFC 4941 or draft-ietf-6man-stable-privacy-addresses.

---

From: Scott Brim <[email-masked]>
Date: Sat, 26 Oct 2013 09:08:48 -0400

On Sat, Oct 26, 2013 at 7:45 AM, Fred Baker (fred) <[email-masked]> wrote:

> But "MAY" vs "SHOULD NOT"? If it can happen at all, then the vast majority
> of systems, that base the IID on a MAC address, have every reason to
> continue to do so.

It seems reasonable to me to document a recommendation, for the future,
even if it will take 15 years for the not-best-practice to fade.  Therefore
it seems reasonable to me to put in a SHOULD, along with all of the reasons
discussed here why the installed base doesn't have to at this time.

Scott

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 26 Oct 2013 14:07:43 +0000

On Oct 26, 2013, at 3:08 PM, Scott Brim <[email-masked]>
 wrote:

> But "MAY" vs "SHOULD NOT"? If it can happen at all, then the vast majority of systems, that base the IID on a MAC address, have every reason to continue to do so.
> 
> It seems reasonable to me to document a recommendation, for the future, even if it will take 15 years for the not-best-practice to fade.  Therefore it seems reasonable to me to put in a SHOULD, along with all of the reasons discussed here why the installed base doesn't have to at this time.

Which is the argument for saying "should 4861 or stable-privacy-addresses".

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Oct 2013 16:10:26 +0200

On 26 Oct 2013, at 13:24, Fred Baker (fred) <[email-masked]> wrote:

> Given that, in the EUI-64 as we use it,

As you use it.  (In 6LoWPAN, we don’t have 16 constant bits. But we do have OUIs.)

But I wasn’t talking about EUI-nn at all; these are supposed (I know) to be managed so there aren’t any collisions.  I was talking about using the IID in roles such as CGA, where it is really nice to have enough bits, and a small probability of collision.  64 bits (a couple of which are often taken for other fluff like CGA’s Sec) is just barely enough.

Grüße, Carsten

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 26 Oct 2013 14:22:28 +0000

> As you use it.  (In 6LoWPAN, we don’t have 16 constant bits. But we do have OUIs.)

If by 6LowPAN you mean IEEE 802.15.4, OK. That, of course, doesn't generalize to "all HAN networks", which was the charter of 6LowPAN. We could discuss G.9972, IEEE 1901 (which has both an Internet Access and a HAN link layer specification), and others. But I digress.

In this context, we're talking about RFCs 4291, 4862, and 4941, draft-ietf-6man-stable-privacy-addresses, and the silly assumption that interfaces necessarily have EUI-anything addresses to base their IIDs on.

> But I wasn’t talking about EUI-nn at all; these are supposed (I know) to be managed so there aren’t any collisions.  I was talking about using the IID in roles such as CGA, where it is really nice…

In which case a stable privacy address or an RFC 4941 address would not be directly useful.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 27 Oct 2013 17:55:00 +0900

On Sat, Oct 26, 2013 at 5:42 PM, Fred Baker (fred) <[email-masked]> wrote:

> It was the driver for the change from RFC 1884's /80 (with a 48 bit MAC in
> the IID) to RFC 2373's /64 (with an EUI-64). I would think that any
> argument today about the /64 would be about inertia if not the EUI-64.
>

I think the split /64 extremely useful because it provides a minimum size
assignment that makes autoconfiguration easy, allows privacy, and gives
users the capability to number multiple applications or multiple devices
without having to use NAT.

I have personally had more than one conversation with operators who cannot
see why they would ever want to give a user more than one IPv6 address,
because a) that's what they do in IPv4, and b) a /64 is a waste of space.
Mobile operators seem particularly prone to this line of reasoning. Telling
them that there's plenty of space to give every device a /64, or that their
service is better if users are allowed more than a /64 for privacy reasons,
or that it allows users to connect multiple devices, etc. has no effect.
Saying "it's specified in the standards and some implementations might not
work if you don't do it" has proven to be a much better argument so far.
Often those same operators then come to appreciate the flexibility once
they have deployed using /64 or larger and see how it makes things better
and easier.

It's true that some operators can decide to use only DHCPv6 and hand out
/128s today, but since some platforms don't support DHCPv6, that decision
has compatibility consequences.

If we ditch the one-size-fits all subnet size and leave the subnet size up
to the operator, it's virtually certain that we will end up with some
deployments that hand out /128s. That makes IPv4-style NAT virtually
inevitable, because users will want to connect more than one device
regardless of what the operator wants them to do. Since apps have to adapt
to the lowest-common denominator connection, there's a good chance that
apps will have to keep IPv4-style NAT traversal mechanisms around forever.
I think that's a fundamentally bad deal, because there's no real reason to
employ address sharing if you have enough addresses; the side-effects of
NAT that people seem to like (e.g., security) come from stateful inpection,
not from the translation itself.

On the other hand, if we do keep a one-size-fits-all subnet size, then I
think /64 is the best choice, not just for backwards compatibility reasons,
but for lots of other reasons such as because it splits the address in two
halves that are natural machine integer sizes, provides enough space to
protect against the birthday paradox, and so on.

Cheers,
Lorenzo

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 27 Oct 2013 10:26:49 +0100

On 2013-10-27 09:55, Lorenzo Colitti wrote:
> On Sat, Oct 26, 2013 at 5:42 PM, Fred Baker (fred) <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     It was the driver for the change from RFC 1884's /80 (with a 48 bit
>     MAC in the IID) to RFC 2373's /64 (with an EUI-64). I would think
>     that any argument today about the /64 would be about inertia if not
>     the EUI-64.
> 
> 
> I think the split /64 extremely useful because it provides a minimum
> size assignment that makes autoconfiguration easy,

Absolutely true; but with DHCP any length would work which though is
stateful. Note that IPv4 has a autoconfig scheme too and that works fine
with a /16, thus only 16bits "lost" (as some people would say).

I am happy with the /64 though, it is nice and clean and you never have
to figure out the netmask anymore.

> allows privacy,

IMHO big nonsense. The company (amongst many others!) you work for uses
amongst others cookies to track their people, and if they really bother
could even use natural language structure, search query types, and other
behavior for breaking this 'privacy'. Also note that even if the last
64bits are random, your company should be more than able to say "oh,
there are typically X users in there, it likely is Y"...

Thus privacy, far from. The only 'privacy' you get on the IP level is
when you use the useless-for-ACL/logging is when you move to a different
network (different /48 at that, not even the /64) as then they can't
directly associate you as the previous person. But then again, those
cookies you are setting are pretty static and will nicely link them up
again.

IP-level privacy does not exist as long as upper layers have different
ways of defeating them and/or when there are statistically too few users
in even a /48.

> and gives users the capability to number multiple applications or multiple
> devices without having to use NAT.

There are a bunch of ISPs who give out "native IPv6", quite a few of
these give exactly 1 IPv6 address to their users..

As long as they do not get a routed prefix and cannot get it through
DHCPv6-PD or some other method, the user will have to NAT or do other
tricks.

For ISPs it is a business case: you want more IPs (IPv4 or IPv6), then
pay for them.

And that premise will never go away unfortunately.

As such, the rest of your mail is already happening unfortunately.

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 27 Oct 2013 18:41:46 +0900

On Sun, Oct 27, 2013 at 6:26 PM, Jeroen Massar <[email-masked]> wrote:

> IMHO big nonsense. The company (amongst many others!) you work for uses amongst
> others cookies to track their people,
>

Not sure we want to get into that argument here, but there's a difference
because as a user you have the capability to control what cookies you
accept and when you clear them (even via a browser extension that
periodically nukes them, if you wish), but you can't really control what
address your ISP gives you.

> DHCPv6-PD or some other method, the user will have to NAT or do other

That's interesting. I was not aware of any, at least in the residential
space. All the large deployments I know of (which presumably constitute the
vast majority of residential IPv6 access, since they're so large) hand out
at least a /64 and in most cases at least a /60. Do you have pointers to
ISPs that do this?

> For ISPs it is a business case: you want more IPs (IPv4 or IPv6), then

They tried that in IPv4 and it didn't work, and we ended up paying the
price in increased application complexity. Here's to pigheadedly hoping we
can do better this time. :-)

Though to be fair, in IPv4 (but not in IPv6) there is real scarcity, so
it's a bit more justifiable to say that addresses need to be paid for.

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 27 Oct 2013 11:17:05 +0100

On 2013-10-27 10:41, Lorenzo Colitti wrote:
> On Sun, Oct 27, 2013 at 6:26 PM, Jeroen Massar <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     IMHO big nonsense. The company (amongst many others!) you work for
>     uses amongst others cookies to track their people,
> 
> 
> Not sure we want to get into that argument here, but there's a
> difference because as a user you have the capability to control what
> cookies you accept and when you clear them (even via a browser extension
> that periodically nukes them, if you wish), but you can't really control
> what address your ISP gives you.

Cookies is just one of the many ways as per:

http://panopticlick.eff.org/

And note my comment about statistics. There is no such thing as
'privacy' on the HTTP level.

Thus stating that it is there for IPv6 in general because there are
64bits that one can randomize is nonsense too.

> space. All the large deployments I know of (which presumably constitute
> the vast majority of residential IPv6 access, since they're so large)
> hand out at least a /64 and in most cases at least a /60. Do you have
> pointers to ISPs that do this?

Note that I state 'routed'.

You probably mean the ISPs who require ND-proxy to get that /64 on your
side of the link? :)

Amongst others: http://www.ipsidixit.net/2010/03/24/239/ one of many
articles on this for free.fr (the "largest IPv6 native deployment").

Liberty Global (Unity Media in Germany) is playing with DS-Lite, hence
you get 1 IPv6 address and a CGN IPv4 address (which is useless in
prime-time as those boxes cannot handle all the BitTorrent and other
heavy traffic flows).

Also for the US centric:
http://www.comcast6.net/index.php/ipv6-deployment-faq
8<----------------
With IPv6 for standalone computers, what size IPv6 prefix will I receive?
We will allocate a single IPv6 address (/128), since we know that only a
single device is connecting, with no additional need to sub-net. We plan
to continue to assess address allocation policies as we deploy,
particularly given how very new IPv6 is from an operational standpoint
globally.

When will Comcast support IPv6 for home networking?
Comcast is planning to begin pilot market deployment of IPv6 home
networking support in the near future.
------------------>8

Though that might not match reality (as I recall having heard other
stories, no facts on that at hand though) and I know at least business
folks getting a /48, that is, if they have enough leverage to get it
enabled on their link.

Oh and we are then not even talking about even the possibility of a
static prefix, typically one will rotate every 24 hours because of
'privacy' reasons and other nice annoyances to make sure people will
cough up for the business prefix...

> price in increased application complexity. Here's to pigheadedly hoping
> we can do better this time. :-)

Hey, I hope so too ;)

> it's a bit more justifiable to say that addresses need to be paid for.

Partially true yes, lets not go down the spammer-rabbit-hole ;)

Greets,
 Jeroen

---

From: Ray Hunter <[email-masked]>
Date: Sun, 27 Oct 2013 11:52:41 +0100

> protect against the birthday paradox, and so on.
If I read the above, you seem to be arguing that dropping fixed /64
would be a bad thing because operators will use this as an opportunity
to limit their customers to a single IPv6 address, and yet
simultaneously you seem to be arguing that maintaing a fixed /64 is a
good thing even though it limits customers to a single subnet.

Do I understand you correctly? The logic doesn't seem very
self-consistent to me.

Me? I believe in CIDR.

-- 
Regards,
RayH

---

From: Scott Brim <[email-masked]>
Date: Sun, 27 Oct 2013 07:57:20 -0400

>
> Not sure we want to get into that argument here, but

I _don't_ want to get into it here but I want to briefly support Lorenzo on
privacy.  Privacy through controlling tracking of an IP address is very
different in mechanism and result from higher layer end-to-end privacy.

Scott

---

From: Karl Auer <[email-masked]>
Date: Sun, 27 Oct 2013 23:19:07 +1100

> different in mechanism and result from higher layer end-to-end privacy.

Me too.

It's easy to forget that the Internet does not consist solely of the
web. There are plenty of other things that people may not want to have
tracked via the IP address, and who knows what other protocols may yet
be developed that could benefit from the privacy extensions of IPv6?

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 27 Oct 2013 14:04:07 +0100

On 2013-10-27 12:57, Scott Brim wrote:
> 
> On Oct 27, 2013 5:42 AM, "Lorenzo Colitti" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
> I _don't_ want to get into it here but I want to briefly support Lorenzo
> on privacy.  Privacy through controlling tracking of an IP address is
> very different in mechanism and result from higher layer end-to-end
> privacy. 

It does not matter if you have 1 IPv4 address with 2000 people behind
it, or 1 /48 with 2000 people behind it.

The algorithms to de-anonimize and differentiate between the real hosts
behind them exist.

Cookies are one way to do that, complete browser profiles or other
differences in the client, be that the tcp stack level another. For
other protocols it is all much easier as they are typically already
authenticated anyway or have other bits.

As such any of these 'privacy extensions' are futile and just a lie to
the user of them that they are more "private" as for most home networks
they simply are not.

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 27 Oct 2013 22:36:10 +0900

> http://panopticlick.eff.org/

Ok, we shouldn't have gotten into this debate. I think that's worthless
(every one of tens of millions of iPhones will return the same result... ).
But sure. There are other ways to track people than via IP addresses.

> You probably mean the ISPs who require ND-proxy to get that /64 on your

No, you're misinformed. I mean real DHCPv6 PD. See below.

> articles on this for free.fr (the "largest IPv6 native deployment").

Since forever Free.fr has been handing out /60 to all its customers (it's
the maximum they can hand out with 6rd using their IPv6 allocation size),
and sends an RA with a /64 by default. I believe that if you configure it
they'll send out one different prefix for each port on the box. Look for
them in your logs; I'm sure you'll still see some ff:fe in there, which
probably means autoconf.

> prime-time as those boxes cannot handle all the BitTorrent and other

DS-lite is not limited to one IPv6 address. Where did you get that from? As
for DS-Lite, well, you know, there's not a lot of IPv4 left.

> http://www.comcast6.net/index.php/ipv6-deployment-faq

That information is out of date. Comcast rolled out DHCPv6 IA_NA first, and
then (without updating the FAQ, I guess) started turning on PD (with /64s)
during 2012. Now they hand out a /60 via PD everywhere.

http://www.comcast6.net/index.php/8-ipv6-trial-news-and-information/80-ipv6-offers-many-more-ip-addresses
http://www.dslreports.com/forum/r28725662-IPv6-ALL-areas-support-60-now.

> cough up for the business prefix...

Nope, Comcast doesn't do that - neither in IPv4 nor in IPv6. Some European
ISPs do. Where did you get your facts from?

Please check your information before presenting it as facts in this sort of
policy discussion. We really don't want to come to the wrong conclusion
because we have the wrong data.

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 27 Oct 2013 22:39:14 +0900

> Do I understand you correctly? The logic doesn't seem very

No, that's what I meant. I think we should keep the fixed "one subnet ==
one /64" model, and that every customer should get at more than one subnet.
The early adopters in the industry seem to be settling on /60, which is a
bit small but still quite flexible.

> Me? I believe in CIDR.

So do I, as long as it's larger than /64.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 27 Oct 2013 10:08:19 -0400

Hi, Fred,

On 10/26/2013 10:07 AM, Fred Baker (fred) wrote:
> 
>> It seems reasonable to me to document a recommendation, for the 
>> future, even if it will take 15 years for the not-best-practice 
>> to fade.  Therefore it seems reasonable to me to put in a
>> SHOULD, along with all of the reasons discussed here why the
>> installed base doesn't have to at this time.
> 

Not sure I follow: stable-privacy-addresses is expected to be used
along RFC4862..

Am I missing something?

Thanks,
- -- 
Fernando Gont

---

From: Fernando Gont <[email-masked]>
Date: Sun, 27 Oct 2013 10:36:34 -0400

On 10/26/2013 03:41 AM, Tim Chown wrote:
>> different game. -- If anything, a first step would be to relax this
>> for hosts, and *at some point in the future*, relax it for routers
>> -- otherwise, a "legacy" host that expects a /64 might break or
>> fail to do SLAAC if an updated router where to advertise, say, a
>> /80.
>> 
> Well yes, there’s obviously a large deployed code base where /64 has
> been assumed. And changing that assumption may simply not be
> practical.

I'm not sure about whether that's practical or not.. but just wanted to
note that it's a different game.

> But… for example, some people who were concerned over the ND cache
> problem have run with /120 and DHCPv6. 

Those should call a lemon a lemon, and ask their vendors to fix their ND
implementations ;-).

> I’m not advocating that.
> Indeed the homenet arch text specifically mentions not using such
> “tricks" where the ISP only allocates one /64 to a home which
> requires multiple subnets.

So.. what do ou do in that case... IPv6 NAT?

> I’m just suggesting it would be interesting to spend a little time to
> figure out where the /64 really is “burnt in” so that, if there were
> a desire to explore proposing a /80 or /96 or whatever for a future
> SLAAC, we would have a clearer idea of what the implications would
> be, and how/if an incremental progression to variable length SLAAC
> could be facilitated.

Agreed.

Thanks,

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 27 Oct 2013 15:50:09 +0100

On Sun, Oct 27, 2013 at 12:57 PM, Scott Brim <[email-masked]> wrote:
>>> amongst others cookies to track their people,
>>

think I'll add a +1 to this one.

Privacy isn't just one single thing. That the user might lose privacy
elsewhere in the entire stack that make up Internet, that's NOT an
argument to give up /64 because we have lost privacy anyhow.

This /64 split is a good construction. Many reasons has already been
given but the three reason I can think of right now
- it split of the entire address space into two equal sized parts,
Net-prefix, and LAN-prefix
- this split is universal. It is probably one of the few thing we have
that is that clear. Let us not give it up.
- a /64 size match lots of other bit sized things

Yes you can argue any of them into death and back, but sometimes we
have to make a choice and stick with it. I'll say we stick with this
/64 LAN size.

That ISP, or whoever else, chose to give end-users a /128 do not
undermine the /64 LAN size. It is after all really upto each and every
operator to chose how they want to run their operations. All we can do
is give recommendation.

------------------------------
Roger Jorgensen      | - ROJO9-RIPE  - RJ85P-NORID
[email-masked]           | - The Future is IPv6
-------------------------------------------------------

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

---

From: Roger Jørgensen <[email-masked]>
Date: Sun, 27 Oct 2013 15:59:19 +0100

> Any comments will be appreciated.

I've read through the other threads and I still have this one question
- why bother?

I see several reasons to not recommend or require eui64 based
addresses, but that is all.
I see no real reason to deprecate it really, the affected userbase and
implementation are way too big to go to that step.
It is probably one of the cases that people will stop using it if we
let them have the options of not using it, so I say - let time do the
job of deprecating it.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Octavio Alvarez <[email-masked]>
Date: Sun, 27 Oct 2013 08:53:42 -0700

> there are typically X users in there, it likely is Y"...

Then why deprecate EUI-64?

---

From: Octavio Alvarez <[email-masked]>
Date: Sun, 27 Oct 2013 08:57:15 -0700

> If you make it easier for a site to live with a /64 by making it easier to split that into /80 networks, the next thing you’ll notice that sites start to be allocated /80s.

... and proposals to allow up to /64s in the global routing table.

---

From: Octavio Alvarez <[email-masked]>
Date: Sun, 27 Oct 2013 09:03:31 -0700

> Well, you're proposing deprecating EUI-64, so there is no longer any reason to be constrained to /64.... so your replacement should consider the possibility of it being used with longer subnet pref…

http://etherealmind.com/allocating-64-wasteful-ipv6-not/

It quotes RFC 5375.

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 27 Oct 2013 17:10:10 +0100

TLDR: /64 on a link is great, keep it; /48 or /56 standardized per site
is great for renumbering (at least the plan); IPv6 "privacy address" is
not really private anyway, thus bad to list as a reason for keeping /64.

On 2013-10-27 14:36, Lorenzo Colitti wrote:
> On Sun, Oct 27, 2013 at 7:17 PM, Jeroen Massar <[email-masked]

The point that I am trying to make, but the one you do not want to hear,
is that "IPv6 privacy" does not exist, hence stating that it is a 'good
thing for having a /64 or /48' is just stating a muyth similar to
stating that "IPv6 is more secure than IPv4 as it has IPSEC" and other
such myths.

Thus, I'll nicely ask to stop making statements like that as they are
not true, and never have been. (though they look like it, and as
everybody keeps echoing them they sound like it, they are not)

If you want proper privacy then use Tor or similar systems.
(and lots of people debate if those keep you truly private...)

I'll give another few comments on your statements below, just to show
how easily they are debunked and thus how false they are.

That all said, /64's are great IMHO.

Though if there is a significant reason why people think the address
space is too small and they need to get rid of the 'barrier', then write
up a proper draft, spell out your reasoning and we can discuss that.

>From my POV there is enough space, there are just ISPs who are cutting
people short in how much they want to give out as they are stuck in
IPv4-think, which is logical in a way when they have dealt with a lot of
problems address squeeze or problems getting more space from a RIR. The
solution to these folks is education, not changes to a proper architecture.

Don't forget that one of the primary reasons for doing /48 at every site
was that it allows "easier" renumbering (at least one can keep the same
address plan ;)

As for networks that want to use shorter-than /64, they can. DHCPv6
allows this scenario. The IETF though should never be recommending any
of that and neither should the RIRs, who should actually IMHO enforce
that LIRs give out proper address space to users and not force users to
a single /128 when the ISP has more than enough space and can easily go
to the RIR to get more when they need it (though if an ISP has to return
for more they made a mistake in their initial allocation if it was only
made a few years ago...).

Greets,
 Jeroen

--

> (every one of tens of millions of iPhones will return the same result...
> ). But sure. There are other ways to track people than via IP addresses.

Just tested with my iPad2, which is just another IOS device:

"Your browser fingerprint appears to be unique amongst the 3.535.368
tested so far"

the primary reason apparently:
- User Agent, which included the exact User-Agent string
  not everybody is running IOS 7.0.3 yet = 18.95bits, 1/505052.57
- Browser Plugin Detail = 17.29 bits, 1/160698.55
  Not everybody has Bria and other Apps that allow IOS to accept
  certain media types.

Panopticlick wins again. That is HTTP indeed, but HTTP is what these
devices are being used for, not IP level so much. And if you make one
lousy connection outbound over HTTP that identifies you then that IP
address has compromised you. Unless (but that is hard to see) IOS cycles
the IPv6 address for every app; with very few apps doing IPv6 though
that is hard to test easily.

Also Google/Bing/Yahoo or whatever search engine you are allowed to use
for IDFA for some extra work there to make it possible to track you.
Though they claim you are anonymous, they track an identity which can be
extremely easily linked to a person with help of .

Next to that some apps just for 'fun' insert your mac address or other
identifying information into their requests.

Note that iPhones are predominantly HTTP users and thus have all the
problems and tracking features that come along with it. If you are all
behind a NAT it gets tricker, but nobody cares about IP level tracking,
the applications take care of that; people love logging in to social
networks.

Those 10m iphones also do not live behind the same IP address, or even
/48; though it is likely in a IPv6-environment that there will be a few
thousand in a single /48 indeed, that is, if the operator choses to
deploy them that way. It is often enough seen to deploy behind a
transparent proxy.

Still, statistics allow one to discern between them.

> No, you're misinformed. I mean real DHCPv6 PD. See below.

I've not seen DHCPv6 PD live in action at any of these ISPs; I have seen
lots of people do NDproxy tricks though.

>     articles on this for free.fr <http://free.fr> (the "largest IPv6
>     native deployment").
> 
> 
> Since forever Free.fr has been handing out /60 to all its customers

Hence why the above linked article exists and many other similar ones.

> (it's the maximum they can hand out with 6rd using their IPv6 allocation
> size), and sends an RA with a /64 by default. I believe that if you
> configure it they'll send out one different prefix for each port on the
> box. Look for them in your logs; I'm sure you'll still see some ff:fe in
> there, which probably means autoconf.

> DS-lite is not limited to one IPv6 address. Where did you get that from?

While the protocol and the tools might not be limited to that, this is
how it is being deployed.

IPv6 (this whole thread :) is not limited to a single /128 either, but
this is how it is being deployed in the wide by various ISPs (cheap
hosters are a primary example, but there are also consumer ISPs, eg
Liberty Global mentioned above) who do.

> As for DS-Lite, well, you know, there's not a lot of IPv4 left.

There indeed is not; in this specific example they converted people who
had proper IPv4 connectivity to DSLITE and the former IPv4 addresses are
now used for the hosting offering of the ISP. The pain is thus being
diverted a bit.

> Nope, Comcast doesn't do that - neither in IPv4 nor in IPv6. Some
> European ISPs do. Where did you get your facts from?

I didn't say that Comcast did, note that I pointed out for them the
helpdesk article which describes, apparently stale, details about their
deployment.

> Please check your information before presenting it as facts in this sort
> of policy discussion. We really don't want to come to the wrong
> conclusion because we have the wrong data.

I fully agree, see above about your iphones statement where you provide
no facts but all statements.

Note that I am pointing out documentation that is available. That these
authoritative sources are out of date not much I can do about.

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Oct 2013 03:06:16 +0900

On Mon, Oct 28, 2013 at 1:10 AM, Jeroen Massar <[email-masked]> wrote:

> is that "IPv6 privacy" does not exist

Perhaps, but let's not argue that on this thread, which is about subnet
sizes.

> Hence why the above linked article exists and many other similar ones.

The article exists because the writer wanted to put a firewall between the
ISP router and the other machines. You can do that with DHCPv6 PD but not
with native routing (just like you can't do that in IPv4 without NAT). It
doesn't support the assertion that free.fr assigns single IPv6 addresses to
their users.

For free.fr docs on this:

http://ripe58.ripe.net/content/presentations/ipv6-free.pdf (addressing
plan, mentions /60 per user)
http://aide.ma-freebox.fr/ipv6.html (look at the screenshots, they even
allow you to statically route some of your /64s to nexthops you specify)

> Liberty Global mentioned above) who do.

Where did you get the information that unitymedia only provide a single
/128? http://www.unitymediakabelbwforum.de/viewtopic.php?f=53&t=23981 and
http://www.youtube.com/watch?v=K0hT1PpfxxQ suggests the CPE gets a /57.

> authoritative sources are out of date not much I can do about.

Of course you can't do anything about out-of-date documentation, but please
do a little more research before making confident statements based on said
out-of-date documentation. People might believe you, and they'd be wrong.

Specifically, I think the "quite a few [ISPs] give exactly 1 IPv6 address
to their users" statement is not true in the case of mainstream residential
ISPs - I think they all provide at least a /64, and more usually at least a
/60.

---

From: TJ <[email-masked]>
Date: Sun, 27 Oct 2013 15:04:04 -0400

> > very different in mechanism and result from higher layer end-to-end

First off, ++1 to Lorenzo on all counts (and Scott, Karl).

> authenticated anyway or have other bits.

Having said that, FWIW - I partially disagree with Jeron here - it does
matter.  A user can have browser extensions, multiple browsers (or mutliple
VMs with different OSes) and have a fairly good level of privacy if so
desires - as long as the underlying L3 provisioned does not prevent it.  Is
may not be exactly mainstream / commonplace, but not uncommon enough to
ignore (IMHO) either.

/TJ

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 27 Oct 2013 13:43:45 -0700 (PDT)

<snip>
>
>Specifically, I think the "quite a few [ISPs] give exactly 1 IPv6 address to their users" statement is not true in the case of mainstream residential ISPs - I think they all provide at least a /64, and more usually at least a /60.
>

During their IPv6 trial, Internode gave out /60s. When they deployed production residential broadband IPv6 in 2011 (which I worked on), the provided a dynamic /64 to the CPE via SLAAC (which allows direct connection of a PC as an alternative to using a CPE), and a static /56 via DHCPv6-PD. They fairly recently said they now have 10% of their customers using IPv6, as they've been enabling it by default on all new customer connections and providing IPv6 enabled CPE with it. Going by the published customer numbers, 10% is in the order of 16 000 to 18 000 services with native IPv6 connectivity.

http://www.internode.on.net/news/2013/06/309.php

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 27 Oct 2013 21:20:56 +0000

On Oct 27, 2013, at 3:08 PM, Fernando Gont <[email-masked]>
 wrote:

> Signed PGP part

Sorry, yes. Off-by-one error.

> Thanks,

------------------------------------------------------
8 issues in virtual infrastructure
http://dcrocker.net/#fallacies

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 28 Oct 2013 07:53:47 +0100

FWIW.
I'm working for the #1CPE vendor, managed CPEs that is, and I can confirm that majority of our customers ( ISP's/Telco's) is handing out a /60 or /56.  It's very rare, although they exist, to only see /64s handed out to the (residential) CPE.
Some do add ia_na to it to number the WAN interface, it's an exception to see slaac on wan to number wan intf these days @ our customers, although it is being used.

WRT privacy etc
Some of our customers re-apply the IPv4 approach on handing out IPv6 pds, i.e. with IPv4, they renewed the public IPv4 address every XX hours and re-apply this to ia_pd.  Whether or not this is/was for economics rather than privacy purposes (more charged for static IPv4 @ some customers, but these being more business than residential customers) is another question of course.

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith
Sent: zondag 27 oktober 2013 21:44
To: Lorenzo Colitti; Jeroen Massar
Cc: <[email-masked]>
Subject: Re: Why /64

<snip>

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 09:24:58 +0100

> Then why deprecate EUI-64?

I did not state anything like that. I have only raised concern about
stating that "IPv6 privacy addresses" are a real thing.

I am pro /64 per link and a /48 for Enterprise and at least /56 for
Home-user sites. (/60 is too tiny and not flexible enough)

Greets,
 Jeroen

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 28 Oct 2013 09:28:03 +0100

+1 for the /64 on the link and /48 for enterprise, 

but "at least" a /56 for home (with /60 too tiny) ??
Can you elaborate on why you would need more than 4 bits subnets @ home?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeroen Massar
Sent: maandag 28 oktober 2013 9:25
To: Octavio Alvarez
Cc: <[email-masked]>
Subject: Re: Why /64

On 2013-10-27 16:53, Octavio Alvarez wrote:
>> uses amongst others cookies to track their people, and if they really 
>> bother could even use natural language structure, search query types, 
>> and other behavior for breaking this 'privacy'. Also note that even 
>> if the last 64bits are random, your company should be more than able 
>> to say "oh, there are typically X users in there, it likely is Y"...
> 

I did not state anything like that. I have only raised concern about stating that "IPv6 privacy addresses" are a real thing.

I am pro /64 per link and a /48 for Enterprise and at least /56 for Home-user sites. (/60 is too tiny and not flexible enough)

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 09:35:17 +0100

> First off, ++1 to Lorenzo on all counts (and Scott, Karl).

You can +1 without facts or any backing details, but the fun thing is,
it is no difference at all: privacy addresses do not make you "private"
in any way or form.

The only thing higher levels gives the adversary is a easier detection
and correlation. But unless you have exactly the same packet signature
and you are hitting the same sites as other people in your /64 or /48
you are unique.

Please note that a IPv6 Privacy Address is for a period of time, not per
application (at least I have not seen an OS do that yet, it could, but
they do not).

As such, when your HTTP browser goes to a site, that IP address is
identified as you; then anything else goes to another site, and voila,
they know that that connection is also related to you. Then your privacy
time window expires, you connect to that second site again, which is not
HTTP, but as you have been there just a bit ago, there is a high chance
that that is still you.

> matter.

With what exact part do you disagree and what part does matter?

> A user can have browser extensions, multiple browsers (or
> mutliple VMs with different OSes) and have a fairly good level of
> privacy if so desires - as long as the underlying L3 provisioned does
> not prevent it.  Is may not be exactly mainstream / commonplace, but not
> uncommon enough to ignore (IMHO) either.

Even though that would give you separate addresses and would initially
give that user separate identities that are being tracked, that user is
still coming out of the same /64 or /48.

Thus on the IP level indeed it initially looks like multiple users. But
as various organizations are pretty good at estimating amount of users
in a location, they can easily guess that it is the same person anyway.

I'll state again: if you want privacy use a mixnet, eg Tor.
(and even then you are exposing all your random bits, thus beware what
protocols and tools you use)

Greets,
 Jeroen

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 28 Oct 2013 09:36:36 +0100

Hi,

On 26.10.2013 09:41, Tim Chown wrote:
> problem have run with /120 and DHCPv6. I’m not advocating that.

+1

Regards,
 Roland

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 09:46:03 +0100

> Can you elaborate on why you would need more than 4 bits subnets @ home?

Because I am one of the examples where I have, at home, already have
more than 16 VLANs at home.

But I might be special, I can only assume several other people here have
similar large home networks. I have so many VLANs as I like things in
separate networks, many do not even get Internet connectivity but they
are globally addressable. Note that things go very quickly when you have
things like IPv6 connected lightbulbs; though these are in a VLAN per
room so that I can send a multicast message to that VLAN and turn them
all on/off etc in one go.

The original point of the /48 was that nobody should have to bother
thinking about bits as there is enough space.

Clearly some ISPs see some scaling issues inside their network and thus
think that /56's solve that. Hence why ARIN at first then changed that
limit.

One routing slot though is still one routing slot, not more, thus if it
is a /56 or a /48 should not matter.

I am quite fine with a /56 for home users, it definitely works for me
and thus should for really everybody else in a home network.

But enterprises/companies should per default get a /48 per site so that
it is always the same and they can at least number-plan wise renumber
easily.

Hence the /64 link (autoconfig is great), /56 for enter home and /48 for
companies.

Greets,
 Jeroen

PS: one problem with the 'you get a /48' etc is that some ISPs steal the
first /64 for the uplink, some others do not. Hence why if one is doing
a network plan skip the first /64 as it will save some pain if you ever
switch. (Though it would just mean changing one VLAN to other bits).

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 09:49:18 +0100

On 2013-10-27 15:50, Roger Jørgensen wrote:
[..]
> argument to give up /64 because we have lost privacy anyhow.

I am NOT arguing that a /64 should go the way of the dodo.
I am only stating that this "IPv6 Privacy Address" thing is a myth.

> This /64 split is a good construction.

I fully agree, but IPv6 Privacy Addresses is not one of them.

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Oct 2013 17:50:26 +0900

> I am only stating that this "IPv6 Privacy Address" thing is a myth.

Can you do so on another thread, please? This thread is about /64.

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 09:55:26 +0100

On 2013-10-28 09:50, Lorenzo Colitti wrote:
> On Mon, Oct 28, 2013 at 5:49 PM, Jeroen Massar <[email-masked]

You do realize that YOU made that point right?

>From your message on 27 Oct 2013 17:55:00 +0900:
http://www.ietf.org/mail-archive/web/ipv6/current/msg19238.html

> size assignment that makes autoconfiguration easy, allows privacy,
> and gives users the capability to number multiple applications or
> multiple devices without having to use NAT.

As you wrote that, I noted that "allows privacy" is a myth.

You brought this point up, I argued against that single point (and
nothing else btw).

If you do not want to discuss it, then you should not have mentioned it
and you should not be arguing against it, simple.

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Oct 2013 17:57:18 +0900

> You do realize that YOU made that point right?

Yes, and I withdrew it. I withdraw it again. Please let's not talk about it
on this thread any more.

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 28 Oct 2013 09:53:59 +0100

Ok, thx for the update.
I don't think that you're the "default/avg" user here :-), hence I don't believe they will use your setup as an example to set for a specific ia_pd prefix length.
I agree there's plenty of space, but lots of ISPs claim people said the same in IPv4 era, hence are cautious to set it "too big".

Anyway, I must say to see lots of /56s, so looks ok in lots of occasion, but for sure no global consensus / approach on this, I see anything between 64 and /48 for the home being used today.

Regs
Carl
-----Original Message-----
From: Jeroen Massar [mailto:[email-masked]] 
Sent: maandag 28 oktober 2013 9:46
To: Wuyts Carl; Octavio Alvarez
Cc: <[email-masked]>
Subject: Re: Why /64

> Can you elaborate on why you would need more than 4 bits subnets @ home?

Because I am one of the examples where I have, at home, already have more than 16 VLANs at home.

But I might be special, I can only assume several other people here have similar large home networks. I have so many VLANs as I like things in separate networks, many do not even get Internet connectivity but they are globally addressable. Note that things go very quickly when you have things like IPv6 connected lightbulbs; though these are in a VLAN per room so that I can send a multicast message to that VLAN and turn them all on/off etc in one go.

The original point of the /48 was that nobody should have to bother thinking about bits as there is enough space.

Clearly some ISPs see some scaling issues inside their network and thus think that /56's solve that. Hence why ARIN at first then changed that limit.

One routing slot though is still one routing slot, not more, thus if it is a /56 or a /48 should not matter.

I am quite fine with a /56 for home users, it definitely works for me and thus should for really everybody else in a home network.

But enterprises/companies should per default get a /48 per site so that it is always the same and they can at least number-plan wise renumber easily.

Hence the /64 link (autoconfig is great), /56 for enter home and /48 for companies.

Greets,
 Jeroen

PS: one problem with the 'you get a /48' etc is that some ISPs steal the first /64 for the uplink, some others do not. Hence why if one is doing a network plan skip the first /64 as it will save some pain if you ever switch. (Though it would just mean changing one VLAN to other bits).

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 10:11:10 +0100

On 2013-10-28 09:53, Wuyts Carl wrote:
> Ok, thx for the update. I don't think that you're the "default/avg"
> user here :-), hence I don't believe they will use your setup as an
> example to set for a specific ia_pd prefix length. I agree there's
> plenty of space, but lots of ISPs claim people said the same in IPv4
> era, hence are cautious to set it "too big".

We can't teach people to learn math nor can we teach them to think of
routing slots and the fact that aggregation makes things so much easier.

We also cannot teach people who are in the networking business and who
request the prefix they get from their RIR to request a large enough
block, and then are 'we are running out of space' or funnier, make
comments about other ISPs getting large blocks as they did fill in the
paperwork. The allocation lists show clearly that several ISPs have
upgraded their prefixes to much larger sizes than the default /32 over
time though; thus hopefully this happens before there becomes a need to
do multiple disjunct /32s per ISP, though several have already gone for
that model to 'cover the world' or 'being able to deaggregate per
continent'.

Like in IPv4 there are also already several ISPs again who are limiting
the amount of time that a IPv6 delegation is routed to a single user,
and they cycle it on regular basis; hence the user not receiving a
static prefix and thus having to renumber all the time and thus it being
quite annoying.

These primarily are all business decisions though, little the IETF can
do about unfortunately. There is enough documentation out there, the
people in charge will go their own way without heeding the advice of
their fellow networkers...

> Anyway, I must say to see lots of /56s, so looks ok in lots of
> occasion, but for sure no global consensus / approach on this, I see
> anything between 64 and /48 for the home being used today.

In the ARIN region ISPs are supposed to do at minimum /56, as this is in
the allocation guidelines. Similar allocation guidelines exist for the
other RIRs.

Unfortunately there is no 'forced' requirement from the RIR and ISPs
thus end up picking whatever they deem good for them.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 10:11:50 +0100

On 2013-10-28 09:57, Lorenzo Colitti wrote:
> On Mon, Oct 28, 2013 at 5:55 PM, Jeroen Massar <[email-masked]
> Yes, and I withdrew it. I withdraw it again. Please let's not talk about
> it on this thread any more.

Can you please provide a link to the message in the archives where you
did? As I clearly did not see it.

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Oct 2013 18:22:22 +0900

> did? As I clearly did not see it.

http://www.ietf.org/mail-archive/web/ipv6/current/msg19246.html : "sure.
There are other ways to track people than via IP addresses."

If you want to continue that discussion, please do so on a separate thread.

---

From: Sander Steffann <[email-masked]>
Date: Mon, 28 Oct 2013 10:22:53 +0100

Hi Carl,

> Can you elaborate on why you would need more than 4 bits subnets @ home?

Today 4 bits can be enough for simple cases with i.e. a home network, a guest network and maybe a home-office network. But IPv6 is meant to last for some time, and in the (near) future it is not that difficult to see networks for lighting and sensors (i.e. 6lowPAN) being added to that. And I'm not being very creative right now ;-)  Besides: home users often don't understand the different between a wireless router and an access point, so they tend to daisy-chain them. In IPv4 this would cause multiple layers of NAT, in IPv6 you need more subnets.

PS: Look at DT's plans, they are giving multiple /56s to each home. One for best-effort internet access, one for voice, one for streaming audio/video, etc. See https://ripe67.ripe.net/presentations/131-ripe2-2.pdf. I'm not saying this is the way everybody should deploy IPv6, but it is an example of using IPv6 address space in a different way.

Cheers,
Sander

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 10:27:40 +0100

On 2013-10-28 10:22, Lorenzo Colitti wrote:
> On Mon, Oct 28, 2013 at 6:11 PM, Jeroen Massar <[email-masked]

Which shows that you totally missed the point with that statement, and
you surely did not 'withdrew' your point.

See my other messages: IPv6 Privacy addresses are a myth, they do not
work. You can track people even when you just see IP addresses and
ignore the upper layers. The upper layers just make it easier.

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Oct 2013 18:42:47 +0900

> ignore the upper layers. The upper layers just make it easier.

If you want to discuss this further, please take it to a separate thread.

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 28 Oct 2013 10:38:31 +0100

Hi Sander,

Don't worry, I agree upon your statements wrt size of prefix, and always recommend our customers a /56 (or bigger), and this is for residential CPE, so I'm not really talking about "home-office" networks.
Reality today however says that the majority of users today is using a single /64 which I believe makes the ISP think on the size of the ia_pd to be used, hence they might select something smaller, also to get more value in the future for using bigger ones (for more advanced users), so it's sort of a trade-off I believe.

Nevertheless, /64, the topic of these mails, on links should be kept imho, so not start tweaking them smaller just because some ISPs only handout some smaller ia_pd.  Arin guidelines seems to be in place for /56, should not be a bad idea to have this being used globally, but might not be that easy to enforce.

Regs
Carl

-----Original Message-----
From: Sander Steffann [mailto:[email-masked]] 
Sent: maandag 28 oktober 2013 10:23
To: Wuyts Carl
Cc: Jeroen Massar; Octavio Alvarez; <[email-masked]>
Subject: Re: Why /64

Hi Carl,

Cheers,
Sander

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 10:47:00 +0100

On 2013-10-28 10:42, Lorenzo Colitti wrote:
> On Mon, Oct 28, 2013 at 6:27 PM, Jeroen Massar <[email-masked]

As I quoted a few messages before you are the one who put it in this thread.

What you are asking is to just forget about it, as you clearly do not
want to accept my point though, I'll do just that, I've made my point
clear enough.

Greets,
 Jeroen

---

From: Sander Steffann <[email-masked]>
Date: Mon, 28 Oct 2013 10:57:12 +0100

Hi Carl,

> Don't worry, I agree upon your statements wrt size of prefix, and always recommend our customers a /56 (or bigger), and this is for residential CPE, so I'm not really talking about "home-office" ne…

Don't underestimate how many people work from home one or two days a week :-)

> Reality today however says that the majority of users today is using a single /64 which I believe makes the ISP think on the size of the ia_pd to be used, hence they might select something smaller,…

They can get as many IPv6 addresses as they need (even if giving each customer a /48) from the RIPE NCC, so the only reason to do this is to promote more expensive subscriptions. This saddens me, but I guess they will learn when users start complaining...

> Nevertheless, /64, the topic of these mails, on links should be kept imho, so not start tweaking them smaller just because some ISPs only handout some smaller ia_pd.  Arin guidelines seems to be in…

Ack!
Sander

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Oct 2013 11:33:31 +0100

> 1) Write an I-D that analyzes the problem, and proposes a workaround, and,

Thanks for the invitation.  Sounds like a good idea to write a problem 
statement about it.  I wouldn't put solutions in the same draft though.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Oct 2013 11:51:40 +0100

Le 27/10/2013 11:52, Ray Hunter a écrit :
>>> It was the driver for the change from RFC 1884's /80 (with a 48
>>> bit MAC in the IID) to RFC 2373's /64 (with an EUI-64). I would
>>> think that any argument today about the /64 would be about
>>> inertia if not the EUI-64.
>>>
>>
>> I think the split /64 extremely useful because it provides a
>> minimum size assignment that makes autoconfiguration easy, allows
>> privacy, and gives users the capability to number multiple
>> applications or multiple devices without having to use NAT.
>>
>> I have personally had more than one conversation with operators who
>> cannot see why they would ever want to give a user more than one
>> IPv6 address, because a) that's what they do in IPv4, and b) a /64
>> is a waste of space. Mobile operators seem particularly prone to
>> this line of reasoning. Telling them that there's plenty of space
>> to give every device a /64, or that their service is better if
>> users are allowed more than a /64 for privacy reasons, or that it
>> allows users to connect multiple devices, etc. has no effect.
>> Saying "it's specified in the standards and some implementations
>> might not work if you don't do it" has proven to be a much better
>> argument so far. Often those same operators then come to appreciate
>> the flexibility once they have deployed using /64 or larger and see
>> how it makes things better and easier.
>>
>> It's true that some operators can decide to use only DHCPv6 and
>> hand out /128s today, but since some platforms don't support
>> DHCPv6, that decision has compatibility consequences.
>>
>> If we ditch the one-size-fits all subnet size and leave the subnet
>> size up to the operator, it's virtually certain that we will end up
>> with some deployments that hand out /128s. That makes IPv4-style
>> NAT virtually inevitable, because users will want to connect more
>> than one device regardless of what the operator wants them to do.
>> Since apps have to adapt to the lowest-common denominator
>> connection, there's a good chance that apps will have to keep
>> IPv4-style NAT traversal mechanisms around forever. I think that's
>> a fundamentally bad deal, because there's no real reason to employ
>> address sharing if you have enough addresses; the side-effects of
>> NAT that people seem to like (e.g., security) come from stateful
>> inpection, not from the translation itself.
>>
>> On the other hand, if we do keep a one-size-fits-all subnet size,
>> then I think /64 is the best choice, not just for backwards
>> compatibility reasons, but for lots of other reasons such as
>> because it splits the address in two halves that are natural
>> machine integer sizes, provides enough space to protect against the
>> birthday paradox, and so on.
>>
>> Cheers, Lorenzo
>>
> would be a bad thing because operators will use this as an
> opportunity to limit their customers to a single IPv6 address, and
> yet simultaneously you seem to be arguing that maintaing a fixed /64
> is a good thing even though it limits customers to a single subnet.
>

The IPv4's CIDR concept (route based on bitwise borders, instead of
8byte) seems to me a good clue for the discussion about the fix 64bit
limit in IPv6.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Oct 2013 11:53:51 +0100

> So.. what do ou do in that case... IPv6 NAT?

There is also this NPT... and I wonder whether it has this 64bit limit 
or not.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Oct 2013 12:00:56 +0100

> Then why deprecate EUI-64?

I think there is a problem in naming that draft.

I think the intention of it is not to deprecate EUI-64 altogether.  If 
I'm not wrong EUI-64 is an IEEE concept that IETF reuses, and thus 6man 
wouldn't have the prerogatives to 'deprecate EUI-64'.

Second, reading through that draft it seemed to me it intended to 
deprecate the use of a hardware address as input into an IP address 
formation mechanism.

I think the draft _would_ allow to devise an IP address generation 
mechanism using an EUI-64 formed from something else which is not a 
hardware address.

But this is the other thread.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Oct 2013 12:13:33 +0100

Le 28/10/2013 09:35, Jeroen Massar a écrit :
>>> on privacy.  Privacy through controlling tracking of an IP
>>> address is very different in mechanism and result from higher
>>> layer end-to-end privacy.
>>
>>
> You can +1 without facts or any backing details, but the fun thing
> is, it is no difference at all: privacy addresses do not make you
> "private" in any way or form.

I tend to agree.

On one hand, privacy extensions to SLAAC is one little step towards
having just a little more privacy possible, as opposed to not using
privacy extensions.

But there are many aspects than just the IP address, visible in even the
simplest wireshark dump which when correlated reveal a surprising number
of things some may consider deeply private.

Even the time correlation of presence/absence of traffic can be a guide
about someone's habits. It can become as insane as thinking that only 
turning everything off forever could offer some privacy.  An hypothesis 
contradictory to the very essence of communication.

Alex

>
>
> The only thing higher levels gives the adversary is a easier
> detection and correlation. But unless you have exactly the same
> packet signature and you are hitting the same sites as other people
> in your /64 or /48 you are unique.
>
> Please note that a IPv6 Privacy Address is for a period of time, not
> per application (at least I have not seen an OS do that yet, it
> could, but they do not).
>
> identified as you; then anything else goes to another site, and
> voila, they know that that connection is also related to you. Then
> your privacy time window expires, you connect to that second site
> again, which is not HTTP, but as you have been there just a bit ago,
> there is a high chance that that is still you.
>
>> It does not matter if you have 1 IPv4 address with 2000 people
>> behind it, or 1 /48 with 2000 people behind it.
>>
>> The algorithms to de-anonimize and differentiate between the real
>> hosts behind them exist.
>>
>>  differences in the client, be that the tcp stack level another.
>> For other protocols it is all much easier as they are typically
>> already authenticated anyway or have other bits.
>>
>>
>>
>> Having said that, FWIW - I partially disagree with Jeron here - it
>> does matter.
>
>> A user can have browser extensions, multiple browsers (or mutliple
>> VMs with different OSes) and have a fairly good level of privacy
>> if so desires - as long as the underlying L3 provisioned does not
>> prevent it.  Is may not be exactly mainstream / commonplace, but
>> not uncommon enough to ignore (IMHO) either.
>
> Even though that would give you separate addresses and would
> initially give that user separate identities that are being tracked,
> that user is still coming out of the same /64 or /48.
>
> Thus on the IP level indeed it initially looks like multiple users.
> But as various organizations are pretty good at estimating amount of
> users in a location, they can easily guess that it is the same
> person anyway.
>
>
> I'll state again: if you want privacy use a mixnet, eg Tor. (and
> even then you are exposing all your random bits, thus beware what
> Greets, Jeroen
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Oct 2013 12:18:27 +0100

Le 28/10/2013 10:22, Sander Steffann a écrit :
>> but "at least" a /56 for home (with /60 too tiny) ?? Can you
>> elaborate on why you would need more than 4 bits subnets @ home?
>
> Today 4 bits can be enough for simple cases with i.e. a home
> network, a guest network and maybe a home-office network. But IPv6 is
> meant to last for some time, and in the (near) future it is not that
> difficult to see networks for lighting and sensors (i.e. 6lowPAN)
> being added to that.

I agree.

And I would add another aspect.  One could hardly imagine that a single
subnet (any subnet) could hold together 2^64 nodes.  That is a matter of
link-layer technology.  I think not even the largest single subnet
switch/vlan-based office networks or datacenter would approach that number.

(a single IEEE subnet is one where link-scope link-layer multicast works
across, and IP datagrams are not decremented their Hop Limit when
transmitted through).

Alex

> And I'm not being very creative right now ;-)  Besides: home users
> often don't understand the different between a wireless router and an
> access point, so they tend to daisy-chain them. In IPv4 this would
> cause multiple layers of NAT, in IPv6 you need more subnets.
>
> PS: Look at DT's plans, they are giving multiple /56s to each home.
> One for best-effort internet access, one for voice, one for
> streaming audio/video, etc. See
> https://ripe67.ripe.net/presentations/131-ripe2-2.pdf. I'm not
> saying this is the way everybody should deploy IPv6, but it is an
> example of using IPv6 address space in a different way.
>
> Cheers, Sander
>

---

From: Octavio Alvarez <[email-masked]>
Date: Mon, 28 Oct 2013 09:32:35 -0700

> I think there is a problem in naming that draft.

I meant "why deprecate EUI-64 as device-ID in IPv6 addresses". Sorry if
this starts a misconception.

---

From: Octavio Alvarez <[email-masked]>
Date: Mon, 28 Oct 2013 09:47:19 -0700

> I am only stating that this "IPv6 Privacy Address" thing is a myth.

Which is also inaccurate, as the purpose is not to provide privacy, but
just to prevent anti-privacy through the IPv6 address.

It's difficult to choose the right words for this.

---

From: Octavio Alvarez <[email-masked]>
Date: Mon, 28 Oct 2013 09:56:21 -0700

> 8byte) seems to me a good clue for the discussion about the fix 64bit

CIDR is already being used. /80s, /96s and other arbitrary netmasks can
be set on some devices and should work. Some of them may misbehave, though.

But still, there is nothing to fix. The /64 limit is not a problem and
will not be.

Also, RFC 4941 (and some others) depend on /64 networks.

Cheers.

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Oct 2013 18:05:33 +0100

> just to prevent anti-privacy through the IPv6 address.

Please explain this "anti-privacy" concept.

> It's difficult to choose the right words for this.

You mean that it is difficult to justify randomizing bits as it does not
solve the problem at hand: you can and will be tracked.

>From the intro of RFC4941:
----
   Changing the interface
   identifier (and the global scope addresses generated from it) over
   time makes it more difficult for eavesdroppers and other information
   collectors to identify when different addresses used in different
   transactions actually correspond to the same node."
----

As it states 'more difficult'. Since 2001 (RFC3041 which has the same
wording and intent) this kind of tracking tech and the compute power has
advanced enough though that the difficulty is futile.

Greets,
 Jeroen

---

From: [email-masked]
Date: Mon, 28 Oct 2013 18:45:53 +0100 (CET)

> be set on some devices and should work. Some of them may misbehave, though.

"Some devices"? They work on all devices I've tried. And I certainly
*expect* normal longest prefix match based forwarding to work, with
no arbitrary /64 limitation. 

The only limitations I've seen are IPv6 ACLs on some Cisco switches,
where the 144 bit wide CAM cannot accomodate a 128 bit IPv6 address
*and* 2 x 16 bit port numbers.

Steinar Haug, AS 2116

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 28 Oct 2013 12:23:38 -0700 (PDT)

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Sent: Tuesday, 29 October 2013 4:45 AM
> Subject: Re: Why /64
> 

I'd expect it to work too.

I think the difference between IPv6 and other protocols in this area is that while it has a longest match rule across the whole address, there are "soft" rather than hard field boundaries in a portion of the address space because they're much easier to deal with operationally, and easier to develop systems to deal with. The longest match rule is there to ensure that if the soft field boundaries end up being incorrect, different soft boundaries can be defined in a different portion of the address space, it won't require router upgrades to fix as the move from Classful IPv4 to CIDR did.

People like flexibility, but don't seem to think much about the costs it may incur. Flexibility and options creates opportunity for error. It's hard to get prefix length wrong when all subnets are /64s and when all of your customers have /48s. If your customers have a mix of /56s and /48s, you now have to manage your space more carefully, costing you time and effort, and over time a few customers may get given the wrong prefix size for their needs, with the costs of dealing with those error may exceed any savings there were in trying to "right size" allocations. Simplicity is usually cheaper and more robust.

---

From: Octavio Alvarez <[email-masked]>
Date: Mon, 28 Oct 2013 12:41:04 -0700

> Please explain this "anti-privacy" concept.

Made up word, as in "explicitly not privacy". It's not the same "this 
address will not make it as easy for a tracker to track me at least in 
some applications but it is possible if you try hard enough and it will 
cost some more resources to the tracker" than "here you go, it's me and 
you even know what brand of NIC I'm using".

Also, Web != Internet.

> advanced enough though that the difficulty is futile.

Under that logic, punching a hole on my house roof with a drill is just 
more difficult than opening a door, and given a drill is easy to buy and 
not so expensive for people that want, let's all leave our doors 
unlocked and open.

I *also think*, however, that changing address without restarting all 
connections just nullifies the effect of any changing-address privacy 
extension.

I'm not a pro-removing-EUI-64-device-IDs, I'm just saying that 
randomizing bits does something helpful.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 28 Oct 2013 22:28:18 +0100

> It's difficult to choose the right words for this.

I think you are quite right on that one. Privacy isn't really PRIVACY,
it's more about trying not to reveal Everything there is about whoever
is using whatever IP, however that IP is "created". Call it EUI-64,
"IPv6 privacy" or whatever.
None of them really provide 100% privacy, they are all just a bit
better than none, even EUI-64 has some... Which is the point isn't it?

--

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 28 Oct 2013 15:39:59 -0700

Hi Hosnieh,

Assuming this is the relevant text from your draft, I will try to give my interpretation of it and how it differs from the recommendations in draft-gont:

"Step 3 in Section 3.3 of RFC 4941MUST be ignored. When a node uses
   the mechanism explained in this document to generate an IID, it MUST
   not use any other IID generation approaches that are based on MAC
   addresses (RFC 4862) for either temporary or non temporary IID
   generation. The node MIGHT use the algorithm explained in
   [StableAddresses] for the generation of a public address that does
   not make use of EUI-64 or the MAC address for public (global)
   addresses."

1. The implication of the first sentence is that a node that creates a public address as described in 4862 MUST NOT create a temporary address as specified in 4941.

2. There is no recommendation as to whether or when to use the mechanism you specify in ra-privacy, but the second sentence says that when a node uses that mechanism, it MUST NOT (assuming you meant for the "not" to have 2119 meaning) use any IID-generation mechanism based on a MAC address.

3. The third sentence is editorial because MIGHT is not a 2119 keyword.

The combination of the three statements above is rather different from the recommendations made in draft-gont-6man-deprecate-eui64-based-addresses. In draft-gont, we say:

  "Nodes MUST NOT employ IPv6 address generation schemes that embed the
   underlying hardware address in the Interface Identifier.  Namely,
   nodes MUST NOT generate Interface Identifiers with the schemes
   specified in [RFC2464], [RFC2467], and [RFC2470].

   Nodes SHOULD implement and employ
   [I-D.ietf-6man-stable-privacy-addresses] as the default scheme for
   generating stable IPv6 addresses with SLAAC."

Thus we do not speak to temporary addresses, we deprecate the use of hardware identifiers in IIDs, and we recommend the use of the mechanism of stable-privacy-addresses when a stable address is needed. Of course there has been some discussion about whether these normative recommendations are the right ones and whether making them is worthwhile and that discussion should continue, but in any event the two drafts' recommendations appear to be rather different.

I am also bought in to the idea that if some recommendation is to be made about use of hardware identifiers in IIDs, it should be in a simple stand-alone draft.

Hope this helps,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 28 Oct 2013 15:40:15 -0700

> "IPv6 privacy" or whatever.

It does seem like the discussion over on that other thread devolved because of semantics a bit. This is part of the reason why we use terminology very carefully in draft-ietf-6man-ipv6-address-generation-privacy to discuss the threats against different mechanisms for IID generation, and even to name the mechanisms themselves. It's unfortunate that RFC 4941 is called "privacy extensions" and that folks call the associated addresses "privacy addresses"; in the above-referenced draft we call them "temporary addresses" for a reason -- they are temporary. No claims that they provide 100% anonymity at all times are thereby attached.

If this discussion continues, it might help if folks referenced the specific properties vis a vis correlation and tracking that a particular IID generation mechanism provides, rather than focusing on "privacy" as some sort of binary state that a user either has or doesn't have.

Alissa

---

From: Fernando Gont <[email-masked]>
Date: Mon, 28 Oct 2013 18:58:56 -0400

Hosnieh,

> draft.  Are you going to merge my draft with yours? 

To be quite honest, I'm not sure what you mean. But before juping to the
specifics of this I-D we've published, let me clarify some bits about
this topic:

1) I authored draft-gont-6man-stable-privacy-addresses in 2011. At the
time, that I-D was meant to deprecate Modified EUI-64 IIDs. During the
process of wg adoption, it was seen as a better approach to have this
I-D just propose the algorithm, rather than have it deprecate EUI-64...
hence the deprecation was eventually removed.

2) In a similar way, draft-ietf-6man-stable-privacy-addresses used to
contain a threat assessment -- notably improved in response to Alissa's
feedback (during WGLC or IETF LC, IIRC). Eventually, this threat
assessment was removed (since, among other things, it was a whole topic
by itself).

"2)" later resulted in a stand-alone document... and, more recently, so
did "1)".

draft-gont-6man-deprecate-eui64-based-addresses-00.txt borrows text from
stable-privacy and from Alissa's I-D -- that's how Will and me produced
the initial -00 version, which was later discussed and edited with the
other co-authors before publication.

Now, if asked about the specifics (and having just taken a look at your
document), -- and assuming this is the part you're referring to -- your
document says:

>    Step 3 in Section 3.3 of RFC 4941 MUST be ignored. When a node uses
>    addresses ( RFC 4862) for either temporary or non temporary IID
>    generation.

This text does not deprecate Modified EUI-64. It rather provides an
optional alternative to generating IIDs.

Besides, Section 3 of
<http://tools.ietf.org/html/draft-gont-6man-stable-privacy-addresses-00>
(dated December *2011*) contains this text:

  > IPv6 implementations conforming to this specification MUST generate
  > interface identifiers with the algorithm specified in this section.
  > The aforementioned algorithm MUST be employed for generating the
  > interface identifiers for all the IPv6 addresses configured with
  > SLAAC for a given interface, including IPv6 link-local addresses.

.. which pretty much reads like the text in your I-D ("MUST NOT use
EUI-64 *when this algorithm is employed*")...

So I'm rather curious about your suggestion of "plagiarism" on our side,
I should say.

>    The node MIGHT use the algorithm explained in
>    addresses.

FWIW, our document recommends draft-ietf-6man-stable-privacy-addresses,
rather than listing it as one possible option.

Thanks,

---

From: Hosnieh <[email-masked]>
Date: Tue, 29 Oct 2013 03:53:40 -0400 (EDT)

Fernando,

> So I'm rather curious about your suggestion of "plagiarism" on our side,

That section of the draft in ra-privacy also says not to use EUI-64 as both
temporary and public addresses. This section is not new and you can find it in
early versions of ra-privacy as well because it was one of the problem of RFC
4941. Your draft expands this section and make it more general to deprecate
EUI-64.

What I can remember during and after IETF 87, there was also offlist discussion
about this and I said, since this part is in this draft and already explained, I
suggest to keep it as it is and nobody said otherwise. You were also includede
in that discussion.

So, when you planned to have that section out of this draft and make it more
general, at least you could mention it and discuss about this or refer to this
draft.

Hosnieh

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 29 Oct 2013 10:42:52 +0100

On 2013-10-28 18:14 , Peter Dordal wrote:
> On 10/28/2013 04:27 AM, Jeroen Massar wrote:
> In what sense exactly is this claim meant?I agree that "privacy"
> addresses are in many scenarios not all that private,
> but I am not sure that makes them useless.
> 
> 1. Suppose I connect both at work and home; each site has
> a different /64 prefix. I do not want anyone to correlate my work
> and home traffic.

For different sites, not using the MAC-derived EUI-64 is indeed a great
thing. But you could just as well use DHCPv6 or just pick random number
like ::5 and use that insted.

The actual IPv6 Privacy address, including the randomization and
expiration does not add much there in avoiding tracking.

Note that a lot of folks have IM clients (using specific jabber
servicers), mail clients (using specific smtp/imap/pop3 servers)
configured. Thus if there are only a few users on the destination
server, it is easy enough to designate all that randomly picked source
still as the same person based on that.

(If you want to hide on the IP level, use mixnet...)

> Assume I am either not using http, or I erase
> cookies frequently; higher layers are not exposing me in any
> "obvious" way.

Actually, erasing your cookies makes you obvious as there are very few
people who do not have cookies as you get them all the time.

Hence why some people where 'exchanging' cookies at one point (can't
seem to quickly find the site that had the plugins etc to do so).

But seems Christian wrote a article about that earlier this year:

http://huitema.wordpress.com/2013/03/17/lets-build-a-cookie-exchange/

> If I use SLAAC at both sites, using the same EUI-64 identifier
> as my low-order bits, then this gives me away.

Definitely. And that can be considered a good thing (logging, ACLs) and
a bad thing: makes tracking really easy.

> How else can I avoid this besides using privacy addresses?

As above, configure something like ::2 or use other such numbers.

> 2. Suppose I connect to two different remote sites, A and B,
> while at work. I don't want someone reviewing the logs at A and B
> to know the same host made both these connections.
> 
> There are thousands of others at my same workplace using the
> same /64 prefix; an outside observer will not be able to infer
> that the same person connected to A and B from the prefix alone.

But they can make a pretty good guess. There will be a lot of meta data
in those connections, much of it that will make you unique.

Try this for the fun of it:
 - keep your cookies that you have
 - google for something common "how do you..."
   and see how autocomplete answers (that is, if you still have that
enabled). or if you do not (smart! but also makes you unique again)
   just hit the search button and see which answers you get

now clear those cookies and change that IPv6 address of yours to
something else random and try again. Gee, you say, same results!?

Now ask a colleague to repeat the same thing on a different host and
he/she will be getting different results. Gee, why? There is more meta
information than that...

And HTTP is not the only way to detect things, every protocol has meta
data. It just depends on how much the adversary wants to know who you
are and how much they can collect.

> I want to choose different IPv6 addresses at my end
> for each of these connections, differing of course only in the
> low-order bits. Again I use SLAAC. How do I create
> the second IPv6 address except by using privacy addresses?

The privacy extensions are not per-application and neither
per-connection. They are time-based instead and thus if you make
connections during a certain bucket of time they all are coming at the
same time.

They would be much better already if they did do per-app, per-connect.

But still you would just be thrown into a bit-bucket of 'that /64
contains users X Y Z" and thus based on other properties than IP you
would still be seen as identity X.

Greets,
 Jeroen

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 29 Oct 2013 11:06:06 +0100

Le 28/10/2013 17:32, Octavio Alvarez a écrit :
>>>> IMHO big nonsense. The company (amongst many others!) you work
>>>> for uses amongst others cookies to track their people, and if
>>>> they really bother could even use natural language structure,
>>>> search query types, and other behavior for breaking this
>>>> 'privacy'. Also note that even if the last 64bits are random,
>>>> your company should be more than able to say "oh, there are
>>>> typically X users in there, it likely is Y"...
>>>
> I meant "why deprecate EUI-64 as device-ID in IPv6 addresses".

Ok, but even then there might be an issue.

It is a 'Modified EUI-64', not an 'EUI-64'.

It is an Interface ID, not a device-id.

But I can understand you correctly ok, no problem :-)

This leads to me thinking that what they'd like to deprecate is this
phrase from RFC2464:
> The Interface Identifier [AARCH] for an Ethernet interface is based
> on the EUI-64 identifier [EUI64] derived from the interface's built-
> in 48-bit IEEE 802 address.  The EUI-64 is formed as follows.
> (Canonical bit order is assumed throughout.)

And I still have a problem with it, because it is not IETF who requires
the EUI-64 to be formed from the hardware address, but it is IEEE who
requires that.  IETF only requires the 'Modified EUI-64' to modify the
EUI-64 e.g. by inverting the u/g bits.

What IETF could deprecate is this other phrase from RFC2464:
> The Interface Identifier is then formed from the EUI-64 by
> complementing the "Universal/Local" (U/L) bit, which is the next-to-
> lowest order bit of the first octet of the EUI-64.

It should say this:
> The Interface Identifier MAY be formed from the EUI-64; if so, then
> it MAY be complementing the "Universal/Local" (U/L) bit, which is the
> next-to- lowest order bit of the first octet of the EUI-64.

Moreover, RFC4291 says this:
> For all unicast addresses, except those that start with the binary
> value 000, Interface IDs are required to be 64 bits long and to be
> constructed in Modified EUI-64 format.

This gives an opportunity to people to form IPv6 address starting with
000 and without necessarily using Modified EUI-64, thus not necessarily
using EUI-64, and thus not necessarily using hardware addresses, and
thus not necessarily using 64-bit Interface Identifiers, and hence maybe
longer than 64 prefix lengths.

Otherwise, the RFC4291 spec _could_ say this:
> For all unicast addresses, except those that start with the binary
> value 000, Interface IDs are required to be 64 bits long and MAY be
> constructed in Modified EUI-64 format.

or it could say this:
> For all unicast addresses, except those that start with the binary
> value 000, Interface IDs MAY be formed using the 'Modified EUI-64'
> format, in which case their length is 64 bits.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 29 Oct 2013 11:19:44 +0100

Le 28/10/2013 20:23, Mark ZZZ Smith a écrit :
>> From: "[email-masked]" <[email-masked]> To:
>> [email-masked] Cc: [email-masked];
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked] Sent: Tuesday, 29 October
>> 2013 4:45 AM Subject: Re: Why /64
>>
>>>> The IPv4's CIDR concept (route based on bitwise borders,
>>>> instead
>> of
>>>> 8byte) seems to me a good clue for the discussion about the fix
>>>> 64bit limit in IPv6.
>>>
>>> CIDR is already being used. /80s, /96s and other arbitrary
>>> netmasks can be set on some devices and should work. Some of them
>>> may misbehave, though.
>>
>> "Some devices"? They work on all devices I've tried. And I
>> certainly *expect* normal longest prefix match based forwarding to
>> work, with no arbitrary /64 limitation.
>>
>

Yes, I expect routing to work on larger-than-64 and bitwise boundaries.

But is also a matter of the subnet mask of the smallest possible subnet. 
  Can one have an IPv6 subnet comprising only 4 entities, on 
Ethernet-compatible, and using Stateless Address Auto-Configuration?

> I think the difference between IPv6 and other protocols in this area
> is that while it has a longest match rule across the whole address,
> there are "soft" rather than hard field boundaries in a portion of
> the address space because they're much easier to deal with
> operationally, and easier to develop systems to deal with. The
> longest match rule is there to ensure that if the soft field
> boundaries end up being incorrect, different soft boundaries can be
> defined in a different portion of the address space, it won't require
> router upgrades to fix as the move from Classful IPv4 to CIDR did.
>
> People like flexibility, but don't seem to think much about the costs
> it may incur. Flexibility and options creates opportunity for error.
> It's hard to get prefix length wrong when all subnets are /64s and
> when all of your customers have /48s. If your customers have a mix of
> /56s and /48s, you now have to manage your space more carefully,
> costing you time and effort, and over time a few customers may get
> given the wrong prefix size for their needs, with the costs of
> dealing with those error may exceed any savings there were in trying
> to "right size" allocations. Simplicity is usually cheaper and more
> robust.

Yes and no.

YEs in that flexibility with fixed borders is indeed easier to grasp 
conceptually and easier to write configuration files for them, 
especially when addresses are a huge 128bit long.  A few rules of thumb 
and checking the validity can be done visually, no need of complex 
formal checkers.

No, in that we can still have flexibility, just that it is finer grain.

RFC1878 "Variable Length Subnet Table For IPv4" adviced for this by 
detailing tables of subnet masks, their effective subnets and effective 
number of Hosts.  At a time when the typical edge network subnet length 
was 8bit (today's typical 64bit Interface ID) this was a step forward 
for better detailing and subnetting space.

And yes, it may be that today 64bit is large enough and we dont have 
that IPv4 subnetting problem.

Alex

>
>> The only limitations I've seen are IPv6 ACLs on some Cisco
>> switches, where the 144 bit wide CAM cannot accomodate a 128 bit
>> IPv6 address *and* 2 x 16 bit port numbers.
>>
>> Steinar Haug, AS 2116
>>
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 29 Oct 2013 10:22:02 +0000

I agree with Alex!
Why not a new draft as a problem statement to explore and sum up all
relevant issues  ?

*Best wishes*
*nabilbenamar.com*

*
--------------------------------------------------------------------------------
*

On Mon, Oct 28, 2013 at 10:33 AM, Alexandru Petrescu <
[email-masked]> wrote:

> ------------------------------**------------------------------**--------
> Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
> ------------------------------**------------------------------**--------
>

---

From: Peter Dordal <[email-masked]>
Date: Mon, 28 Oct 2013 12:14:39 -0500

1. Suppose I connect both at work and home; each site has
a different /64 prefix. I do not want anyone to correlate my work
and home traffic. Assume I am either not using http, or I erase
cookies frequently; higher layers are not exposing me in any
"obvious" way.

Peter Dordal
Loyola University Chicago

---

From: Fernando Gont <[email-masked]>
Date: Tue, 29 Oct 2013 12:28:28 -0400

On 10/29/2013 03:53 AM, Hosnieh wrote:
> That section of the draft in ra-privacy also says not to use EUI-64 as
> both temporary and public addresses. This section is not new and you can
> find it in early versions of ra-privacy as well because it was one of
> the problem of RFC 4941. 

Please re-read my earlier response: I authored an I-D that said that in
December 2011.

> Your draft expands this section and make it
> more general to deprecate EUI-64.

It's not "more general". There's a difference between a proposal that
provides an option, and a document that is meant to replace one thing
with another.

draft-ietf-6man-stable-privacy-addresses was originally meant to replace
Modified EUI-64. Then that document was change such that the mechanism
was specified as an option, without replacing the existing algorithms.

Your I-D ra-privacy means to do something similar to what stable-privacy
is doing: provide an alternative algorithm for generating IIDs.

draft-gont-6man-deprecate-eui64-based-addresses-00 does a different
thing: it recommends to replace the existing recommended algorithm
(Modifed EUI-64) with another (stable-privacy).

Suggesting that your document was plagiarized is, at best, inappropriate.

> What I can remember during and after IETF 87, there was also offlist
> discussion about this and I said, since this part is in this draft and
> already explained, I suggest to keep it as it is and nobody said
> otherwise. You were also includede in that discussion.

1) What your document says is different from what our says (please see
my explanation above)

2) Your document is, IMO, mixing different and unrelated issues -- I
don't think it could be progressed as such.

3) I don't understand how being listed in a recipient's list represents
some sort of agrement -- but this is a side comment. And while digging
into mail achives, it seems that your description of such mail exchange
is misleading.

> So, when you planned to have that section out of this draft and make it
> more general, at least you could mention it and discuss about this or
> refer to this draft.

Once again: please see my explanation above. Namely:

1) Your document provides an optional way to represent IIDs (in this
respect, stable-privacy has been doing this way before.. but the same
applies to CGAs and others)

2) draft-ietf-6man-stable-privacy-addresses did both options (firstly
trying to replace Modified EUI-64, and later (as does the current
version) simply providing an alternative algorithm to do so).
draft-ietf-6man-stable-privacy-addresses predates was published way
before your I-D.

P.S.: I would have preferred to explain this off-list. But since your
post was on-list, and I was asked to clarify this issue, that's why
ended up posting this an my previous note on-list.

Thanks,

---

From: Octavio Alvarez <[email-masked]>
Date: Tue, 29 Oct 2013 10:32:20 -0700

> something else random and try again. Gee, you say, same results!?

That has nothing to do with the issue at hand.

Whatever changes are done in IPv6 can not protect a user if the user
likes using an application designed to track him. The "problem" may not
lie on the application itself, but it certainly doesn't lie on IPv6
either (read: HTTP cokies...)

Writing a higher-layer protocol or application that tracks you is not
the fault of IPv6. It's like blaming Ethernet for allowing a site in
Australia to reach Europe given Ethernet was only designed for local
area networks.

The issue at hand is: what does IPv6 directly does to leak information
about the local machine? Is this a problem? If it is (at all) is it
possible to fix and how?

---

From: Scott Brim <[email-masked]>
Date: Tue, 29 Oct 2013 13:38:36 -0400

> about the local machine? Is this a problem? If it is (at all) is it

Right, and: Avoid designing the fundamental protocols of the Internet such
that privacy is impossible, even if they fix the non-fundamental parts.

---

From: Octavio Alvarez <[email-masked]>
Date: Tue, 29 Oct 2013 10:43:04 -0700

> Ethernet-compatible, and using Stateless Address Auto-Configuration?

Why would you want to do that? ISPs could use this to give homes just 1
address, breaking innovation again and again, because of whatever lame
excuse, from misinformation to greed.

Public IP addresses, even if firewalled are useful to end devices.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 29 Oct 2013 13:08:08 -0700 (PDT)

----- Original Message -----
> From: Alexandru Petrescu <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Tuesday, 29 October 2013 9:19 PM
> Subject: Re: Why /64
> 

Certainly. Use a /64. What is the problem with that?

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Oct 2013 10:35:02 +1300

On 29/10/2013 23:06, Alexandru Petrescu wrote:
..
>> format, in which case their length is 64 bits.

These are exactly the words we have already changed, via the approval
of  draft-ietf-6man-ug. As soon as that draft exits the RFC Editor queue,
they will read:

   "For all unicast addresses, except those that start with the binary
    value 000, Interface IDs are required to be 64 bits long. If derived
    from an IEEE MAC-layer address, they must be constructed in Modified
    EUI-64 format."

This thread is about changing the first sentence, which I think you will
find is a contentious proposal with many pros and cons.

   Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 29 Oct 2013 21:54:06 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian
> E Carpenter

> find is a contentious proposal with many pros and cons.

May I wax philosophic for a second?

I too object to the term "required." And I believe in more or less Darwinian survival of the fittest too.

CIDR evolved for a reason: the old 32-bit classful scheme became inadequate when the Internet moved from an academic/military net of a few 10s of thousands, to something for the masses.

CIDR will re-evolve in IPv6, when the Internet evolves from something for the masses to something for the masses of even tiny things.

The idea that any subset of IPv6 addresses MUST have 64 IIDs, let alone the majority subset, is sure not to survive the test of time, in my opinion. Not when you dramatically change the paradigm of what gets connected. Lucky for everyone, we do know how to apply CIDR ubiquitously. I hope we don't design ourselves out of that possibility.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Tue, 29 Oct 2013 22:31:13 -0400

> wouldn't have the prerogatives to 'deprecate EUI-64'.

Whaat we mean to deprecate is *Modified EUI-64 IIDs -- that is,
Interface identifiers based on the underlying hardware address.

> mechanism using an EUI-64 formed from something else which is not a

Our I-D recommends draft-ietf-6man-stable-privacy-addresses.

Thanks,

---

From: Peter Dordal <[email-masked]>
Date: Tue, 29 Oct 2013 14:56:56 -0500

> like ::5 and use that insted.
I can't use ::5 because my office mate might also like 5.
Perhaps the issue though is that we should call them "random" addresses
rather than "privacy" addresses?

As for DHCPv6, the (one) advantage of SLAAC is that it lets me pick my own
low-order address bits.

> JM: The actual IPv6 Privacy address, including the randomization and
> ....
And if I am going to use tor from the office, I might want to be
particularly sure that I don't use the same IP address I use for my
everyday work.

Ok, privacy addresses are more like window curtains than Faraday cages.
But they still protect against some correlations. (In this they are not
unlike so-called "private browsing")
>
> pld: 2. Suppose I connect to two different remote sites, A and B,
> > JM: But they can make a pretty good guess. There will be a lot of meta data
This depends very much on the protocol. Http is not a good example here;
http has scary tons of metadata.

I can easily envision situations where identity "guesses" would be 
pretty flimsy,
**at least if the attacker had access only to the remote endpoint**.
> JM: Try this for the fun of it:
For the record, I got the *same* result on every machine:
How do you take a screenshot on a mac
            get rid of bedbugs
            divide fractions
            get bed bugs

(Some of these may be local to Chicago. Now I am worried about bedbugs.)

> JM: And HTTP is not the only way to detect things, every protocol has meta
> data.
Client-side smtp? ssh? More to the point, people who are more concerned 
about
privacy may pay more attention to these things than I do, and choose "safer"
protocols.
>> pld: I want to choose different IPv6 addresses at my end
> JM: The privacy extensions are not per-application and neither
I don't believe this is a "MUST", though I agree that concurrent use of
multiple IPv6 addresses is not quite in the spirit of rfc4941.

I'm back to my earlier point: privacy addresses are like private browsing:
imperfect, possibly even to the point of being misleading, but worth having.
I've been watching your [that is, Jeroen Massar's] _How the Internet 
Sees You_
presentation, but I am not (yet) convinced that privacy addresses
have no value in any circumstances.

Peter Dordal

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 30 Oct 2013 09:49:29 +0100

[merging multiple emails in one thread, thus a nice long one;
 TLDR: IP does not make you private in any way]

On 2013-10-28 20:41, Octavio Alvarez wrote:
[..]
> some applications but it is possible if you try hard enough and it
> will cost some more resources to the tracker" than "here you go, it's
> me and you even know what brand of NIC I'm using".

If you do not want to expose that randomize the bits a bit. Microsoft
does this for the various Windows implementations exactly for this reason.

> Also, Web != Internet.

I am only using HTTP as an example as it is one of many easy ways to get
extra details.

Note that even if you do not want to use HTTP various "automatic update"
tools will do it for you (the Internet is HTTP after all), and generate
an even bigger signature as it effectively shows which tools you have on
your machine that are able to do these updates.

One only has to look at the SrcIP<->DstIP combo to see who you are
contacting, the lowest port used (if any and if you have it) indicates
the server thus you can automatically learn these, use reverse/asn/whois
lookup to figure out who it is, and keep on correlating with other
connections. If you don't have a port then that is just a bit less info,
just keep a count of 'occurrences' on each side and you can figure out
that a user has less connections than a server. (statistically at least)

Even if your SrcIP changes, you will at one point connect to DstIP again
(or something in that /48) as the update tool wants more updates. If you
are the only Jitsi user, the only one without Adobe updates, etc,
gotcha, you are special...

And no, the population size does not matter, you are special. If you
like it or not: On the Internet you are a very unique snowflake.

[..]
> Under that logic, punching a hole on my house roof with a drill is
> just more difficult than opening a door, and given a drill is easy to
> buy and not so expensive for people that want, let's all leave our
> doors unlocked and open.

If your house is from the 1800s and still build of wood, then yes, if
you did not bother to upgrade your security and go along with the times
you will be vulnerable.

Instead of your 'leave all doors unlocked', you can realize that that
wooden roof is the bad part thus acknowledge that problem, be aware of
it and stop spreading the myth that a wooden roof is any good.

But that is where your analogy stops, as in the 21st century we would
just make a stone/concrete/multilayered roof and such a roofing problem
would be resolved. (And hopefully you put proper locks on doors, close
the windows etc etc etc)

The multilayered roof though might be relevant in this analogy: use a
mix-net like Tor and voila, you are anonymous and nobody can peek in
through the roof anymore what you are doing in your bedroom....

> connections just nullifies the effect of any changing-address privacy

Restarting *all* connections with the new IP will just demonstrate that
you changed IP and are reconnecting to all previous sites.

> randomizing bits does something helpful.

If you think it is helpful, giving the hints I give above and in other
mails, how exactly is it "helpful" at all?

Note, I am against removing /64 length. And I am just stating that the
privacy addresses are nothing special and are not a bonus one is getting
because one has /64 bits of randomness.

Note also that if one choses to do so with the help of DHCPv6 one can
already use longer than /64 prefixes in a network.

> That has nothing to do with the issue at hand.

It has, it shows that without ('reset' at least) upper level protocol
details various companies easily show that they can know who you are
based on other bits.

Note also that IP is nothing without an application, it is needed.

The issue I raised for this privacy-extensions-subthread of 'why /64' is
that an IP address is easily tracked and that the so called 'privacy
extensions' do not help there. Tools and techniques exist to easily
track you. It does not matter how large the subnet is you are living in,
as the adversary can estimate that size and estimate how many people are
using that subnet (be that a /128, a /64 or a /48).

Note that that tracking is *independent* of the upper protocols. Just
the mere fact that some people connect to X and others connect to Y
makes them easy correlated to each other.

> either (read: HTTP cokies...)

You are forgetting that IP is always used in combination with TCP and
UDP (and rarely with something like SCTP or something else). Rarely (but
hopefully more often) folks will use IPSEC to protect the lower layer
bits; but if one can see those bits crypto analysis can be done to
assign an identity too.

IP (be that IPv4 or IPv6) will never ever make you 'private' or
'anonymous'. And no, it does not really matter how much you randomize
those bits.

> Australia to reach Europe given Ethernet was only designed for local

But as I stated, only seeing IP is good enough for this 'tracking'.

As a small hint, most of this tracking (or better 'correlation') today
happens simply with NetFlow; which just sees src/dst IP and the protocol
and port numbers there are just extra details.

They don't even have to bother looking inside the packets; though it
would make it much easier for many correlations especially with so many
people giving too many details away, hence the well-known and easily
demonstrated HTTP method I mentioned.

> about the local machine? Is this a problem? If it is (at all) is it

The IPv6 specification itself does not leak anything. Unless you think
it is a problem that the world knows that you are yet another Mac user
based on your NIC. Hence why Microsoft one-time randomizes the EUI-64
portion, that "solve" that part.

It is the way that IP and its underlying protocols (TCP, UDP, SCTP, etc)
are implemented that leak details.

If they did not nmap or even passive fingerprints would not be possible.
Note that these are typically miniscule differences in the stacks.

Very little that can be done by the IETF to resolve these kind of things.

On 2013-10-29 18:38, Scott Brim wrote:
> Right, and: Avoid designing the fundamental protocols of the Internet
> such that privacy is impossible, even if they fix the non-fundamental
> parts.

IP is not made for Privacy. It never has and never will. It is an
end-to-end communications protocol. Hence unless you use a mixnet (eg
Tor) which end-middle-middle-middle-end you are not going to private.

Our add-on friend IPSEC (which is supposed to be in the base IPv6
specification but has been silently ignored by everybody but Microsoft
(Direct Access and Xbox One) only hides&/auths your payload.

The IP layer will still reveal who you are talking to and thus
adversaries that look at connections will know who you are and who you
are talking to and will correlate and will figure you out even when
changing IP addresses all the time or heck prefixes in many cases.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 30 Oct 2013 10:01:11 +0100

> On 10/29/2013 04:42 AM, Jeroen Massar wrote:
[..big snip..]
> I can't use ::5 because my office mate might also like 5.

That can be a problem in that scheme yes. Hence why DHCPv6 exists.

> rather than "privacy" addresses?

That would help yes. They definitely are not private indeed.

[..]
> particularly sure that I don't use the same IP address I use for my

Depends on where your adversary is. If he can see you talking to the
first Tor hop, then yes; but otherwise it should not be a problem.

> Ok, privacy addresses are more like window curtains than Faraday cages.

That analogy works for me.

> unlike so-called "private browsing")

Quite. As even if your cookies are gone, if you connect in the same time
frame from the same IP address, with the same browser User-Agent and
other factors (try EFF panopticlick in private browsing, lots of fun);
you will be the same person for most sites which are a bit good at
correlation.

[..]
> **at least if the attacker had access only to the remote endpoint**.

If I am looking for 1 person out of a million and I can narrow it down
to 200, quite a few adversaries would be quite happy already.

[..]
> For the record, I got the *same* result on every machine:

How many people are using your IP address/prefix? ;)
Does the IP address you use change often?

Note also that you tried the autocomplete, which gives relevant search
queries for you / your area. It is typically better test to check for a
search query that you regularly do (as the way you type it and if you
have autocomplete=on the speed and typos you make is what helps them
identify you).

[..]
>> JM: And HTTP is not the only way to detect things, every protocol has
>> meta data.
> about privacy may pay more attention to these things than I do, and choose
> "safer" protocols.

Depends all on what you are protecting against.

> multiple IPv6 addresses is not quite in the spirit of rfc4941.

Ack.

> imperfect, possibly even to the point of being misleading, but worth

IMHO they are very misleading. In 2001 when they where 'invented' it was
reasonable to call them 'privacy'. In 2013 far from with all the things
learned and tech that has evolved.

> have no value in any circumstances.

Trust me, they do not have any value whatsoever.

The above suggestion about an IP per connection/app would only allow the
adversary to count how many connections you made or how many apps you
have running on your host. And thus make it easier to figure out which
one of many you are. Yes, it would explode the database a bit, but
wh00p, big-data is definitely there in 2013.

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Oct 2013 21:27:38 +0900

On Wed, Oct 30, 2013 at 6:54 AM, Manfredi, Albert E <
[email-masked]> wrote:

> CIDR evolved for a reason: the old 32-bit classful scheme became
> inadequate when the Internet moved from an academic/military net of a few
> 10s of thousands, to something for the masses.
>

Yes, CIDR evolved for a reason: we were running out of IPv4 address space.

We don't have that problem in IPv6 at the moment, and various people have
gone through the math showing that we won't have that problem for decades.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Oct 2013 08:46:53 -0400

And we do have classless aggregation and delegation within the upper 64 
bits.

Yours,
Joel

On 10/30/13 8:27 AM, Lorenzo Colitti wrote:
> On Wed, Oct 30, 2013 at 6:54 AM, Manfredi, Albert E
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     inadequate when the Internet moved from an academic/military net of
>     a few 10s of thousands, to something for the masses.
>
>
> We don't have that problem in IPv6 at the moment, and various people
> have gone through the math showing that we won't have that problem for
> decades.
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 30 Oct 2013 21:32:48 +0100

> Certainly. Use a /64. What is the problem with that?

As I see it the problem is that /64 supports more than 4 entities; I 
would like a link that only has 4 entities.  Maybe DAD would be safe to 
assume to take shorter time?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 30 Oct 2013 21:37:33 +0100

> find is a contentious proposal with many pros and cons.

Yes it is.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 30 Oct 2013 21:45:58 +0100

> have gone through the math showing that we won't have that problem for

I guess we could live through the same decades, and more, if we didnt 
have that 64 limit.

Alex

---

From: Erik Kline <[email-masked]>
Date: Wed, 30 Oct 2013 20:45:35 -0700

On 30 October 2013 13:45, Alexandru Petrescu
<[email-masked]> wrote:
> I guess we could live through the same decades, and more, if we didnt have
> that 64 limit.

I don't think we should be designing a "solution" for a problem that
we don't actually have.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 31 Oct 2013 06:51:11 +0100

> I don't think we should be designing a "solution" for a problem that

The 64 limit problem is there in the inherent design.

One easy way to observe it is to connect to numerous operators and be 
surprised to only obtain a 64 and be unable to further extend one's 
Ethernet network.

Other ways that may be more difficult to need and observe is with 
smaller subnets (4-max node).

Alex

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 31 Oct 2013 04:52:51 -0700 (PDT)

----- Original Message -----
> Sent: Thursday, 31 October 2013 7:32 AM
> Subject: Re: Why /64
> 
<snip>
> would like a link that only has 4 entities. 

How would you automate growing the subnet to accommodate adding a 5th device?

It is quite painful to grow a public addressed IPv4 subnet, although NAT has suppressed that cost in residential cases because allows "excessively large" subnets to be used too (how many houses have 254 devices, "needing" a 192.168.0/24 subnet on the LAN interface?).

Public IPv6 with "right sized" subnets would expose that task and cost to people who haven't experienced it before (or rather, more likely expose it to technical relatives like us if we're available), and it is likely that CPE vendors would react by resorting to using IPv6 NAT and a nice large /64 on the LAN interface to again hide it.

> Maybe DAD would be safe to 

> assume to take shorter time?

How would that allow DAD to be performed in a shorter time? The DAD process isn't proportional to the number of addresses on the subnet.

Using ARIN XX-Small fees ($500 p/a, /22 for IPv4, /40 for IPv6), as IPv4 addresses cost $0.48 each per annum, and IPv6 addresses cost $1.62E-024 each per annum, there is no need to spend any effort and time trying to develop mechanisms that would "right size" an IPv6 subnet to save IP address costs, and that is the only reason I can think of as to why somebody would want to do that.

Regards,
Mark.

---

From: Erik Kline <[email-masked]>
Date: Thu, 31 Oct 2013 14:07:22 -0700

>>> have
> surprised to only obtain a 64 and be unable to further extend one's Ethernet
> network.
>
> Other ways that may be more difficult to need and observe is with smaller
> subnets (4-max node).

Sounds like you need a problem statement draft, since subtending a /64
network is not necessarily trivial (even if you can do autoconf for
something like a /80), i.e. you have routing issues to solve as well.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 31 Oct 2013 21:14:13 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik
> Kline

> something like a /80), i.e. you have routing issues to solve as well.

What routing issues? I'm curious.

If a residence, or an automobile, is assigned a /64, presumably any routing from the WAN will be aggregated to that home or vehicle already. Then inside, your gateway takes care of the rest, no?

I think any prediction that 64-bit prefixes are the most we could ever want "for decades to come" is only as good as the assumptions made to reach that predictions. These assumptions are notoriously poor.

Bert

---

From: Erik Kline <[email-masked]>
Date: Thu, 31 Oct 2013 14:19:42 -0700

> If a residence, or an automobile, is assigned a /64, presumably any routing from the WAN will be aggregated to that home or vehicle already. Then inside, your gateway takes care of the rest, no?

No gateway currently does this, i.e. it will not "just work" today.

Furthermore, I would argue that no home gateway currently expects that
it should do this, since it hasn't been documented as a requirement.

That's the kind of stuff to which I was referring.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 31 Oct 2013 21:24:12 +0000

> From: Erik Kline [mailto:[email-masked]]
> Sent: Thursday, October 31, 2013 5:20 PM
> To: Manfredi, Albert E
> Cc: IETF IPv6 Mailing List
> Subject: Re: Why /64
> 
> > If a residence, or an automobile, is assigned a /64, presumably any routing
> from the WAN will be aggregated to that home or vehicle already. Then inside,
> your gateway takes care of the rest, no?
> 

Understood. And I find this troubling and unnecessary. That's my point. We have this huge 128-bit address space, and we are putting ourselves in a position where we actually only have maybe 48 or at most 56 bits of "distribution potential," meaning "to different sites." Where IPv4 with CIDR has essentially 32. How come this isn't troubling?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Nov 2013 10:50:20 +1300

> Understood. And I find this troubling and unnecessary. That's my point. We have this huge 128-bit address space, and we are putting ourselves in a position where we actually only have maybe 48 or a…

Because there are trillions of /48s.

   Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 31 Oct 2013 22:06:00 +0000

> From: Brian E Carpenter [mailto:[email-masked]]

> Because there are trillions of /48s.

And we think that is way more than adequate, today. Until the paradigm changes, and every vehicle, every street, every building, every person, will need its own internal subnet structure. For things like vehicle-to-infrastructure comms, vehicle-to-vehicle comms, internal vehicle controls and diagnostics (separated into multiple subsystems of course), wearable medical sensors, and who knows what else. And space.

I'm just saying, classful IPv4 also seemed like plenty at first. It was a mere decade before we knew differently.

Bert

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Oct 2013 22:26:17 +0000

Hi, I have a whacky idea on why /64 is already a good number.
Routers on a link are identified by their link-local address;
always beginning with fe80. But, the interface identifier bits
are essentially wasted by including the EUI-64 encoding of the
MAC address while the MAC address is already available in the
L2 header.

But, since we delegate routable IPv6 prefixes to routers, why
not include the IPv6 prefix in the router's link-local IPv6
address?

For example, suppose the prefix 2001:db8:foo:baa::/64 were
delegated to a router then the router could configure the
IPv6 link-local address "fe80::2001:db8:foo:baa". This then
provides a useful router ID to other nodes on the link so
that the prefixes reachable through the router can be
gleaned by looking at the 64-bit interface identifier.

It would then be a configuration option on a link-by-link
basis as to whether the link supports this new "IPv6 prefix
embedded link local address" format. Then, legacy links can
continue to use good old EUI-64-based link-locals and new
links can use this new format. Just a thought.

Fred
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Nov 2013 09:35:52 +1100

In message <[email-masked]>, "Manfredi, Albert E" writes:
> And we think that is way more than adequate, today. Until the paradigm changes, and every vehicle, every street, e
> very building, every person, will need its own internal subnet structure. For things like vehicle-to-infrastructur
> e comms, vehicle-to-vehicle comms, internal vehicle controls and diagnostics (separated into multiple subsystems o
> f course), wearable medical sensors, and who knows what else. And space.
> 

No classful IPv4 was *known* to not scale from the very beginning.

There are 72057594037927936 /56's which are what most ISP are
planning to hand out to residential customers.

If you really want to be miserly you can request /64's on a needs
basis with PD which is what internal home routers will need to do
so the code to support this will exist if we ever need to got to
that level when talking to ISP's.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Nov 2013 11:39:00 +1100

In message <[email-masked].
com>, "Manfredi, Albert E" writes:
> Understood. And I find this troubling and unnecessary. That's my point. We ha
> ve this huge 128-bit address space, and we are putting ourselves in a positio
> n where we actually only have maybe 48 or at most 56 bits of "distribution po
> tential," meaning "to different sites." Where IPv4 with CIDR has essentially 
> 32. How come this isn't troubling?

Because at 20 billion people you have 3 million networks per person with /56's.

		(2^56)/(2*10^10) = 3602879

Mark

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 1 Nov 2013 00:59:22 +0000

> From: Mark Andrews [mailto:[email-masked]]

> Because at 20 billion people you have 3 million networks per person with

But this continues to miss the point. It used to be mainframes at organizations. Then it became PCs in homes and offices. Then it became PCs and cell phones and tablets and printers and scanners and ...

Now think of beacons at road edges, potholes, road signals, street lights, crosswalks, yield signs, lane merge, nature trail, bike path, shipping lane, buoys, and so on, in addition to what you might have now associated with people, homes, offices. It's not just associated with people anymore.

All of these need organizational networks. Not all of these networks need anywhere close to 2^64 hosts apiece. Why would you need 2^64 IIDs for a subnet of neighborhood streetlights, for instance?

Bert

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 01 Nov 2013 01:59:57 +0100

> Because there are trillions of /48s.

And because every such site gets a /48 (or /56) and then can do whatever
they want with that. ;)

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Nov 2013 14:48:19 +1300

>  Why would you need 2^64 IIDs for a subnet of neighborhood streetlights, for instance?

Unguessable IIDs, for example, unless you would like Stuxnet 3.0
flashing your city's streetlights like a Christmas tree,
or PRISM 2.0 keeping a close eye on you.

Structured IIDs, if you'd like to put semantics into them
(which I think is a terrible idea, but maybe opinions will be
different in 2113).

ILNP.

If we'd just wanted to do IPv4.1, we'd have picked 64 bits
instead of 128. As it is, we have 64 bits for CIDR and 64 bits
for new ideas.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Nov 2013 12:56:11 +1100

In message <[email-masked].
com>, "Manfredi, Albert E" writes:
> But this continues to miss the point. It used to be mainframes at organizatio
> ns. Then it became PCs in homes and offices. Then it became PCs and cell phon
> es and tablets and printers and scanners and ...

And you think it will get to 3 million things per person that need
their own network?  Printers, scanners and phones attach to networks.
Phone that are tethering can request /64's as required from upstream.

> Now think of beacons at road edges, potholes, road signals, street lights, cr
> osswalks, yield signs, lane merge, nature trail, bike path, shipping lane, bu
> oys, and so on, in addition to what you might have now associated with people
> , homes, offices. It's not just associated with people anymore.

Again how many of them will need their own network rather than
connect to a network?   The network count is orders of magnitude
smaller than the device count.

> All of these need organizational networks. Not all of these networks need any
> where close to 2^64 hosts apiece. Why would you need 2^64 IIDs for a subnet o
> f neighborhood streetlights, for instance?

You don't and and the electricity company / council can configure
the network to use something smaller if they want.  Nobody is
forcing people to use large networks if they don't want to.  They
can always stand up a stateful DHCP server and send approptiate RA's.

They could cover a whole country out of a /64 if they wanted to.

You however seem to want everyone to stand up a stateful DHCP server
when there is no need to do so.  Device configuration doesn't need
a stateful DHCP server.  Only address assignment needs a stateful
DHCP server.

Mark

---

From: Karl Auer <[email-masked]>
Date: Fri, 01 Nov 2013 13:53:05 +1100

> Why would you need 2^64 IIDs for a subnet of neighborhood streetlights, for instance?

I don't know. But the key thing is that I don't need to. When I ask for
a glass of water at a restaurant, I do not know or care how many water
molecules I'm buying, either. It doesn't *matter*.

No-one ever seems to consider the *advantages* of the "/64 everywhere"
approach. They decry the "waste" without looking at what that "waste" is
buying:

- everything is the same. No more calculating (leaf) subnet sizes, no
more stealing from Peter to pay Paul, no more getting it wrong - every
subnet is a /64.

- there are *always* enough addresses in *any* subnet for you add one
more device. Or even a hundred. You might run into other limits, but the
addressing will never get in your way.

- adding a subnet is easy - just take the next /64. No estimates,
calculations, consideration or judgement needed.

- your router configs are easier to understand

- your documentation is easier to write and easier to read.

What this boils down to is greater ease of network management and
administration. And that translates directly into money saved - saved in
design time, saved in implementation speed, save in ease of
troubleshooting, saved in ease of documentation, saved in fewer errors
made, saved in less downtime.

Spread across the whole Internet, all those advantages multiply. 

All those benefits come just from having a standard subnet size big
enough to accommodate any likely number of hosts. The fact that it is
big enough to handle completely *unlikely* numbers of hosts is a bonus -
because you can forget about that problem too. Your subnets will
*always* be big enough.

We could argue about where the line should be; how big the standard
network should be. For any remotely reasonable number of devices in
a /64, you are using zero percent of the 18 billion billion available
addresses. 2, 200, 20,000 or even a million, it's still zero percent to
a dozen decimal places. Let's sliiiiiide the pointer to the right,
making the standard network smaller and smaller and smaller until that
percentage is something bigger - say 1%. What have you achieved? If you
still have a big enough subnet to accommodate any likely number of
hosts, you are "wasting" addresses. Anything smaller, and you've brought
that old IPv4 concern back into the world - "have I got enough
addresses?" And if you make it so that you can have any sized leaf
subnet, you lose all the lovely advantages of "one size fits all".

My definition of "waste" is spending a limited resource for no benefit.
The above benefits seem to me to have real value, so I don't consider
"/64 everywhere" to be a "waste".

Regards, K.

---

From: Ray Hunter <[email-masked]>
Date: Fri, 01 Nov 2013 07:57:06 +0100

> that level when talking to ISP's.

Which would be fine if:

1) All allocations continue to be made by ISPs on a network provider =>
consumer model

2) We had a routing mechanism that could handle such a flat addressing
structure

3) We had a delegation mechanism for naming and addressing that could
easily cope with delegation on bit boundaries.

but we don't.

1. More and more we see demand from manufacturers e.g. car engine
management, and even subcomponent management.

2. We have a very limited number of bits of hierachy for route
aggregation, and thus effectively a limit to the hierarchical depth of
network topology/ organisations.

3. Once you factor in recommendations to delegate on nibble boundaries
(e.g. for DNS) you have somewhere around /32 to /64 = ±9 nibble
boundaries => 9 levels of depth of hierarchy + a flat LAN.

IMHO I think what we effectively have is an administrative
(non-technical) limit to scaling today, largely limited by an ability to
register, delegate, and aggregate; rather than the huge number of
possible addresses or prefixes. 'twas ever thus. In IPv4 it was
effectively +/- 3 levels (octet boundaries + a flat LAN).

regards.

-- 
Regards,
RayH