Waste of IPs? or shrewed method to collect IP space?

[eonesixfour]

Not to seem ungrateful and what not but I can't help but think that a /64 for a Point to Point link and a /48 for what most people only need a /64 at most for is a little wasteful, although I can see how on the other hand this would give he.net a massive amount of IP space which would drop off as ISPs and colo places start allocating native IP space so hmmm....

[testmonster]

Believe it or not, you have that slightly backwards,

RFC 3177 recommends the assignment of a /48 unless it is known in advance that additional /64s will never be needed.

Hurricane currently only allocates /48s to tunnel users that request it by clicking the allocate /48 button.

[eonesixfour]

Ok so HE is doing the right thing for all intents and purposes, it's just a case of those that came up with IPv6 did another stupid thing *sigh*

This along with the /64 per subnet which is also stupid, there is really no need for more then /112 at most since thats about when a lot of switches tend to start hitting MAC limits, obviously this can be increased but for most home users is there a real need, I doubt it.

In fact a /120 or less would be far better, especially now that DHCPv6 software is available, when I last seriously played with IPv6 a few years ago it wasn't.

The reason I'm suggesting this of course is because I don't want to end up where we are now with IPv6 needing to move to IPv8 or whatever they come up with next just because there is a shortage of IP space due to stupid allocation ideas of the people designing these things not living in the real world.

If things were issued on a /128 basis for the PtP and then a /120 issued a single /64 alone would support 36,028,797,018,963,968 tunnels + routed subnets.

The way things are currently going, if every server today that has at least 1 IPv4 address was allocated a /64 and on top of that every home network getting a /64 to the router and a /48 how long before they start talking about us running about of IPv6 addresses?

I haven't done the math but at the current estimated rate IPv4 addresses are being consumed, IPv6 addresses would be gone in a similar time frame.

[eonesixfour]

Oh and if it's not a waste of IPs, I wonder how many privacy concerns were addressed when the brilliant person thought up to send the MAC address  as the IP, I'm surprised the EFF or similar organisation hasn't made a fuss over this considering how much of a fuss has been made over tracking cookies and this seems much worst.

[snarked]

I hear what you're saying, but as noted above, the current BCP from the RFCs disagrees with you.  IANA issues /12's (originally, /23's) to the registries which in turn issue /32's and /48's to individual service providers (depending on their type), and they in general issue /64's to the end users.  IPv6 autoconfiguration requires that the host be on a /64 network, since what it configures is the lower 64 bits; 48 of which come from the MAC address.  Is it wasteful?  Yes.  However, the practice is Internet-wide.  Allocations no longer in use can be returned to the registries.

As for HE, I don't really see the purpose in allocating TWO /64's just to have one that has an X::1 and X::2 that simply ping each other to make certain the tunnel still works (effectively a /126).  A better plan would have been to allocate a single /64 and simply require that the X::1 on the customer's end of the tunnel respond to pings from HE's tunnel server(s).  That shouldn't be a problem since at a minimum, HE's IPv6 subnet of 2001:470::/32 should be routed over the tunnel anyway (if not ::/0, 2000::/3, or other subnet greater than /32 inclusive of it).  As to the additional /48 allocation available here, I consider that a personal choice.

Remember that even with any tunnel, one can additionally use the 6to4 mechanism - and should have the 2002::/16 route sent to the primary IPv6-encapsulation interface.  With Linux, I've seen the source code that will auto-extract the IPv4 component of such addresses and auto-tunnel the packets to the appropriate host.  I don't know if KAME-based IPv6 stacks have that encoded or not (e.g. freeBSD). Sending 6to4 over a different IPv6 tunnel from a dual-stacked host is "taking the long way around."  However, as 6to4 along with the IPv6 tunnel service here and elsewhere are transition mechanisms, in a purely native IPv6 Internet, they will eventually disappear.

As far as DHCPv6 is concerned, part of the original plan for IPv6 is that such would be unnecessary.  IPv6 is meant to be "big brother's dream" - everything wired to everything else all the time.

[eonesixfour]

the current BCP from the RFCs disagrees with you.

No, I just disagree with it ;)

Is it wasteful?  Yes.  However, the practice is Internet-wide.  Allocations no longer in use can be returned to the registries.

APNIC used to hand out /35s but you can upgrade to a /32 for free!

As for HE, I don't really see the purpose in allocating TWO /64's just to have one that has an X::1 and X::2 that simply ping each other to make certain the tunnel still works (effectively a /126).

Erm don't you mean 1 /64 for the PtP ? At least that's the only allocation I'm aware of and currently abusing ;)

You really only need a /128 for the PtP connection, I also thought you needed network/broadcast yesterday then I remembered they did away with them in IPv6.

of 2001:470::/32 should be routed over the tunnel anyway (if not ::/0, 2000::/3, or other subnet greater than /32

It's been a while since I played with IPv6 serious (2002 or there abouts), back then we were only supposed route 2000::/3 not ::/0 has something changed or are people just being lazy and routing everything when they shouldn't be?

I vaguely recall the ::/0 shouldn't be routed because it contained multicast space as well as unicast.

Remember that even with any tunnel, one can additionally use the 6to4 mechanism - and should have the 2002::/16 route sent to the primary IPv6-encapsulation interface.  With Linux, I've seen the source code that will auto-extract the IPv4 component of such addresses and auto-tunnel the packets to the appropriate host.  I don't know if KAME-based IPv6 stacks have that encoded or not (e.g. freeBSD). Sending 6to4 over a different IPv6 tunnel from a dual-stacked host is "taking the long way around."  However, as 6to4 along with the IPv6 tunnel service here and elsewhere are transition mechanisms, in a purely native IPv6 Internet, they will eventually disappear.

Ok now you've got me, I'm using linux but I'm not entirely sure what you're talking about here.

As far as DHCPv6 is concerned, part of the original plan for IPv6 is that such would be unnecessary.  IPv6 is meant to be "big brother's dream" - everything wired to everything else all the time.

Yes and I have a nice pair of 240v wires here big brother can stick up his you know what ;)

[karlbrose]

Before you call the world "stupid" you really should read the specs first and try to understand the new addressing system and its philosophy, unless you want to raise questions as to your own caliber.

And as to the prospect of running out of IP addresses again: the potential size of the new allocation space (/64) is the SQUARE of the old IPv4 Internet, with each allocation of the potential size of the SQUARE of the size of old Internet. This, if you look at the address space through IPv4 glasses.

[karlbrose]

The issue of what is "enough" is not part of the IPv6 philosophy or concern anymore. It's irrelevant. Think of it as a UUID for addressing.
Enterprise or local domain subnetting is finally gone. Every subnet is a 2^64 address space. This eliminates any or perhaps most needs for renumbering. Change of upstream provider (prefix) can be almost automatically handled by advertising the prefix.
The /64 allocation prefix space alone is large enough to give every soul in the milky way an address space of many times the current Internet for the next few billion years.
The vastness of the space of the IPv6 Internet as a whole and likely empty (smaller) vastness between active IP addresses makes port scanning over sections of the Internet unfeasible and security by obscurity may be possible.

[eonesixfour]

Before you call the world "stupid" you really should read the specs first and try to understand the new addressing system and its philosophy, unless you want to raise questions as to your own caliber.

Perhaps I could have been a little more careful with my words, but at the same time it just seems silly to make such a large IP space and then turn round and be so libral with it.

And as to the prospect of running out of IP addresses again: the potential size of the new allocation space (/64) is the SQUARE of the old IPv4 Internet, with each allocation of the potential size of the SQUARE of the size of old Internet. This, if you look at the address space through IPv4 glasses.

The amount of IPs wasn't my entire argument, I just wasn't able to conscisely put it any better.

[eonesixfour]

at the moment I'm splitting my /64 into /96's so each vlan has as much space as the IPv4 internet

I might up to a /48 just to try autoconfig

You technically don't need to, I'll probably get shot for saying this, but if you set the 6to4 tunnel IP to xxxx::2/128 you can use xxxx::3/64 on the lan interface. This works because the /128 is more specific it will override the /64 route.

although if I was the IETF I'd issue many a /120 as that would have one IPv4 octet of space and thats more than enough for most
and use a /128 for the tunnels or /120 and have all users of a tunnel end-point use the same /120 for the ptp and a differant /120 for their side of their end as well as offer multiple /120's per tunnel in case of vlans and a /104 in case of companies that use a 10.x.x.x scheme for easy transition

that would be a direct fix for the current IPv4 issue as people aren't running low on lan private addesses just on public addesses as well as take care of Mars networking (when that happens) (maybe some web cam sats of mars) (that would be cool)

If only they had had the foresight to include a backward compatability, but alas they didn't.

[eonesixfour]

Enterprise or local domain subnetting is finally gone. Every subnet is a 2^64 address space. This eliminates any or perhaps most needs for renumbering. Change of upstream provider (prefix) can be almost automatically handled by advertising the prefix.

LANs technically only need 2^48 bits of space, and since you can't duplicate the same MAC on the same LAN I'm still left wondering if they really can justify the extra 16 bits for padding. I fail to see how a change of upstream provider is going to be fun, we were all promised portable subnets but like they were ever going to come good on that one, in any case this is going to be as much work if not more then renumbering IPv4 subnets, especially when you start getting into DNS etc.

The /64 allocation prefix space alone is large enough to give every soul in the milky way an address space of many times the current Internet for the next few billion years.
The vastness of the space of the IPv6 Internet as a whole and likely empty (smaller) vastness between active IP addresses makes port scanning over sections of the Internet unfeasible and security by obscurity may be possible.

Actually IPv6 doesn't handle the latency of space apparently, I remember from a few years ago of talk about IPv8 being designed to deal with it over inter-planetary distances.

[eonesixfour]

I forgot to include it in my replies but anything that currently have a IPv4 address will end up with a /48, it's only things that only have NAT IPs now that are likely to only get /64's

[ntmatter]

The /64 allocation prefix space alone is large enough to give every soul in the milky way an address space of many times the current Internet for the next few billion years.
The vastness of the space of the IPv6 Internet as a whole and likely empty (smaller) vastness between active IP addresses makes port scanning over sections of the Internet unfeasible and security by obscurity may be possible.

Actually IPv6 doesn't handle the latency of space apparently, I remember from a few years ago of talk about IPv8 being designed to deal with it over inter-planetary distances.

Gotta wonder what an intergalactic IPvX would look like. On its own, IPv6 is a stateless protocol whose only concern is transmitting packets from A to B. On those grounds, IPv6 can function without modification. After all, RFC 1149 was successfully implemented, but the round-trip ping times were enormous. The same concept would be applicable distances on the scale of thousands of light years -- your packets would arrive eventually. In fact, even using Faster-Than-Light communication channels, IPv6 wouldn't care if your packets arrived before they were sent. (10 points to anyone who can come up with a suitably interesting ::1 loopback paradox)

The one place that I can see IPv6 having troubles is when the transmission time starts to exceed device lifetime. If DHCPv6 has not seen sufficient adoption by the time that humans have colonized the galaxy, it will be necessary to rely soley on stateless autoconfiguration. As such, it is possible that known addresses could expire while payloads are in transit.

To combat the effects of the (comparatively) shrinking lifetime of available IPv6 addresses, I would propose a means for associating an IPv6 Network address from a particular time period with its current address, and then translating incoming packets to their current network address.

Thanks to the novel structure and arrangement of the IPv6 space, the process of translating network addresseses temporally (or TNAT for short) becomes a simple one. Most assumedly, the few colonized distant worlds would have their own top-level prefixes (at least they'll get their own /48 if they sign up for a tunnel here) which can be used to imply the total path distance to the known point of origin. (eg, 2001:: belongs to Earth, which is exactly 3.14159 light years away. The IPv6 address at this location at LOCALTIME - 3.14159 years was XYZ, which has since been updated to the new hostname, ZYX. *PACKET MANGLING!!* and *CONTINUE ROUTING*). This conveniently side-steps the need to determine total RTT by classical means such as an ICMP ECHO packet, which may produce unexpected results due to changes in network topology and reciever position that could occur during transit.

So, as aforementioned, IPv6 is the logical choice for our future space-colonization needs. The real changes will need to occur in the higher-level protocols and endpoint hardware. For example, stateful protocols such as TCP will need to be reworked to support larger window sizes (30 years can mean a lot of in-flight data) and HTTP session cookies will have to deal with longer lifetimes. Out-of-order packet delivery due to FTL transmission may also cause difficulty when streaming internet radio. This in itself may be a strong reason to implement Multicast support on an interstellar network.

The good news is that this solution can be implemented with modern hardware and software, with minimal restructuring. By simply replacing parts of the TCP stack with a relational database and medium-sized SAN, we can meet the needs of the future with yesterday's technology today...so let's get started! :)

[melbeckman]

Spaceman Bob walks the gangtube from Inter-Planetary Vehicle 4 to the lobby of the Mature Astronaut's Leisure Village, following his first ever earth landing. Born in space, Bob spent his entire life shuttling charcoal among the colonies, where carbon is in short supply. He's looking forward to a well-earned retirement.

Bob checks in and is shown to his room, where the bellbeing demonstrates various accoutrements of his new abode. Eventually they tour the well-appointed bathroom.

"And here you have, of course, a sink and shower. Unlike your time on IPV4, I think you'll be quite pleased to be free of water ration worries!" beams the bellbeing.

"Free?" queries Bob. "What does freedom have to do with common sense? Just because there is more water here, I don't think we should go wasting it. Where's the water gun, by the way?"

"Ah, water gun? I don't..."

"You know, for metering water into food pouches, bathing sponges, and the like."

"Well, as I said, we don't really do rationing here.  For cooking water, just run as much out of any faucet as you like. The shower can give you plenty of water for bathing -- no sponge baths necessary. No limits, really, except during drought conditions, when you might be asked to hold consumption to a thousand liters or so a day."

"A thousand liters a day! Are you daft, man? What could anyone possibly do with a kiloliter of water every day? I doubt I use that much in a year! This waste mentality is heretical! You won't find me consuming so much as a liter a day, let alone a kilo. I'm very conserative."

"Well, yes, I appreciate that. Admirable. But there isn't really any need..."

"I'm not an idiot. Of course there's no immediate need, but what if there's a hull breach and you lose your H2O store? Or if the population -- which I understand is growing prodigiously -- jumps to the point where water runs out? You'll wish you had conserved then, by golly!"

"Um, the hull, there really isn't... And earth ecology recycles water continuously; we can't really run out. I think perhaps the differences in scale between IPV4 and your new home aren't immediately obvious. You see we have..."

"Shut up! Shut up you ninny! I've lived under the harshest conditions, survived disasters and contingencies you've never even imagined. I know resource gluttony when I see it. It's a capital offense in the civilized world. The morons who thought up this wasteful, stupid system should be thrown in prison! Now, where's my oxygen pack? There could be a pressurization fault, you know..."

[snarked]

On account of extended RTT, IPv6 (or IPv4) isn't practical outside of the proximity of Earth (including satellites in orbit and the Moon).  Mars, at its closest, is about 12 minutes one-way.  A 24 minute RTT (1840 seconds plus) won't work.

Any interplanetary protocol must have forward error correction and not require acknowledgment of individual packets or session parts.  We will have gateways to interplanetary nodes, but their transmissions away from Earth will not be part of IPv6.

Enough of this foolishness.