Where to buy Internet IP addresses

> EUI-64 is required for autoconfig...

"On paper" :slight_smile: There's no technological reason why the 48bit MAC wouldn't
be enough on it's own.

For today. But, remember, this sort of shortsightedness is what landed
us in the current IPv4 pain. Do you have anything beyond hysterical
raisins to justify not making a future-proofing change now, before IPv6
is widely deployed, and changes can be easily made?

Tacking on an extra (fixed) 16bit value doesn't
make it any more unique.

For ethernet, today.

Doing so also would not add any level of
complexity to address determination -- it's still a simple concat.

Correct. So it's trivial to do, and it future-proofs us to be able to
support EUI-64. That means that when the next great networking technology
comes about, we don't need to make invasive changes, devise transition
strategies, or wreak havoc.

Show of hands. How many people have massive firewire based IP networks?

Who the fsck cares.

*crickets* Right. (I've used ip1394 like twice in over a decade... a file
transfer between a laptop and desktop.)

Yeah, that's nice. Who the fsck cares.

Most of the significant problems with IPv4 are due to people thinking
small, and not having a vision towards the future. Back when "computers"
meant something the size of a VAX 11/750 or bigger, it is easy to see
how designers didn't really have the concept that maybe someday there
would be microprocessors all around us, that we'd be walking around with
cell phones that had more computational capabilities than their entire
computer. Likewise, I am afraid to wonder what we're going to see in
another 30 years, but my bet is that it'll be networked!

So, please, please, either explain why EUI-64 is such a horrible, awful,
terrible hardship for you to endure. If it's because your Atari 400
doesn't have the cycles to keep up with EUI-64 translation at gigabit
speed, then say that. Or you can outline some other way in which it is
fundamentally a bad idea to future-proof by using the latest EUI
standard, rather than an old, dated standard.

If you don't actually have a rational explanation, then you just appear
to be a troll.

... JG

For today. But, remember, this sort of shortsightedness is what landed
us in the current IPv4 pain.

48bit MACs have caused IPv4 address exhaustion? Wow. I didn't know that.

... justify not making a future-proofing change now, before IPv6
is widely deployed, and changes can be easily made?

It's not very widely deployed now, and it's already too late to make simple changes. ONE single, simple protocol change requires a lot of people to do a lot of work.

For ethernet, today.

IPv6 is a decade old and there still aren't many people using it. Ethernet is 30 years old. Do you honestly think you'd be able to roll out EthernetV2(tm) with 64bit MACs anytime in the next century? Ethernet is far more fundamental than IPv4, grown into the silicon of almost everything. Even though there are alternatives to ethernet (infiniband anyone?) ethernet is still *everywhere*.

Correct. So it's trivial to do, and it future-proofs us to be able to
support EUI-64. ...

And the only reason we'd need to use EUI-64? Because some twits decided to use a Layer 2 address in a Layer 3 address. Or have we exhausted EUI-48 as well?

Most of the significant problems with IPv4 are due to people thinking
small, and not having a vision towards the future. ...

I'm thinking small? No. I'm being frugal and efficient -- "conservative". FORCING networks to be no smaller than /64 -- per the fundamental requirement for SLAAC -- when there's absolutely no forseeable need for 18billion billion hosts per network is wasteful beyond measure. I see this a fundamentally the same as handing out /8's 25 years ago -- "because the protocol (classfulness) requires it." Just because *we* see the IPv6 address space as unbelievablly huge *today*, doesn't mean we should carve it up in recklessly huge chunks. That's exactly how IPv4 was seen long ago, and we've been and will be living with that mistake for decades.

So, to sum up... we're being locked into using /64's as a minimum allocation simply because a fundamental part of IPv6 (SLAAC) requires an EUI-64 -- taking a layer-2 address and promoting it to a layer-3 address, more or less because it's there and supposed to be globally unique (read: we're lazy and don't want to figure out another way to be "stateless".) This despite no current internet devices using EUI-64[*], and the overwelming technology leader (ethernet) doesn't and very likely never will (given the millions of tons of existing hardware in use.)

([*] according to the wiki, firewire and zigbee are the only things using EUI-64. I don't know of anyone using firewire as a network backbone. (obviously, not that you care.) Zigbee is relatively new and similar to bluetooth; will people use them as a NIC or connect little zigbee gadgets to the internet -- well, there are coffee makers, vending machines, and christmas lights on the internet, so as a novelty, certainly. How many bluetooth devices are running IP over bluetooth? That said, I could see PAN meshes (personal area networks) eating a huge number of addresses, but /64???)

It was fixed 15 years ago, but not before more than half the space was "wasted". With IPv6 we can use current policy and only "waste" a /3 and then we can change policy and do something smarter if needed. This /3 will last us a long time and we have plenty of time to create something better than SLAAC.

It's time to deploy IPv6 *NOW* with what we have, not to start to change it in fundamental ways and delay deployment several more years by starting to change IPv6 stacks who are by now fairly mature.

Mikael Abrahamsson wrote:

That's exactly how IPv4 was seen long ago, and we've been and will be living with that mistake for decades.

It was fixed 15 years ago, but not before more than half the space was "wasted". With IPv6 we can use current policy and only "waste" a /3 and then we can change policy and do something smarter if needed. This /3 will last us a long time and we have plenty of time to create something better than SLAAC.

Fixing ipv4 didnt erase the pain of the brokeness.

Odds are it will be much much worse if that happens with ipv6.

Doing potentially stupid things now because we can fix it later isnt intelligent.

One potential problem scenario is larger proliferation of DFZ routes than would have otherwise been necessary - simultaneous with large scale ipv4 de-aggregation.

About 13% of ipv6 is assigned for addressing purposes.

According to IANA, the /3 is about 0.8% allocated and we already have 1700 ipv6 routes, which according to statistics is about 0.014% of the /3.

And we arent even using it for anything important yet, meaning something that could not be done over ipv4 internet or ipv4 vpn.

At this rate, the /3 will be full with about 12 million routes. That isnt far fetched assuming most corporations and other tech savvy users go with PI over the next 15-30 years.

Even if we can stick to roughly one prefix per AS, my best guesstimate is anywhere between 50-250k ipv6 routes until ipv4 routes start declining, depending on how long that takes.

Expecting organizations to renumber into larger assignments in order to keep overall prefixes low is an unrealistic hardship.

If the goal is to keep each organization to a single prefix, /48 per customer suggest a minimum allocation on the order of either /24 (16m customers, 2m per /3) or a /28 (1m customers, 34m in the /3) instead of a /32 (65k customers, 530m in the /3).

Are there any better numbers out there other than these hastily scribbled back of envelope ones?

I suppose the question is, are we building a system that can stand for decades or centuries?

Right now it seems to be optimizing for both.

Joe

([*] according to the wiki, firewire and zigbee are the only things using EUI-64. I don't know of anyone using firewire as a network backbone. (obviously, not that you care.) Zigbee is relatively new and similar to bluetooth; will people use them as a NIC or connect little zigbee gadgets to the internet -- well, there are coffee makers, vending machines, and christmas lights on the internet, so as a novelty, certainly. How many bluetooth devices are running IP over bluetooth? That said, I could see PAN meshes (personal area networks) eating a huge number of addresses, but /64???)

Utility companies utilize Zigbee pretty extensively. So that's millions and millions of addresses right there.

Charles Wyble wrote:

([*] according to the wiki, firewire and zigbee are the only things using EUI-64. I don't know of anyone using firewire as a network backbone. (obviously, not that you care.) Zigbee is relatively new and similar to bluetooth; will people use them as a NIC or connect little zigbee gadgets to the internet -- well, there are coffee makers, vending machines, and christmas lights on the internet, so as a novelty, certainly. How many bluetooth devices are running IP over bluetooth? That said, I could see PAN meshes (personal area networks) eating a huge number of addresses, but /64???)

Utility companies utilize Zigbee pretty extensively. So that's millions and millions of addresses right there.

A million addresses is 1/16th of one OUI in EUI-48, and there are 4,194,304 OUIs (after you take out the local/global and multicast/unicast bits). Billions or even trillions of addresses are manageable without needing EUI-64; millions is a drop in the bucket. Still, it's good to know that another link layer -- which people _will_ be running large IPv6 networks on -- is using EUI-64 and that it's not just a FireWire thing.

S

But does the entire planet need to talk to those critters? No. Nor should they even be able to.

Those little gadgets can very happily live within a link-local only network, or isolated private network.

I know the subject of "nat" in IPv6 will have people chasing me with pitchforks, but there are a lot of things in the world that don't need to be accessable by the entire world and should be (must be) protected from even accidentally being exposed to the Evil Internet(tm). Everyone will chime in with "firewall them", but the risk exists as long as they have global addresses. Having to break into a machine in order to get at the internal network (ala today's NAT) makes the network much safer -- not "safe", but safer than directly naked on the internet.

(If you want to do numbers... the utility company could hang 2billion zigbee's on every human on Earth and still not fill *one* /64. [global pop ~ 6.77 billion])

Ricky Beam wrote:

Utility companies utilize Zigbee pretty extensively. So that's millions and millions of addresses right there.

But does the entire planet need to talk to those critters? No. Nor should they even be able to.

Really.... we don't have enough debates going on in this thread?

Those little gadgets can very happily live within a link-local only network, or isolated private network.

Exactly. Behind the utilities (closely monitored and highly restrictive) firewall. Most likely behind multiple firewalls. (border fw, internal operations fw, monitoring network firewall). No reason they shouldn't have a fully routeable address.

I know the subject of "nat" in IPv6 will have people chasing me with pitchforks, but there are a lot of things in the world that don't need to be accessable by the entire world and should be (must be) protected from even accidentally being exposed to the Evil Internet(tm). Everyone will chime in with "firewall them", but the risk exists as long as they have global addresses. Having to break into a machine in order to get at the internal network (ala today's NAT) makes the network much safer -- not "safe", but safer than directly naked on the internet.

This is no different then having machines with a public IP on the net today. A firewall is such a small part of an overall security architecture.

Don't troll.