Where to buy Internet IP addresses

Mailman List Mirror (Read Only)
1

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

No, thinking small is what landed us in the current IPv4 pain.

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

No, it's not too late to make simple changes. We're still figuring out
lots of bits about it.

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

Yes, I do think that something fundamental like that will happen at some
point.

On the other hand, can you *guarantee* that it will not? Because if you
cannot *guarantee* that it will not, then that raises doubts as to the
wisdom of your advice. And quite frankly, you've already conceded that
a technology - firewire - exists that does use EUI-64.

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

Do you have an equally brilliant but completely different suggestion as to
how to implement reliable stateless autoconfig in IPv6?

But it's not the only reason we need to use EUI-64. We know that someday,
even if it's many years out, we'll run out. And further, I believe that
the rate of depletion will only increase, as the number of network-capable
devices explodes.

Or have we exhausted EUI-48
as well?

No. Do we have to do that before we figure out what to do next?

Are we too stupid to learn from the period of history we're going
through right now? With IPv4, we've waited until we're just about
out in order to figure out where to go from here. That was dumb.
Predictable but dumb. Why wait for resource depletion in another
realm, when we already know that's a bad thing to do?

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

Yes, that's thinking small, because IPv6 was *designed* to be liberal.
Intentionally. By massive amounts, so that no credible claims could be
mounted that there was any good reason for "being [excessively] frugal."

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.

RFC3041. That's a need. It works today. It's implemented on FreeBSD,
Linux, and Microsoft stacks, among others. We just went through an
educational process with the DNS protocol to learn why the ability to do
this sort of thing is a completely credible "need", as well. So I'm
sorry to say, but you're just wrong, that's a need, and it's there now.

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.

You don't think that the IPv6 designers thought long and hard on that very
question? You're second-guessing them? I'm sure we'd all appreciate a
presentation as to why 128 bits isn't enough. Really, if it's a problem,
now is the time to decide to go to 256 bits and IPvX.

These are huge numbers that we're talking about. At the time IPv4 was
created, people were looking at 4 billion and refrigerator-sized routers
and thinking, "this'll last us for a while." And it did. But I don't
recall them assuming that IPv4 was the end of the road.

With IPv6, we've made some very clear decisions about what we need to last
us for a while. One of the most visionary things we've done is to set
aside a huge space for local network addressing. This leaves us with a
huge amount of space to work with in the future, if, for whatever reason,
the current ideas don't pan out.

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".)

You're not being locked into it. Nobody's forcing you to use it. I'm
sure that you can find someone willing to delegate you a single /64 for
you to subnet along the lines of the traditional IPv4 ways.

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.

They have to use it as a network backbone? Why, exactly?

It has to be a technology that we are using today? We're not allowed to
look at the way technology has developed and extrapolate that we might
have many, many more uses, new technologies, and needs in the future?

Hey, you know what, I'm just going to say this.

Your thinking is definitely small-scale. There is nothing in IPv6 that
prevents you from making a network work on the teeny scale. However, if
we were to deploy your ideas IPv6-wide, then those of us who can think
on the grand scale would find ourselves shortchanged for no good reason.

Therefore, IPv6 deployment needs to continue in the way it was designed
and envisioned, so that you are able to do your thing, and I am able to
do mine.

HTH, HAND, etc. I'm out of here.

... JG

2

No, it's not too late to make simple changes. We're still figuring out
lots of bits about it.

Yes, it is too late. IPv6 as it stands is a huge pile of crap and bloat. We'd be better off straping the whole mess and starting over, but that ain't gonna happen. Over the next dozen decades and hundreds of RFCs, we might have something that looks like it was designed by competent people instead of glued together mess we have today that was created by committees with multiple personal and political agendas.

On the other hand, can you *guarantee* that it will not?

Yes. Yes, I can. Ethernet has been around for decades from 10M to 100M to 1G to 10G and now we're working on 100G. Look around the room and count the number of devices containing ethernet technology. It's f'ing EVERY. WHERE. Every single piece will have to be replaced to support EUI-64. It's grown into the silicon, so there's no amount of software updates that can fix it like we're attempting to do with IPv4-to-IPv6.

And quite frankly, you've already conceded that
a technology - firewire - exists that does use EUI-64.

True. But you ignore the fact that firewire isn't used as an internet transport technology. Where's the 24 or 48 port firewire switches? You can run IP over fibre channel, but I don't know of anyone who does so outside of private (read: internal) networks. (Clusters often use FC-IP within the SAN for node-to-node signaling.)

Ethernet won. It uses 48bit addressing. It's not going to change. That "mistake" is now cast in diamond. The world is not going to throw away all the ethernet gear because someone wants to change the addressing scheme.

Do you have an equally brilliant but completely different suggestion as to how to implement reliable stateless autoconfig in IPv6?

Sure I do. And I'm not the only one. In fact, many IPv4 systems have an address generator... the thing that builds "local" 169 addresses.

The simple fact is they took the dirty, brainless simple path of using what is supposed to be a unique identifier (Layer-2's MAC-48) and directly attching it to the layer-3 (IPv6) address. Everyone is confusing "stateless" with "constant" and "consistent". SLAAC doesn't need to generate the exact same address everytime the system is started. Stateless simply implies a host is not depending on data maintained from an external source. A host can generate whatever random number it needs. It doesn't have to be *globally* unique; it only need be *locally* unique. There are plenty of ways to generate and verify local uniqueness.

No. Do we have to do that before we figure out what to do next?

Do we have to replace trillions of dollars in hardware because of a problem we don't have?

Are we too stupid to learn from the period of history we're going
through right now? With IPv4, we've waited until we're just about
out in order to figure out where to go from here. That was dumb.
Predictable but dumb. Why wait for resource depletion in another
realm, when we already know that's a bad thing to do?

You must be new here. IPv6 was designed a long time ago. Long before we "ran out of addresses". Nobody has deployed it because nobody has deployed it. IPv4 works. We still have address space to hand out -- and will for several more years. IPv4 will *continue* to work long after IANA has no more blocks to assign.

Bottom line... there's no pressing reason to make the jump, and a whole bunch of reasons to hold off. But you don't seem to care about any of that -- we should all continue driving our pintos with the exploding gas tank until your local shop has time to replace it. No. Thanks.

RFC3041.

Ah, so you conceed there *are* ways to generate addresses that aren't the MAC address. Therefore, they don't have to be 64bits. However, it's easier to be unique with larger numbers.

You don't think that the IPv6 designers thought long and hard on that very question? You're second-guessing them? I'm sure we'd all appreciate a
presentation as to why 128 bits isn't enough.

I'm not guessing at all. I know they didn't. And where the f*** have I ever said 128bit isn't enough. My whole issue is with forcing people into 0% utilization of their address space "because we have lots of address space" and "eventually we'll need that space." Yet, you seem to think we're justified in giving people billions upon billions upon billions of addresses because we might, someday, somehow, have millions of gadgets that need to be globally addressable. But that's completely different from the mess we have with IPv4... handing out /8's because we could, then throwing on the breaks and promoting (even demanding) "responsible use", all the way to today where everyone asks for more address space than they currently need because "we might need it later" but later never comes.

128bit addressing is uber-plenty and will last us a long time as long as we continue to practice "responsible use".

These are huge numbers that we're talking about. At the time IPv4 was
created, people were looking at 4 billion and refrigerator-sized routers
and thinking, "this'll last us for a while." And it did. But I don't
recall them assuming that IPv4 was the end of the road.

And you don't see the repeat with IPv6? *sigh* I see it everywhere... the address space is *HUGE*. there's no way we'll ever use it all. "enough addresses to assign every grain of sand on the planet it's very own..." But yet, day one we slice the address space in half and place a "globally unique" (probablly) number in the lower half. And then propose slicing the uper half into chunks large enough to give every house 256 to 65,536 *individual* globally unique spaces.

You're not being locked into it. Nobody's forcing you to use it. I'm
sure that you can find someone willing to delegate you a single /64 for
you to subnet along the lines of the traditional IPv4 ways.

Yes, we all are. We will all be given a minimum of a /64, while no one has a need for even a billionth of that space, and aren't likely to for the forseeable future. When they do, *then* give them the space they need. Ah, but "renumbering is a pain", you say. That's another of those IPv6 fundamentals... renumbering your network is supposed to be easy -- prefix delegation and autoconfig makes it all Magic(tm).

3

Ricky Beam wrote:

Yes, we all are. We will all be given a minimum of a /64, while no one has a need for even a billionth of that space, and aren't likely to for the forseeable future. When they do, *then* give them the space they need. Ah, but "renumbering is a pain", you say. That's another of those IPv6 fundamentals... renumbering your network is supposed to be easy -- prefix delegation and autoconfig makes it all Magic(tm).

Actually, they probably would have stuck to a 64 bit address space and it was debated. Then it came down to, let's make it a 64 bit network space, and give another 64 bits for hosts (96 bits probably would have worked, but someone apparently feels the next bump from 64bit is 128bit so there we go).

Renumbering, when the system works is a breeze. Of course there are a billion places where autoconfiguration doesn't work well, and those will still require effort to renumber.

At least with this method, if Cisco supports DHCPv6 IA_TA option and proxy-nd similar to how they support IPv4, then a single pool will handle an entire pop no matter what. I'm sure 32bit host addressing would have been fine too, but then we're stuck with that 96bit value that no one likes.

Jack

4

Ah, but they half-assed the solution. IPv6 makes no distinction between network and host (eg. "classless"), yet SLAAC forces this oddball, classful boundry. Routing doesn't care. Even the hosts don't care. Only the tiny craplet of autoconfig demands the network and host each be 64bits. That's brilliant!

5

I would venture a guess that there are atleast two divergent opinions here that will "never" be reconciled. I propose you agree to disagree and move forward ... or take the argument back in time about 15 years, when these issues were being debated and solutions (great, good, mediocre, bad - efficient, wasteful - constraining, freeing ... whatever) were decided upon.

/TJ ... Also thinking the level of vitriol is a bit counter-productive, but this is the Internet ...

6

Ricky Beam wrote:

Ah, but they half-assed the solution. IPv6 makes no distinction between network and host (eg. "classless"), yet SLAAC forces this oddball, classful boundry. Routing doesn't care. Even the hosts don't care. Only the tiny craplet of autoconfig demands the network and host each be 64bits. That's brilliant!

So ask the IETF to drop it to generic 32bits. I presume they can draw up mathematical formulas to show that 32 bits can autogen and avoid a conflict with the maximum number of IPs likely to be found on a segment without having to do excessive DAD requests. Of course, they'll have to obsolete the 64 bit model and I suspect the vendors will complain about it.

Jack

7

"stateless" with "constant" and "consistent". SLAAC doesn't need to
generate the exact same address everytime the system is started.

No - but it is *phenomenally useful* if it does. Changing addresses is
only ever something you want in very specific circumstances.

Bottom line... there's no pressing reason to make the jump, and a whole
bunch of reasons to hold off. But you don't seem to care about any of
that -- we should all continue driving our pintos with the exploding gas
tank until your local shop has time to replace it. No. Thanks.

Wow, that's a metaphor that has been not merely mixed, but shaken and
stirred as well. Are you for a move to IPv6 now or not? Is the Pinto
IPv4 or IPv6? What does the exploding gas tank represent?

If you mean we should hold off on moving to IPv6, then I disagree
strongly. Here's a quote I like (because it's mine :slight_smile:

   "[...] the storm clouds have well and truly gathered,
    thunder is rolling in the hills, great big rain drops are splotting
    into the dust all around us, and what are we doing? Wandering around
    the outside of the Ark tut-tutting about the quality of the woodwork
    and loudly suggesting the construction of various sorts of
    rowboats."

For what it's worth, I actually agree with you that 64 bits is way too
short a prefix for the job. 80 would have been better, and some
framework for *choosing* the prefix length and (say) hashing the MAC
would have been even better. As it does you, the waste offends me,
because I DO think we are repeating an IPv4 mistake.

On the other hand - we have DHCPv6 to work around it. Noone HAS to use
SLAAC. DHCPv4 is in every piece of home kit these days, with useful
defaults, there's no show-stopper reason that DHCPv6 cannot do the same
job. With a bit of work it could do a much better job.

Regards, K.

8

pretty much every time the node moves in/across networks.
  if the node doesn't move, it keeps the same address.

--bill

9

Wow, that's a metaphor that has been not merely mixed, but shaken and
stirred as well. Are you for a move to IPv6 now or not? Is the Pinto
IPv4 or IPv6? What does the exploding gas tank represent?

I'm complaining that the IPv6 we're all being asked to use is a buggy contraption that's best parked until more of it's issues are resolved. Once we start down the path capable of supporting SLAAC's /64 requirement, there's no going back. The address space has be carved out; there's no "uncutting" that pie. (much in the same way the /8 handed out in the early 80's aren't being reclaimed.)

If you mean we should hold off on moving to IPv6, then I disagree
strongly. Here's a quote I like (because it's mine :slight_smile:

The flood hasn't started yet. And the ark isn't finished; with enough people bailing water, it might stay afloat. :slight_smile:

On the other hand - we have DHCPv6 to work around it. Noone HAS to use
SLAAC. ...

Yes, but as long as it exists, someone *will*.

10

Ricky Beam wrote:

11

I'm complaining that the IPv6 we're all being asked to use is a buggy
contraption that's best parked until more of it's issues are resolved.

Using it is the fastest way to get issues resolved. It worked for
IPv4... :slight_smile:

Expecting all the issues to be fixed before we start using it is the
best way of all to ensure that it never gets off the ground at all. It's
an excuse, and not a very good one.
   

Once we start down the path capable of supporting SLAAC's /64 requirement,
there's no going back. The address space has be carved out; there's no
"uncutting" that pie.

I disagree. I can see several ways to retrofit more and better
functionality in this area later.

The flood hasn't started yet. And the ark isn't finished; with enough
people bailing water, it might stay afloat. :slight_smile:

Hm, like the fellow falling out of a tall building. As he flashed past
each window on his way down, people on each floor heard him murmuring
"so far so good...".

Look, the Ark *is* finished. It floats. It can be steered. It has space
for everyone. The fact that some of the plumbing is a bit iffy is just
not a major issue right now; getting everybody on board is. We have LOTS
of very clever people ready to bail, many of whom are quite capable of
inventing bilge pumps from scratch.

Sure the flood hasn't started. The fact that we are up to our ankles in
water is a purely temporary phenomenon, nothing to worry about.

Regards, K.

12

The address space has be carved out;
there's no "uncutting" that pie. (much in the same way the /8 handed out
in the early 80's aren't being reclaimed.)

I believe Net 14 has been.

Please do note that a /8 is being eaten every month by
todays consumption rate.

The flood hasn't started yet. And the ark isn't finished; with enough
people bailing water, it might stay afloat. :slight_smile:

My feet are humid... Not from Python boots.

13

You'll love RFC 4941 as implemented by Windows Vista and later.

Tony.

14

Of course, the builders used screen doors and windows for the below-the-waterline openings, but not to worry, the bilge pump equivalent of Moore's Law will undoubtedly save us.

Regards,
-drc

15

The fact that MS chose to use that as the default with Vista is odd, and
I think a bad choice, but RFC4941 is not a bad thing in itself. It is an
alternative that makes good sense in some contexts - but not, I think,
in most contexts.

And it's easy enough to turn off. XP uses temporary addresses too, also
easy to turn off.

Regards, K.

16

> > "stateless" with "constant" and "consistent". SLAAC doesn't need
> > to generate the exact same address everytime the system is started.
>
> No - but it is *phenomenally useful* if it does. Changing addresses
> is only ever something you want in very specific circumstances.

You'll love RFC 4941 as implemented by Windows Vista and later.

The fact that MS chose to use that as the default with Vista is odd, and I
think a bad choice, but RFC4941 is not a bad thing in itself. It is an
alternative that makes good sense in some contexts - but not, I think, in

most

contexts.

While I was initially inclined to agree, operating this way does allow some
interesting capabilities - and I would be very interested in hearing from
someone @MS as to their thinking behind this decision.

/TJ

17

Speaking as a builder, I have to say the screen doors were on the
plans when I got there. I gather the planners believed they would
facillitate use of the ark by hybrid human-acquatic lifeforms that did
not exist at the time, nor do they exist today, but were hoped to
exist because mermaids and mermen are, like, totally hot.

18

Their awful experimental IPv6 stack in XP already does 3041, so I assume Vista, 2008, and 7 all do the same. In the XP case, it's not very agressive in rotating addresses.

19

No - but it is *phenomenally useful* if it does. Changing addresses
is only ever something you want in very specific circumstances.

You'll love RFC 4941 as implemented by Windows Vista and later.

Their awful experimental IPv6 stack in XP already does 3041, so I assume

Vista,

2008, and 7 all do the same. In the XP case, it's not very agressive in
rotating addresses.

Nope, different.
No EUI64 at all - goes straight to randomized IIDs, but (cough) not to be
confused with Temporary/Privacy IIDs.
Randomized Link-local, randomized non-link local (Site|UniqueLocal|Global).

FWIW - WinXP uses 24hours/change_in_prefix/reboot as the default criteria
for new Privacy IID creation, is that not aggressive enough?
  I'd be curious to know what makes it "awful" IYO, I use it daily and
have few complaints ... ?

(I think the bigger / better complaint against WinXP is the lack of
IPv6-transport support for DNS ... and perhaps the lack of DHCPv6 client
functionality as well)

/TJ

20

FWIW - WinXP uses 24hours/change_in_prefix/reboot as the default criteria
for new Privacy IID creation, is that not aggressive enough?

I define that as "not aggressive". (I've seen ISPs rotate addresses (DHCP) faster than that.)

  I'd be curious to know what makes it "awful" IYO, I use it daily and
have few complaints ... ?

Where's the GUI for dealing with it? It's Windows(tm) after all.

And it brings along a few other things we didn't ask for... a Toredo(?) tunnel interface, for one.

But yes, it is functional. It'll get you to the small assortment of ipv6 websites around.

(I think the bigger / better complaint against WinXP is the lack of
IPv6-transport support for DNS ... and perhaps the lack of DHCPv6 client
functionality as well)

Yes, but those things require more than just an IPv6 stack. Service components have to be changed to handle DNSv6 and DHCPv6.