Where to buy Internet IP addresses

Mailman List Mirror (Read Only)
1

> When I came back, I found this ugly EUI-64 thing instead,
> so not only was autoconfiguration much uglier,
> but you needed a /56 instead of a /64 if you were going to subnet.
> Does anybody know why anybody thought it was a good idea
> to put the extra bits in the middle, or for IPv6 to adopt them?

"64bit MAC" -- which pretty much exists nowhere. It's a repeat of the
mistakes from IPv4's early days: CLASSFUL ROUTING.

Actually, that's exactly wrong.

It takes the good stuff from one of the failures of IPv4... CLASSFUL
ROUTING... and does it right:

Fundamentally, IPv4 got one part of it right with classful routing.
Giving service providers large blocks of space, large enough to allow
them to announce a single route out on the Internet. The problem is
that the address space wasn't really large enough to support this in
a sane manner, because growth wasn't predictable and mistakes would
result in waste.

IPv6 is *designed* for waste. You are *expected* to have vast realms
of completely unused IP(v6) addresses. So there is no damage to be had
by giving someone a delegation that's an order of magnitude too large,
and even giving someone a delegation that's an order of magnitude too
small is survivable without real problems. We can also delegate based
on much more distant projections.

Reducing the routing table size is one of the BEST ideas from classful
routing, it just didn't pan out because it was done as classful routing.

Now, we get a chance to learn from that mistake, and we can do it right.

Using a 64-bit MAC when most current MAC's are 48 is not a mistake. It
shows that someone somewhere had some vision towards the future.

I'm with you. I wish vendors and spec designers would just get over it
and let people subnet however they want. If I want to set a network to be
/96 or /120, I should be allowed to do so. Yes, I know autoconfig will
not work -- and I don't want it to.

You *can* do that. Nobody has said that it is impossible to set up an
interface with a /130-slash-/131 if you want a point to point.

But what we're talking about is service providers delegating to customers.
Customers should *also* be allowed to subnet "however they want."
Something they can't do right now, because they aren't given the space.
If service providers are allowed to delegate teeny prefixes (meaning /64
or less), we're going to see consumers finding "ways" around that
restriction, and then we're down an ugly road that's reminiscent of IPv4
and NAT and "you get one IP address, deal with it."

That should be avoided at all costs.

... JG

2

Joe Greco wrote:

But what we're talking about is service providers delegating to customers.
Customers should *also* be allowed to subnet "however they want." Something they can't do right now, because they aren't given the space. If service providers are allowed to delegate teeny prefixes (meaning /64
or less), we're going to see consumers finding "ways" around that restriction, and then we're down an ugly road that's reminiscent of IPv4 and NAT and "you get one IP address, deal with it."

Customers should also be able to implement multiple networks with support for stateless autoconfig. Doing away with NAT means new ways of handing out networks, which I believe the IETF has come short on, but the start is to accept that they'll need at least a /64 per layer two segment for compatibility reasons. Implementations will vary, as will the knowledge of the customer, but it is safe to assume at this point that there will be implementations with support for stateless autoconfig and multiple networks/subnets/etc.

Jack

3

If I'm allowed to subnet my single /64, then I'm still not using NAT. And as long as I don't go beyond /80, autoconfig can still work, at least on ethernet -- which is pretty much 99.999% of cases. (not that I advocate the use of autoconfig. *grin*)

4

Ricky Beam wrote:

If I'm allowed to subnet my single /64, then I'm still not using NAT. And as long as I don't go beyond /80, autoconfig can still work, at least on ethernet -- which is pretty much 99.999% of cases. (not that I advocate the use of autoconfig. *grin*)

Sorry, Ricky. But that won't work. EUI-64 is required for autoconfig, and it expands the 48 bits to 64 bits by inserting FFFF or FFFE depending on if the original is a MAC-48 or EUI-48 identifier.

That being said, you might be able to use stateless with tokens which can be less than 64 bits, though not sure how well implementations will handle stateless autoconfig with less than a /64. You can also use DHCPv6 with TA/NA addresses, though Cisco doesn't support those options in their IOS implementation at this time, open source DHCPv6 servers do. You can also backup to static assignments.

Jack

5

I think Ricky's point is that he could do autoconfig in a /80 as long as there
isn't the semi-gratuitous MAC-48->EUI-64 expansion.

6

Is there an implementation of autoconfig that doesn't do the expansion? I haven't tested it, but I'm not even sure that autoconfig would work with a token using a smaller than /64 prefix. It may work, but it's definitely outside the standard and would be implementation specific.

Jack

7

"On paper" :slight_smile: There's no technological reason why the 48bit MAC wouldn't be enough on it's own. Tacking on an extra (fixed) 16bit value doesn't make it any more unique. Doing so also would not add any level of complexity to address determination -- it's still a simple concat.

Show of hands. How many people have massive firewire based IP networks? *crickets* Right. (I've used ip1394 like twice in over a decade... a file transfer between a laptop and desktop.)

8

* Jack Bates:

Sorry, Ricky. But that won't work. EUI-64 is required for autoconfig,
and it expands the 48 bits to 64 bits by inserting FFFF or FFFE
depending on if the original is a MAC-48 or EUI-48 identifier.

I'm rather puzzled why this blatant layering violation is still sold
as a must-have feature.

9

Florian Weimer wrote:

* Jack Bates:

Sorry, Ricky. But that won't work. EUI-64 is required for autoconfig,
and it expands the 48 bits to 64 bits by inserting FFFF or FFFE
depending on if the original is a MAC-48 or EUI-48 identifier.

I'm rather puzzled why this blatant layering violation is still sold
as a must-have feature.

It's not a must have if you manage your own network. There are always other options. That being said, if you are an ISP handing out prefixes to customers, there is an expectation that the customer will probably use it given the direction CPE implementations are going. Thus you have to predict that if you don't want to setup all your customer's networks for them, they'll probably be using /64 per subnet.

Jack