So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses? I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device! Am I still seeing/reading/understanding this correctly? - Brian

-----Original Message----- From: Seth Mattinen [mailto:sethm@rollernet.us] Sent: Monday, October 05, 2009 10:38 AM To: nanog@nanog.org Subject: Re: ISP customer assignments

Brian Johnson wrote:

...

...

From what I can tell from an ISP perspective, the design of IPv6 is for assignment of a /64 to an end user. Is this correct? Is this how it is currently being done? If not, where am I going wrong?

The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one.

~Seth

more-or-less. Can I suggest you read:

http://en.wikipedia.org/wiki/IPv6

Think of ipv6 not as 128 bits of address space, but more as a addressing system with a globally unique host part and 2^64 possible subnets. In this respect it's substantially different to ipv4.

And after reading Wikipedia, follow it up with ARIN's http://www.getipv6.info wiki site. --Michael Dillon

"Brian Johnson" <bjohnson@drtel.com> writes:

So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses?

I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device!

Most people will have more than one device. And there is no NAT as you know it from IPv4 (and hopefully there never will be. I had to troubleshoot a NAT related problem today and it wasn't fun.[1]) And I want more than one network I want to have a firewall between my fridge and my file server.

Am I still seeing/reading/understanding this correctly?

RFC 3177 suggest a /48. Forget about IPv4 when assigning IPv6 Networks to customers. Think big an take a one size fits all(most) customers approach. Assign a /48 or /56 to your customers and they will never ask you about additional IPs again. This make Documentation relay easy. ;-) cheers Jens [1] Everybody who claims that NAT is easy should have his or her head examined. -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink@guug.de | -------------------------------------------------------------------------

Am I the only one that finds this problematic?

No, but most of the people who find this "problematic" haven't done any looking into the matter.

I mean, the whole point of moving to a 128 bit address was to ensure that we would never again have a problem of address depletion. Now I'm not saying that this puts us anywhere in that boat (yet) but isn't saying "oh, lets just put a /64 on every interface" pretty well ignoring the lessons of the last 20 years? Surely a /96 or even a /112 would have been just as good.

No, it wouldn't have been. The sheer usefulness of having things like stateless autoconfig for many trivial applications should not be underestimated.

Lets think longer term... IPv4 is several decades old now and still in use. If IPv6 lasts another 50 years before someone decides that it needs a redo, with current practices, what will things look like? Consider the population at that point and consider the number of interfaces as more and more devices become IP enabled. "wireless" devices have their own issues to content with (spectrum being perhaps the biggest limiter) so wired devices will always be around. That means physical interfaces and probably multiple LANs in each residence. I can see where each device may want its own LAN and will talk to components of itself using IP internally, perhaps even having a valid reason for having these individual components publically addressable.

Do some math, then. A /64 handles a single network. An essentially infinite number of devices can live within that space, though there are practical limits. You might realistically have a network for your light switches and a network for your A/V gear. You seem to anticipate that, so let's just say we agree, but I'm going to make a big whopper claim and say that we should delegate /48 to end users. This means each user could have up to 65,536 /64's. While I can daydream about scenarios that would eat up a significant fraction of those subnets, I have to also concede that consolidation is probably possible. Population today is about 7 billion. A fairly aggressive long range report by the UN puts population in 2300 as high as maybe 40 billion, or about six times our current population. Let's just pretend we had the 40 billion today. To come up with 40 billion unique /48 allocations, we'd need almost 36 bits. Of course, this assumes that you can sequentially allocate them. More realistic scenarios suggest that you'd have several bits worth of sparseness. Maybe 40 bits. Okay, 40 bits is close to 48 bits. But we're not delegating /48's to everyone (yet) and we don't have 40 billion people on the planet.

Like I said, I'm not necessarily saying we're going to find ourselves in that boat again but it does seem as though more thought is required. (And yes, I fully realize the magnitude of 2^64. I also fully realize how quickly inexhaustable resources become rationable.)

People HAVE done the thought. They've thought about it and argued it back and forth for years. This isn't a good place to continue to beat the discolored spot where the dead horse formerly lay; there are some discussions in the NANOG archives as it stands. It's mostly only those who are steeped in the IPv4 thinking and who haven't done the math are concerned about /64's. And note that you're *free* to go allocate a /96 or a /112 to your devices if you really want to do the manual configuration. What's required is for you to do the thinking as to whether or not it is worth it to paddle furiously against the current to save a resource that is in no short supply. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Oct 5, 2009, at 11:34 AM, Wayne E. Bouchard wrote:

On Mon, Oct 05, 2009 at 08:18:23PM +0200, Jens Link wrote:

...

"Brian Johnson" <bjohnson@drtel.com> writes:

...

So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses?

I realize that this is future proofing, but OMG! That?s the IPv4 Internet^2 for a single device!

Most people will have more than one device. And there is no NAT as you know it from IPv4 (and hopefully there never will be. I had to troubleshoot a NAT related problem today and it wasn't fun.[1])

And I want more than one network I want to have a firewall between my fridge and my file server.

...

Am I still seeing/reading/understanding this correctly?

RFC 3177 suggest a /48.

Forget about IPv4 when assigning IPv6 Networks to customers. Think big an take a one size fits all(most) customers approach. Assign a /48 or / 56 to your customers and they will never ask you about additional IPs again. This make Documentation relay easy. ;-)

cheers

Jens

Am I the only one that finds this problematic? I mean, the whole point of moving to a 128 bit address was to ensure that we would never again have a problem of address depletion. Now I'm not saying that this puts us anywhere in that boat (yet) but isn't saying "oh, lets just put a /64 on every interface" pretty well ignoring the lessons of the last 20 years? Surely a /96 or even a /112 would have been just as good.

Nope.... It really isn't. If we wanted to do that, then, IPv6 would probably have 64-bit addressing, instead of 128-bit, and, you'd have 32 bits of carrier, 16 bits of end- site, 8 bits of subnet and 8 bits of host (or something approximating that). Part of the reason that 128 bits was chosen (64 bits is FAR more than enough) was that it allowed for 64 bits of stateless auto-configuration (IEEE was already pushing EUI-64) within each network and still provided more than enough network numbers.

Lets think longer term... IPv4 is several decades old now and still in use. If IPv6 lasts another 50 years before someone decides that it needs a redo, with current practices, what will things look like?

OK.

Consider the population at that point and consider the number of interfaces as more and more devices become IP enabled. "wireless" devices have their own issues to content with (spectrum being perhaps the biggest limiter) so wired devices will always be around. That

The planet's sustainable population is not likely to exceed 10 billion. (However, current growth is approximately 80 million per year, so, our current 6 billion + 80 million * 50 = 4 billion still puts us at around 10 billion, so, it should be a safe number even if we throw sustainability out the window). IPv6 offers us 32 bits of provider units == 4 billion providers. Each provider can serve 65,536 customer units which gives us the ability to support 281,474,976,710,656, or, about 281 trillion customers. Each customer unit gets 65,536 subnets to do with as they like and they still have 64 bits on each subnet.

means physical interfaces and probably multiple LANs in each residence. I can see where each device may want its own LAN and will talk to components of itself using IP internally, perhaps even having a valid reason for having these individual components publically addressable.

It's OK. We can do it. We will still have addresses to spare even in 50 years, even with that.

Like I said, I'm not necessarily saying we're going to find ourselves in that boat again but it does seem as though more thought is required. (And yes, I fully realize the magnitude of 2^64. I also fully realize how quickly inexhaustable resources become rationable.)

Well... There is a safety valve. We are only issuing from 1/8th of the current address space at this time. If we run that out before we expect to and it becomes clear that there is a need to allocate differently, we can begin doing that from the next 1/8th without any real changes to the protocol or router software. Really, it's OK. Owen

So a customer with a single PC hooked up to their broad-band connection would be given 2^64 addresses?

I realize that this is future proofing, but OMG! That’s the IPv4 Internet^2 for a single device!

Am I still seeing/reading/understanding this correctly?

The fact that you could use it for a single device is irrelevant. We have learned the problems imposed by the shortsightedness of IPv4. You're already given 65536 ports for your IPv4 device. OMG, you do not /really/ need that many for a single device! This issue has been hashed over many times. Stop thinking IPv4, where bits are in sufficiently short supply that we "feel" assignment of any extra space is "waste." Start thinking IPv6, where bits are in such great supply that it makes sense to think about stuff like making sure delegations are sufficiently large that your typical ASN isn't having to advertise a hundred prefixes of cobbled-together-over-the-years space, that NAT can be purged from the face of the earth, etc. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Oct 5, 2009, at 17:38, Seth Mattinen wrote:

The most common thing I see is /64 if the end user only needs one subnet, /56 if they need more than one.

Brrzt, wrong. Neither the end user nor you know the answer to that question! So the only sensible thing is to always give them a /56. (Actually, the IPv6 address architecture design was to give them a / 48. Think about it: We will run out of MAC addresses before we run out of those. But some people can't manage the cognitive dissonance coming from an address starving IPv4 world and then "wasting" all these 2^80 addresses. My parents, who grew up around WW2, were that way, too, and never could unlearn their "saving" habits. So the current "wise" thing is to allocate a /56, "wasting" only 2^72 addresses per customer. The only way back to a connected Internet.) Gruesse, Carsten

On Mon, Oct 05, 2009 at 01:10:15PM -0500, Brian Johnson wrote:

What would be "wrong" with using a /64 for a customer who only has a local network? Most home users won't understand what a subnet is.

IPv6 CPE's may be designed to get one subnet per physical media via DHCPv6-PD, so for example wireless and wired may be different subnets. Really, /56 is the way to go for residential assignments.

[here we go again] On Mon, 05 Oct 2009 14:37:49 -0400, William Herrin <herrin-nanog@dirtside.com> wrote:

Some clever guy figured out that ... why not add an extra 64 bits for that very convenient improvement? This is called "stateless autoconfiguration."

Except that "clever guy" was in fact an idiot blinded by idealism. Not only did he fail to see the security implications of having a fixed address, but he'd apparently spent his entire life under a rock, on an island, on another planet... he completely ignored the fact that people were using DHCP [formerly known as BOOTP] (and have been now for over a decade) to provide machines with FAR MORE than just an address. A machine needs more than just an address to be useful -- something IPv6 users learn very quickly after turning off IPv4 and it's DHCP learned info.

Some even more clever guy figured out that if the first clever guy's strategy is used, it becomes a trivial matter to track someone online... ... stateless autoconfiguration will probably end up being a waste.

It's ALWAYS been a waste. All these supposed "clever guys" failed to learn from the mistakes that preceded them and have doomed us to repeat them... ICMP router discovery (technology abandoned so long ago, I'd forgotten about it), RARP, bootp, dhcp. SLAAC loops us back around to the beginning. Only this time, it's inescapable: I still have to have something on the network spewing RAs for the sole purpose of telling everything to use DHCP instead; there's a hard "class" boundary smack in the middle of a "classless network" because these "clever guys" were lazy and didn't want to figure out ways to avoid address collisions. (something modern IPv6 stacks do by default for privacy -- randomly generated addresses have to be tested for uniqueness.) --Ricky

On Mon, 05 Oct 2009 16:13:37 CDT, Dan White said:

a publicly routeable stateless auto configured address is no less secure than a publicly routeable address assigned by DHCP. Security is, and should be, handled by other means.

The problem is user tracking and privacy. RFC4941's problem statement: Addresses generated using stateless address autoconfiguration [ADDRCONF] contain an embedded interface identifier, which remains constant over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier. The correlation can be performed by o An attacker who is in the path between the node in question and the peer(s) to which it is communicating, and who can view the IPv6 addresses present in the datagrams. o An attacker who can access the communication logs of the peers with which the node has communicated. Since the identifier is embedded within the IPv6 address, which is a fundamental requirement of communication, it cannot be easily hidden. This document proposes a solution to this issue by generating interface identifiers that vary over time. Note that an attacker, who is on path, may be able to perform significant correlation based on o The payload contents of the packets on the wire o The characteristics of the packets such as packet size and timing Use of temporary addresses will not prevent such payload-based correlation. (end quote) Or phrased differently - if I DCHP my laptop in a Starbuck's, on Comcast, at work, at a hotel, and a few other places, you'll get a whole raft of answers which will be very hard to cross-corrolate. But if all those places did IPv6 autoconfig, the correlation would be easy, because my address would always end in 215:c5ff:fec8:334e - and no other users should have those last 64 bits. Amazingly enough, some people think making it too easy to Big-Brother you is a security issue...

On Mon, 05 Oct 2009 18:55:35 -0400, Dan White <dwhite@olp.net> wrote:

All of the items in the above list are true of DHCP. ...

In an IPv4 world (which is where DHCP lives), it's much MUCH harder to track assignments -- I don't share my DHCP logs with anyone, nor does anyone send theirs to me. From the perspective of remote systems (ie. not on the same network), there is about a 100% chance NAT is involved making it near impossible to individually identify a specific machine, even if it gets the same address every Tuesday when you're at Starbucks for coffee. IPv6 does away with NAT (or it's supposed to); in doing so, the veil is removed and everything that had been hidden from site is now openly displayed. If the "host" part of your address never changes, then you are instantly identifiable everywhere you go, with zero effort, forever. --Ricky

On Mon, 05 Oct 2009 16:13:37 CDT, Dan White said:

...

a publicly routeable stateless auto configured address is no less secure than a publicly routeable address assigned by DHCP. Security is, and should be, handled by other means.

The problem is user tracking and privacy.

RFC4941's problem statement:

Addresses generated using stateless address autoconfiguration [ADDRCONF] contain an embedded interface identifier, which remains constant over time. Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier.

The correlation can be performed by

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

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

Since the identifier is embedded within the IPv6 address, which is a fundamental requirement of communication, it cannot be easily hidden. This document proposes a solution to this issue by generating interface identifiers that vary over time.

Note that an attacker, who is on path, may be able to perform significant correlation based on

o The payload contents of the packets on the wire

o The characteristics of the packets such as packet size and timing

Use of temporary addresses will not prevent such payload-based correlation. (end quote)

Or phrased differently - if I DCHP my laptop in a Starbuck's, on Comcast, at work, at a hotel, and a few other places, you'll get a whole raft of answers which will be very hard to cross-corrolate. But if all those places did IPv6 autoconfig, the correlation would be easy, because my address would always end in 215:c5ff:fec8:334e - and no other users should have those last 64 bits.

Amazingly enough, some people think making it too easy to Big-Brother you is a security issue...

Isn't this really a security by obscurity argument? Making it a bit harder for the attacker, relying on 'Eve' just not realizing who I am? Most of those concerns are in fact mitigated by a well implemented Privacy implementation ... and many of the remaining concerns do in fact apply to IPv4. Not to mention the 'higher layer' aspects. Bottom line - if you are doing something that warrants some level of privacy or protection, you should do something to ensure that level of privacy or protection - never assume you are private/secure by default. /TJ

On Oct 5, 2009, at 2:10 PM, Brian Johnson wrote:

What would be "wrong" with using a /64 for a customer who only has a local network? Most home users won't understand what a subnet is.

They probably don't -- but some appliance they buy might. Maybe some home "family-oriented" box will put the kids' machines on a separate VLAN, to permit rate-limiting, port- and destination-filtering, time- of-day limits, etc. In the past, I had to do similar things -- no AIM during homework hours, no file-sharing -- to the point that I had four subnets in my house (wireless, teen-net, workVPN, and backbone/ parents). I don't expect the average consumer to set up something like that, but I sure wouldn't be surprised at appliances that did. --Steve Bellovin, http://www.cs.columbia.edu/~smb

-----Original Message----- From: William Herrin [mailto:herrin-nanog@dirtside.com] Sent: Monday, October 05, 2009 12:58 PM To: Brian Johnson Cc: nanog@nanog.org Subject: Re: ISP customer assignments

/60 - the smallest amount you should allocate to a downstream customer with more than one computer. Anything smaller will cost you extra management overhead from not matching the nibble boundary for RDNS delegation,

I have a lack of imagination, I guess. I can't imagine anyone larger than a small residential user being assigned a /60 or less. Therefore, nybble boundary for rDNS delegation only matters if you delegate rDNS for that block.

handling multiple routes when the customer grows, not

Any customer getting a /60 or less will be dynamically numbered (RA, DHCPv6, whatever), and if more space is needed, should be easily renumbered into a larger prefix.

matching the standard /64 subnet size and a myriad other obscure issues.

I don't know about "myriad" but I agree that /64 is the standard subnet size. I am *not* advocating assignments of /60 or less, just pointing out that if you do it, it doesn't have to break. Lee