×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Akamai To Offer IPv6 To All In April

Unknown Lamer posted about 2 years ago | from the lolcats-over-ipv6 dept.

Networking 110

netbuzz writes "Akamai says that it will offer IPv6 services to its entire customer base beginning next month – a long-awaited move that is expected to be a major boon to the adoption rate of the next-generation Internet Protocol. Akamai hoped to release its production-grade IPv6 services by the end of 2011, but the task proved more difficult than originally anticipated. Akamai has been beta testing its IPv6 services with key customers since last fall."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

110 comments

Probably still waiting for their security software (4, Interesting)

BagOBones (574735) | about 2 years ago | (#39479535)

Based on my own company checks for readiness I assume the big hold up feature parody with IP4 and IP6 security software and equipment.

I know many of our security appliances have been able to route IP6 for a long time, but few of them could filter or manage the traffic with any sort of detail close to that of IP4 since the features had not been ported.

Re:Probably still waiting for their security softw (1, Funny)

Anonymous Coward | about 2 years ago | (#39479631)

Fuck IPV6. Can't we just have a 36-bit or 48-bit IPV4 and keep everything else the same?

Think IPv4 PAE.

Re:Probably still waiting for their security softw (4, Informative)

mattventura (1408229) | about 2 years ago | (#39479743)

How would it be any better? You still would have to replace equipment and software in order to support it. Most high-end equipment uses ASICs for routing, so you wouldn't be able to just do software upgrades to support it.

Re:Probably still waiting for their security softw (1)

Anonymous Coward | about 2 years ago | (#39480697)

True, but high-end equipment has been able to run IPv6 for ages now.

Re:Probably still waiting for their security softw (1)

Anonymous Coward | about 2 years ago | (#39480635)

No, that would require every OS to replace the TCP/IP stack. No backwards compatibility and no better off than IPv6.

Re:Probably still waiting for their security softw (1)

Daniel Phillips (238627) | about 2 years ago | (#39481573)

No, that would require every OS to replace the TCP/IP stack. No backwards compatibility and no better off than IPv6.

IPv6 boosters are fond of this talking point, but "no backward compatibility" is a gross exaggeration, or to be precise it is a false dichotomy, when in fact the ability to preserve front end interfaces that are familiar to users and administrators is a form of backward compatibility. But that certainly would not be the only form of backward compabitility offered by an extended IPv4 stack.

Re:Probably still waiting for their security softw (1)

unixisc (2429386) | about 2 years ago | (#39481667)

The backward compatibility breakage happens right @ the IP header, where the sizes of the source and destination addresses are defined. So an application that looks for a source address @ bit 192 would now have to start looking @ bit 193. Similarly, if the address sizes were changed to even 33 bits, similar changes would happen @ the header, albeit different in magnitude, and every router in the world would still have to be reconfigured/redesigned, and every IP app would still have to be re-written. Front ends can remain the same, but the back end changes would be major, no matter what. Going w/ 128 bit IPv6 enables a whole bunch of paradigm transformations that eliminate a whole bunch of issues.

Re:Probably still waiting for their security softw (0)

Daniel Phillips (238627) | about 2 years ago | (#39481755)

Wah wah, we can't figure out where to put some more bits. There must be just no way. Right.

Re:Probably still waiting for their security softw (1)

unixisc (2429386) | about 2 years ago | (#39481901)

You can. Just that every system that deals w/ it has to know that there are more than just 32 bits to the addresses. And once they're all going to be retrained, it's no different from the sort of effort that IPv6 is going through. In fact, by now, IPv6 has the most widespread support of any standard except IPv4, and if anyone were to come up w/ something else, it would be way behind IPv6 as far as adaption goes.

Re:Probably still waiting for their security softw (1)

Daniel Phillips (238627) | about 2 years ago | (#39481945)

Actually, you can pack extra bits into an IPv4 packet in such a way that a) valid packets using 32 bit addresses remain valid and b) packets with extra address bits are seen as invalid by unaware network drivers. Therefore "they" are *not* all going need to be retrained, only thoes that want to access a wider address range. So how much smoother that would have been rollout wise? We would already be there by now if a sensible approach like this had been adopted instead of the throw out the baby with the bathwater approach we now struggle with. It is by no means impossible that if an extended IPv4 was introduced today, it could exceed IPv6 adoption levels long before IPv6 manages to attract enough web sites to be worth the bother.

Re:Probably still waiting for their security softw (1)

unixisc (2429386) | about 2 years ago | (#39482083)

Where do you specify that? The IPv4 header ends w/ the destination address, and then the payload starts - the type of message, code, checksum, identifier, sequence number and then actual data. Before source address, there was version#, type of service, length, identification, flags & offsets, time to live, protocol and checksum. So where exactly do the extra address bits go? Oh, and remember, it will be needed for both source and destination.

Okay, let's say it was expanded to 40 bits, and we called it IPv5 (but put something else in the version flags bits in the header, since 5 was already taken by the Streaming protocol), and you got a new address 98.76.54.32.10. (out of a possible total of 255.255.255.255.255.) The new most significant byte was put in an area not previously assigned to addresses. So a network device which has only IPv4 drivers will read it as 76,54.32.10. Since that address is likely already taken, how would one be better off w/ IPv5? Oh, and let's say you wanted to connect to an external node w/ an IPv5 address of 59.192.168.1.10, and the driver reads it from the defined destination address field only, it would read 192.168.1.10, think it's internal and search within your LAN.

The above is a good illustration of how being compatible would actually introduce more bugs into the system, due to an expectation of consistency b/w the way the upgraded protocol works, vs the original one. Unless one were to now have 256 private Class A addresses and so on - that's the only way it would be compatible. Such a solution would be extremely leaky, since the world is not short of private IP addresses, but it's definitely short of public ones. So anything like w.10.x.y.z, w.172.16-31.x.y.z and w.192.168.y.z would all have to be designated as private addresses. W/ IPv6, you have a bonanza/plethora of addresses (depending on how you look @ it) but at least, you don't have private address space eating into public address space. But here, you have precisely that. W/ IPv6, one eliminates the need to upgrade for a really long time.

Re:Probably still waiting for their security softw (1)

Daniel Phillips (238627) | about 2 years ago | (#39482487)

Nice straw man. You assumed that an some of the bits of an extended address could be interpreted as a valid address and nasty things would happen. But these nasty things will not happen if an IPv4+ packet with extended addresses is constructed to appear invalid to an unaware network driver. So basically you could have saved typing your last two paragraphs.

Your question of where to put the new addresses bits is constructive. The obsolete [ietf.org]stream id option seems like a reasonable candidate, providing additional two octets, enough to supply the world's burgeoning address requirements for quite some time. Not a grandious 128 bits like IPv6, but just a modest expansion to take care of our needs basically for you and me, our kids, and our kids kids. That ought to be enough time to come up with some further *sensible* address expansion scheme.

So the principle is this: two extended address bytes are tucked away in places that will not destroy the internet. Such packets are constructed to appear invalid to unaware applications. If a path exists between a source and a destination both supportting extended addresses then the source and destination can communicate in the extended address space. The new byte goes at the least significant end, not the most significant, so that routing databases do not need to change.

See, it could work, and please aim mud at the argument, not your own straw man.

Re:Probably still waiting for their security softw (1)

unixisc (2429386) | about 2 years ago | (#39483665)

I don't see why that's a straw man. An unaware network driver could just read what's in the source and destination addresses, and ignore the areas that have the extended addresses - particularly if it happens to fall within a deprecated area in the header. Which is why the new addresses created would have to be compatible w/ what currently exists, thereby capping the growth headroom mentioned.

Also, this proposal essentially means kicking the can down the road, requiring a future generation to have to deal w/ it. But people are always going to find excuses not to switch, thereby putting off indefinitely the improvements that have been engineered into IPv6. If these changes required no changes to all the networking equipment out there, I'd agree w/ you. But the minimum it needs is a firmware upgrade, and guess what - that's exactly what they'd need to be IPv6 compliant. Exceptions being the switches that have custom IPv4 hardware accelaration on their ASICs.

Re:Probably still waiting for their security softw (1)

Daniel Phillips (238627) | about 2 years ago | (#39489433)

I don't see why that's a straw man. An unaware network driver could just read what's in the source and destination addresses...

Not if it's an invalid packet according to an unaware network driver. For example, the checksum might be wrong. There are all kinds of things that can go wrong if an application tries to act on addresses contained in an invalid packet indeed. Delivery to the wrong protocol for example. What a mess that would make. An unintentional straw man is still a straw man, and you knocked that one down yet again.

Also, this proposal essentially means kicking the can down the road, requiring a future generation to have to deal w/ it.

Sure. We need time, and this buys time. If you are saying that is a bad thing, your argument is weak. We kicked the can down the road when we went from 8 to 16 bit microprocessors, and again when me moved to 32 bit. What would have happened if the industry had decided to start off with 64 bit processors, just to avoid "kicking the can down the road"?

The rational question is "how much time would this buy?" And I say, a lot. More than enough so that a long term solution, even an ugly one like IPv6, can set itself in place in such a way as to enable a smooth cutover. Very definitely not the case with the current fiasco.

But people are always going to find excuses not to switch, thereby putting off indefinitely the improvements that have been engineered into IPv6.

None of the "bundled" IPv6 improvements is compelling. The only item in the compelling category is the address space fix. And there is more than one way to do that, and as we see here, there are ways that do not require every network admin in the world to relearn their basics.

People are especially going to find excuses not to switch when the switch is to something unfamiliar, or to something that does not work perfectly. Both very much the case with IPv6.

If these changes required no changes to all the networking equipment out there, I'd agree w/ you. But the minimum it needs is a firmware upgrade, and guess what - that's exactly what they'd need to be IPv6 compliant.

IPv6 switching requires considerably more hardware resources than IPv4, so network operators are faced not only with reflashing, but reprovisioning. And why? Customers are not beating down the door to get IPv6, so why should they bulldoze all their existing routers?

Then there is the question of ASICs as you say. That hardware is engineered for 32 bit addresses, not 128. An extended IPv4+ would still route most of the traffic through the hardware switch and only need to take extended packets out of line. For IPv6, you need new hardware, period.

So, summary. Your argument that existing IPv4 stacks would necessarily misinterpret extended addresses is most probably wrong, given that a suitable method of invalidating extended packets from the viewpoint of unaware network stacks is available. The argument that we need to go immediately to addresses greater than the number of the atoms in the earth to avoid need to extend addresses again during the lifetime of your grandchild is weak. Your argue that people will not switch anyway, even if the slightest thing is different. But this argument is wrong. People upgrade their operating systems all the time, there are very few who do not. Provided that everything just works, that is not an issue. An IPv4+ stack could easily be deployed to end users, just as the IPv6 dual stack was, except an IPv4+ stack would not be dual, and therefore even less disruptive. In fact, the way has already been paved by the IPv6 dual stack deployment process in many respects. For example, replacing all the 32 bit oriented network APIs.

Final total: one straw man, one weak argument, one incorrect argument. See, it is a fact that IPv6 deployment has failed to cover the gap between address depletion and takeup of a solution. No possibility of argument there, it has already happened. The question is, how much more of this pain are we required to endure in the name of fullfilling somebody's sweeping but impractical vision? And what is the sense in not considering any alternatives now that we have the worst possible result staring us right in the face: a universally natted internet?

Re:Probably still waiting for their security softw (1)

unixisc (2429386) | about 2 years ago | (#39499011)

Sure. We need time, and this buys time. If you are saying that is a bad thing, your argument is weak. We kicked the can down the road when we went from 8 to 16 bit microprocessors, and again when me moved to 32 bit. What would have happened if the industry had decided to start off with 64 bit processors, just to avoid "kicking the can down the road"?

Had the industry started w/ 64-bit CPUs and OSs, that would have been fantastic. Imagine Windows being a 64-bit OS when the Alpha was around - it would have flown. Similarly, nobody would ever have been going through 32-bit to 64-bit transitions. Given that Unix resource requirements were much higher, most of them became 64-bit ages before Windows did. But had we all started w/ that, we'd have avoided the 8 -> 16 -> 32 -> 64 transitions. We're doing it correctly here by going directly from 32-bit to 128 bit, instead of 33 or 40 or 48 or 64 bit.

Re:Probably still waiting for their security softw (1)

Daniel Phillips (238627) | about 2 years ago | (#39506507)

Had the industry started w/ 64-bit CPUs and OSs, that would have been fantastic.

OK, you sent the message loud and clear: you have no concept whatsoever of the advantages of pragmatism. Like a typical IPv6 booster, you live in a cloud where efficiency does not matter, compatibility does not matter, only forcing the wodl to accede to the brilliance of the great new white elephant matters.

Hint: if intel had tried to market a 64 bit microprocessor instead of an 8 bit, or indeed, 4 bit processor they would have been years late to market and nobody would know about them now, nor care.

Re:Probably still waiting for their security softw (1)

WaffleMonster (969671) | about 2 years ago | (#39486083)

So the principle is this: two extended address bytes are tucked away in places that will not destroy the internet. Such packets are constructed to appear invalid to unaware applications. If a path exists between a source and a destination both supportting extended addresses then the source and destination can communicate in the extended address space. The new byte goes at the least significant end, not the most significant, so that routing databases do not need to change.

These ideas really boil down to the failure to understand the issue is not about IP headers, packet formats or finding clever places to put things.. It is about ADDRESSING.

If the address spaces between IP protocols overlap then nobody knows apriori what paths support which protocols. We can not know if host A communicating via IPv4 can also reach host B on IPvDP or what router along the path prevent host A from communicating with Host B . If the address spaces are kept separate this is not an issue. Operationally this is critical to facilitiate migration. You could solve the problem for peers only by giving all existing IPv4 hosts addresses on the new extension network but this does not address routers, requires everyone renumber anyway and is therefore no better than IPv6.

Operationally IPv6 massive address space is a huge win for operators and end users and is well on its way to full deployment. Your hack not so much.

Re:Probably still waiting for their security softw (1)

Daniel Phillips (238627) | about 2 years ago | (#39490237)

We can not know if host A communicating via IPv4 can also reach host B on IPvDP...

Yes we can. If the low order byte of host B's address is zero, they can communicate, otherwise A needs to upgrade in order to establish a direct connection with B.

...or what router along the path prevent host A from communicating with Host B .

IPv6 has the same issue.

If the address spaces are kept separate this is not an issue. Operationally this is critical to facilitiate migration.

What? Your leap of logic escapes me.

You could solve the problem for peers only by giving all existing IPv4 hosts addresses on the new extension network...

As I already stated. Standard IPv4 addresses are extended with a byte of zero at the low order end.

but this does not address routers, requires everyone renumber anyway...

How do you conclude that renumbering is required?

and is therefore no better than IPv6.

You haven't proved that, especially not without filling in your logical holes above.

Operationally IPv6 massive address space is a huge win for operators and end users

Both those claims are firmly in the "hopefully, one day" category.

and is well on its way to full deployment.

That requires a creative definition of "well on the way". And what would be the use of "fully deployed" (if that ever happens) but not used? The generally accepted term for that is white elephant. In Canada we had an airport like that, Mirabel, all shiny and new and sitting for years with virtuatlly no planes on it because everybody preferred the old airport. Now redeveloped I believe.

Your hack not so much.

Nice rhetoric, but I you didn't prove that.

Re:Probably still waiting for their security softw (1)

WaffleMonster (969671) | about 2 years ago | (#39494137)

Yes we can. If the low order byte of host B's address is zero, they can communicate, otherwise A needs to upgrade in order to establish a direct connection with B.

I want to send a message to host A from host B. Host A is on IPv4. Host B is NOT. Host B does NOT have an IPv4 address because ah ...well they ran out and running out has consequences.

How does host B know if host A will be able to receive host B's message?

IPv6 has the same issue.

IPv4 and IPv6 are separate networks, separate routing, separate addressing. There is no problem of partial reachability within an IP universe in a dual stack environment. Either you have IPv4 connectivity, IPv6 connectivity or both. IPv4 and IPv6 universes are completely separate. In your scenario a host may support your IP protocol however if any router along the path does not then things don't work. Good luck finding out why and getting someone outside of your administrative control to fix it.

What? Your leap of logic escapes me.

Review my Host A and Host B question and try and answer it. When you fail you will understand my point.

As I already stated. Standard IPv4 addresses are extended with a byte of zero at the low order end.

Not good enough. See my Host A / Host B question above. Also consider the following:

MegaCo gets a more specific route of 1.1.1.1.x.y routed to them. 1.1.1.1 is a DSL user.

Whenever anyone tries to go to MegaCo and some host or intermediate router does not support your IP extension DSL user gets flooded with "invalid" packets as well as unintended information leakage.

How do you conclude that renumbering is required?

It is required if you want to avoid the Host A/Host B reachability problem. I assume you want to avoid this as operationally it is a showstopper. To ensure reliability people need to know that if they take action X they will see Y outcome. If I deploy IPv6 I get access to the IPv6 network. If I deploy an IPv4 CGN I get access to the IPv4 network. With your hack I'm getting access to some bastardized unreliable hybrid until EVERYONE upgrades. This is not a commercially viable solution.

Both those claims are firmly in the "hopefully, one day" category.

They are statements of fact independant of the deployment status of IPv6.

That requires a creative definition of "well on the way".

Every major content provider and ISP in the US is testing and or deploying IPv6. It is happening with or without you.

Nice rhetoric, but I you didn't prove that.

Not a single person on this planet has or ever will deploy your hack.

Re:Probably still waiting for their security softw (1)

jbolden (176878) | about 2 years ago | (#39483145)

It is not just extra bits, the entire routing / switching strategy changes. IPv6 has no layer 2 i.e. switching is based on IP not mac addresses. Also routing doesn't use routing tables.

If it were just packing extra bits, it would be easy enough to layer IPv6 on top of IPv4 and in fact that is exactly what IPv4 -> IPv6 conversion devices do.

Re:Probably still waiting for their security softw (0)

Anonymous Coward | about 2 years ago | (#39483951)

That is completely and utterly wrong. Switching with IPv6 happens the exact same way it happens with IPv4 simply because neither IPv4 nor IPv6 have anything at all to do with switching based on data link layer addressing. I don't even know what to make of the statement that IPv6 routing doesn't happen via routing tables, of course it does. IPv6 and IPv4 are not layered on top of each other, they exist in parallel.

Mocking standards? (5, Funny)

DragonWriter (970822) | about 2 years ago | (#39479635)

Based on my own company checks for readiness I assume the big hold up feature parody with IP4 and IP6 security software and equipment.

"feature parody"?

Re:Mocking standards? (3, Informative)

rudy_wayne (414635) | about 2 years ago | (#39479735)

Based on my own company checks for readiness I assume the big hold up feature parody with IP4 and IP6 security software and equipment.

"feature parody"?

Yes.

Re:Mocking standards? (0)

Anonymous Coward | about 2 years ago | (#39479783)

Based on my own company checks for readiness I assume the big hold up feature parody with IP4 and IP6 security software and equipment.

"feature parody"?

Yes.

That would be "parity"

Re:Mocking standards? (1)

rudy_wayne (414635) | about 2 years ago | (#39479811)

Based on my own company checks for readiness I assume the big hold up feature parody with IP4 and IP6 security software and equipment.

"feature parody"?

Yes.

That would be "parity"

Not if you mean "parody".

Re:Mocking standards? (0)

Anonymous Coward | about 2 years ago | (#39479845)

SWOOSH

Re:Probably still waiting for their security softw (0)

Anonymous Coward | about 2 years ago | (#39480219)

Based on my own company

For me I mentioned it a few times. They look like ip 6 wahh? If you knew where I worked you would shake your head too...

Re:Probably still waiting for their security softw (1)

unixisc (2429386) | about 2 years ago | (#39481501)

I know that FreeBSD is now complete w/ IPv6 support, to the point of supporting IPv6-only configurations, but what's the level of IPv6 support in OpenBSD? It would seem to me that if a router had OpenBSD on it and managed IPv6 traffic just like it could IPv4, a great deal of those problems would be solved - especially the ones dealing w/ the exploitation of security holes. Or are there finer details to these security issues that I'm missing?

Re:Probably still waiting for their security softw (1)

jbolden (176878) | about 2 years ago | (#39483153)

Yes there are finer details. When it actually comes to things like router and firewall code lots has to change.

For example there is no more NAT, so security layers provided by proxying addresses have to be added directly.
There are no more routing tables, so the layout of equipment should be different.
There is no more layer 2.
etc...

For companies that laid out a complex network in the 1990s they have to do something like "port the code" over to IPv6 based solution.

Re:Probably still waiting for their security softw (0)

Anonymous Coward | about 2 years ago | (#39482147)

I assume the big hold up feature parody with IP4 and IP6 security software and equipment.

I assume you meant "feature parity"..... but "feature parody" is an amusing alternative concept. :-)

Re:Probably still waiting for their security softw (0)

Anonymous Coward | about 2 years ago | (#39483559)

"Parody"? Do you perhaps mean parity? Or do you really mean that IPV6 and security equipment is a parody?

Networkworld confirms it! (1)

Anonymous Coward | about 2 years ago | (#39479741)

i mean we all are just waiting on akamai, because without akamai
nobody could run dns ... or not.

Re:Networkworld confirms it! (2)

Spad (470073) | about 2 years ago | (#39482447)

Akamai are big. Really big. Having them offer IPv6 services to their customers is a big step forward in terms of making IPv6 adoption practical.

Re:Networkworld confirms it! (0)

Anonymous Coward | about 2 years ago | (#39484355)

yes they are big. big and stupid.

Re:Networkworld confirms it! (1)

Trax3001BBS (2368736) | about 2 years ago | (#39490583)

i mean we all are just waiting on akamai

Lets just say if you run TCPview (netstat on steroids) you'll find you have a lot
of a184-84-209-18.deploy.akamaitechnologies.com's. The prefix will change but
a lot of what you get (Browser wise) is through .deploy.akamaitechnologies.com

biznat3h (-1, Troll)

Anonymous Coward | about 2 years ago | (#39479749)

In addition, re)cent article put driven out by the Learn what mistakes these challenges Something done asshole to others (I always bring my

Re:biznat3h (5, Funny)

rudy_wayne (414635) | about 2 years ago | (#39479827)

In addition, re)cent article put driven out by the Learn what mistakes these challenges Something done asshole to others (I always bring my

Mod up +10 insightful.

Best post ever.

Werent we supposed 2 run out of ips a while back? (-1)

youn (1516637) | about 2 years ago | (#39479821)

every year we hear that this year is ipv6 year, get a law to switch to ipv6 only... everyone will upgrade... this is almost like linux, year of the desktop... this is getting ridiculous... yes it will disturb some things but give people 6 months warning and switch... internet has not been around for ever so it is not like it is impossible... and for the few cases it is, put them behind a nat, case closed

Yes, we ran out (5, Funny)

SuperKendall (25149) | about 2 years ago | (#39480005)

We actually ran out of IP's last year, there's been one guy in Virginia running a NAT for the whole U.S. with the last one. But it's on an old lynxsys, he'd really like to free up the plug to vacuum and so we have to all get over to ipv6 pretty soon so he can power it down.

Re:Werent we supposed 2 run out of ips a while bac (1)

Anonymous Coward | about 2 years ago | (#39480237)

The US is not out of IPs. The rest of the world, notably the asia-pacific region, is nearly so. Not only that but in most places on the edges of the internet, double and triple nat is becoming commonplace. This is a far from ideal situation, and it can only get worse, (with solutions like carrier grade nat which shares one ip among dozens of gateways, restricting the available port ranges to each device to keep them all on one ip)

You think your ssh connections only lasting an hour or two now on your hotel's wifi is bad? The way things are going, all you'll be able to get from the internet will be web pages and advertising, slowly, and unreliably, particularly if you live outside the US.

I'm delighted to see akamai rolling out ipv6 across their CDN. Solving that portion of the problem will make it a lot easier for individual sites to upgrade to ipv6 (and also reduce the carrier grade nat problem to just the needed ipv4 addresses)

Re:Werent we supposed 2 run out of ips a while bac (4, Informative)

Anonymous Coward | about 2 years ago | (#39480337)

IANA, the top level of organizations which handle the allocation of IP addresses, has run out of IPv4 addresses more than a year ago: http://www.youtube.com/watch?v=orJpEJuZick [youtube.com]

The regional registries still have addresses and are going through them at different rates, so they'll run out at different points in the future.

RIPE (Europe) is down to about 40 million addresses, including the last 16 million which will be assigned under a different, more stringent policy: http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph [ripe.net]

APNIC (Asia) is already on the last /8 block: http://www.apnic.net/community/ipv4-exhaustion/graphical-information [apnic.net]

ARIN (North America): http://www.compusophia.com/en/ipaddrstat/ipv4_arin_pool.html [compusophia.com]

LACNIC (South America): http://www.lacnic.net/en/registro/espacio-disponible-ipv4.html [lacnic.net]

AfriNIC (Africa):
http://www.compusophia.com/en/ipaddrstat/ipv4_afrinic_pool.html [compusophia.com]

When those are depleted, it's going to be NAT all the way down.

Re:Werent we supposed 2 run out of ips a while bac (1)

rudy_wayne (414635) | about 2 years ago | (#39480903)

IANA, the top level of organizations which handle the allocation of IP addresses, has run out of IPv4 addresses more than a year ago: http://www.youtube.com/watch?v=orJpEJuZick [youtube.com]

The regional registries still have addresses and are going through them at different rates, so they'll run out at different points in the future.

Just because we run out of IP addresses doesn't mean the Internet suddenly evaporates. The 4 Billion existing IPv4 addresses will still work just fine. If you show up too late . . . . . . . the Internet is full, go away.

Re:Werent we supposed 2 run out of ips a while bac (3, Insightful)

jmauro (32523) | about 2 years ago | (#39480969)

Or buy them on the secondary market. The current price is around $12 [theregister.co.uk] per IP [gigaom.com].

Re:Werent we supposed 2 run out of ips a while bac (2)

Midnight Thunder (17205) | about 2 years ago | (#39481137)

Ah, but it works the other way too. See all those people doing business on the new IPv6 Internet? Shame you can't join them because 'too bad' they don't have IPv4 and you don't want to move to IPv6, because it is just hype.

At a certain point that snow ball will take on speed. You can deny it is coming, but will hit you sooner or later. Better off if you are prepared for it.

Re:Werent we supposed 2 run out of ips a while bac (1)

unixisc (2429386) | about 2 years ago | (#39481603)

Ah, but if only you had the remotest idea of how those 3.7 billion IP addresses are distributed - even within the US alone!

Re:Werent we supposed 2 run out of ips a while bac (2)

FireFury03 (653718) | about 2 years ago | (#39482097)

RIPE (Europe) is down to about 40 million addresses, including the last 16 million which will be assigned under a different, more stringent policy

Its worth noting that most (all?) the RIRs have similar /8 policies, which makes the idead of having "run out of IP addresses" slightly confusing. Basically, this means that once they are down to the last /8 (~16.8 million addresses), each LIR is only going to be allocated a single /22, forever. So with such a restrictive policy, it will take many years for the RIRs to actually run out of addresses, but as soon as they hit the last /8, addresses will get very scarce - this is the "crunch point" - by the time they actually run out we probably won't need IPv4 addresses any more.

The idea of this last /8 policy is mainly to allow new LIRs to get a small chunk of IPv4 addresses to allow them to continue to compete with the existing LIRs who already have IPv4 networks - imagine you're shopping around for a datacentre to host some servers in, the existing datacentres say "we can give you IPv4 and IPv6 connectivity" whilst the new datacentre says "we can only give you IPv6 because we have no v4 addresses". In that situation, no one would use the new datacentre, so by allowing them to have a /22 lets them compete on a more level ground. Of course, a /22 is only 1024 addresses, so they are going to have to be very careful with them, and are still at a disadvantage to the existing datacentres, who will be able to reclaim addresses from internal equipment, etc.

So, RIPE is about 26 million addresses away from the last /8 "crunch" and the addresses currently seem to be going at about 5 million a month, so we can probably expect them to run out around August/September, assuming the allocations stay at the same rate. Interestingly, APNIC saw a big increase in demand once they got down to about 7 /8s and this hasn't happened for RIPE yet. It will be interesting to see if there is a last minute demand.

A useful graph of allocations by RIR [potaroo.net]

When those are depleted, it's going to be NAT all the way down.

I keep hearing ISPs say "we're not implementing IPv6 yet, we've got loads of IPv4 addresses so we're not worried". But at the end of the day, I don't think the ISPs are going to be the driving force - I think they really do have plenty of spare IPv4 addresses, and even when they run out, they can NAT most of their customers and charge a premium to anyone who needs an un-NATted connection. The people who are going to be really hit by the crunch are content providers - at some point, a content provider is going to want to add a new server, a new HTTPS site, etc; and they're going to get the answer "no" when they ask the datacentre for some more IPv4 addresses. Thats when things are going to get messy. Of course, the ISPs saying "we don't need IPv6 since we've got loads of addresses" is totally bogus - it doesn't matter how many v4 addresses they have, if the ISPs' customers want to access content hosted by people who _don't_ have v4 addresses, they are going to need v6 connectivity, and eventually any ISP that doesn't provide it is going to lose out because some content isn't going to work. What ISP wants to tell their customers that they don't allow connections to Facebook's new service, or Google's new product?

One thing that would be nice to see is more v6-only content *before* crunch-time to try and pressure the ISPs to act. This could be done without seriously impacting the bottom-line of content producers: for example, Google always likes to "soft-launch" their new products, often by doing an invitation-only thing. But they could soft-launch them by initially making them v6-only. Same effect for them (no massive influx of new users, whilst getting a steady stream of users while they ramp up their infrastructure to cope), whilst causing the users to migrate to v6 earlier than they usually would so that they can access the shiny new product. Dual-stacked content is nice, but at the end of the day isn't going to do a lot to pressure people to upgrade.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39483183)

and even when they run out, they can NAT most of their customers and charge a premium to anyone who needs an un-NATted connection

That's called carrier based NAT and the carriers aren't setup for it. Further the regulators are hostile to it. So carriers would be looking at doing a change that's roughly as expensive as implementing IPv6 except they would also have to implement IPv6 soon thereafter and it would annoy regulators. Carrier based NAT is not going to happen.

What is going to happen is the carriers are going to put home and small business on IPv6 and then offer IPv6 -> IPv4 gateways so the IPv4 Internet looks to home/SB users like a small subnet inside their carrier's network and the carrier's addresses look to the IPv4 world like a cluster. What will break from this is:
a) Geolocation
b) Longer term session stability (since IPv4 addresses will change very quickly).

Re:Werent we supposed 2 run out of ips a while bac (1)

FireFury03 (653718) | about 2 years ago | (#39483601)

Further the regulators are hostile to it.

In what way are the regulators hostile to it? Here in the UK, I've seen no comments from OFCOM on the subject at all (getting *something* from them about IPv6 would be good, at the moment they seem to just be completely silent on the subject. Which is a shame because they really should have enforced ISPs supporting IPv6 a long time ago).

Anyway, whether the regulators like it or not, CGNAT isn't going to go away - we are far past the point where a transition to IPv6 will be an easy disruption free affair. We're going to need IPv4 for the foreseeable future (there's going to be IPv4 services for a looong time to come, and when the ISPs run out of IPv4 addresses, their only sensible options for allowing their customers to access IPv4 services are CGNAT and DNS64/NAT64. IMHO NAT64 is going to break a lot more that CGNAT because it is trying to shoe-horn IPv6 into *all* applications, including software that has no support for IPv6 at all, and essentially offers all the scope for plain old CGNAT-style breakage on top of that. Also, DNS64 badly breaks DNSSEC.

Of course, what *should* have happened was that ISPs should have rolled out IPv6 10 years ago, hardware manufacturers should have supported IPv6 10 years ago and datacentres should have supported IPv6 10 years ago and content providers should have dual-stacked their servers 10 years ago. If this happened, pretty much all home users would now have IPv6 enabled networks and workstations without even knowing about it and everyone would've had 10 years to complete the transition. Instead what happened was *everyone* stuck their heads in the ground and pretended this wasn't going to be a problem until about 6 months before IANA ran out, then various people said "oh shit, we'd better do something" and started implementing IPv6, whilst the vast majority of people still did nothing at all.

Hell, it's *still* pretty hard to find a consumer grade router that has any kind of IPv6 support - you're very unlikely to find that the one you just bought does it by chance, you've got to actively look for it (which isn't something the average consumer is going to do). Then once you have a v6-enabled router, it's extremely unlikely that your ISP offers an IPv6 connection, so you have to shop around for a new ISP (again, not something the average user will do). Then when you find an ISP that does v6, they alsmot certainly won't do it by default, so you have to convince them to turn it on for you (not something the average consumer will do).

Even when you explicitly search for IPv6 stuff, you find that the vendors are often lieing rather than actually implementing v6 support - there are a number of consumer grade internet routers around that say "IPv6 ready" on the box... it turns out that "IPv6 ready" usually means "we might release a firmware update to provide IPv6 support at some point in the future.. maybe, if you're lucky".

Another example - one of my customers was recently shopping around for a new leased line and I advised them to look for an ISP that supports IPv6 since they are going to need it within a reasonably short period. Eclipse Internet said "yes, we support IPv6" so the customer had the leased line installed. Once it was installed, I contacted Eclipse to ask for IPv6 to be enabled and got the reply "Our network fully supports IPv6, however we are not rolling it out to any customers at this point in time"... well that's a fat lot of use and if I were the customer I would be demanding that they refund the installation costs and cancel the contract since it was clearly sold on false pretenses (no, I really don't believe that you can legally tell as potential customer "yes we support IPv6" when you have no intention of giving them an IPv6 connection when they ask for it).

The sad thing is, all the products my company sells fully support IPv6, yet *no one* has ever said anything about this - IPv6 *should* be on every customer's "must have" list when buying new stuff, even if they aren't planning on implementing IPv6 yet, because it's going to be needed within the expected lifetime of anything they buy, but this just isn't happening at all - it isn't even on anyone's radar. Not one of my customers has an IPv6 enabled network.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39484513)

Great comment lots to reply to. The bulk of your comment is about the fact that equipment manufacturers aren't ready yet and in practice their equipment is way behind where they claim it is. I agree with you 100% on that. It is going to be infuriating for people who say buy equipment in 2013 to maybe have to toss it in 2014.

Though I should mention I assume carrier home/small business router/modems will do IPV6->IPV4 as part of their dual stack, so people with home small business equipment could run an IPV4 subnet and keep their equipment. More than just network equipment there are expensive network attached printers and no one wants to replace all of them,.. BTW what is your company?

As for software not having support, again I agree. And I think again that's going to be handled by running small v4 subnets inside of IPV6. I don't think the world moves off dual stacking until around 2030. I'll hit the carrier based NAT issues in my next comment.

Re:Werent we supposed 2 run out of ips a while bac (1)

FireFury03 (653718) | about 2 years ago | (#39485041)

I should mention I assume carrier home/small business router/modems will do IPV6->IPV4 as part of their dual stack, so people with home small business equipment could run an IPV4 subnet and keep their equipment. More than just network equipment there are expensive network attached printers and no one wants to replace all of them,..

I'll address this in 2 parts:

Firstly, most consumer grade routers (that is: the sort of Netgear, etc. thing most people have at home and in small offices) do no IPv6 *at all*. Individual workstations are going to be able to use the likes of Teredo to tunnel v6 traffic over IPv4, but that's a really poor bodge at best.

Second: equipment like networked printers, etc. are largely unaffected anyway. No one (sane) is suggesting turning off IPv4 entirely on the LAN - most people will run IPv6 and IPv4 concurrently. All your old IPv4 equipment is still going to be able to talk to your workstations since they will all run IPv4 too. The router doesn't really affect what protocols you run internally - even if you were on an IPv6-only internet connection, you can still run IPv4 internally to keep your old equipment working.

The only real issues here involve old IPv4-only network equipment that needs to talk to something on the internet - since there won't be enough v4 addresses for each piece of equipment, it'll be going through some variety of NAT. Outgoing connections from your legacy equipment to v4 servers will be (largely) fine, although of course, legacy equipment won't be able to connect to IPv6 services. Inbound connections from the internet to your legacy equipment aren't going to be possible, which is going to be a problem for certain peer to peer technologies. I imagine that ISPs will sell "premium" accounts that provide globally reachable IPv4 addresses that don't go through a NAT - this is possible because they will be reclaiming IPv4 addresses from all those customers who don't pay for the premium account.

By the way, old v4-only equipment is an excellent reason why DNS64/NAT64 isn't the big solution that some people make it out to be: the idea behind DNS64/NAT64 is that the customer's network can be a single-stack IPv6 network whilst still allowing them to connect to IPv4 servers. This is done by passing all the DNS requests from the customer through a DNS64 server - this mangles the IPv4 addresses that are returned in response to a DNS request into IPv6 addresses (breaking DNSSEC in the process). The customer's equipment makes an IPv6 connection to this fake address, which is routed via a NAT64 system, which translates it into IPv4 traffic. Returning traffic is un-NATted back to IPv6 in much the same way as normal IPv4 NAT works. The problem here is that the customer's equipment needs to be able to do IPv6, and this clearly isn't going to be the case for some years. So the ISP is going to have to provide some kind of native IPv4 connectivity anyway, which renderd DNS64/NAT64 a bit pointless. To me, it seems like a solution looking for a problem.

BTW what is your company?

I run Opendium [opendium.com] - we primarilly produce web filtering systems, mail servers, etc. for schools and small businesses and also often run or consult with them on their network infrastructures and network security.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39487153)

Firstly, most consumer grade routers (that is: the sort of Netgear, etc. thing most people have at home and in small offices) do no IPv6 *at all*.

I agree. Which means that either upstream from them the device is going to be doing IPv6 -> IPv4. This capability is going to need to be in Home / Small business modem/router/switches provided by carriers.

  Second: equipment like networked printers, etc. are largely unaffected anyway. No one (sane) is suggesting turning off IPv4 entirely on the LAN - most people will run IPv6 and IPv4 concurrently. All your old IPv4 equipment is still going to be able to talk to your workstations since they will all run IPv4 too. The router doesn't really affect what protocols you run internally - even if you were on an IPv6-only internet connection, you can still run IPv4 internally to keep your old equipment working.

There is impact since you need to be able to access resources internally and externally. Right now a lot of that is handled via. NAT and having static IPv4 IPs for small business.

legacy equipment won't be able to connect to IPv6 services

They are going to have to. Which means some piece of equipment upstream from them is going to have to handle translation.

I imagine that ISPs will sell "premium" accounts that provide globally reachable IPv4 addresses that don't go through a NAT - this is possible because they will be reclaiming IPv4 addresses from all those customers who don't pay for the premium account.

Agreed, that's exactly what I think will happen. Though as time goes on they may lose the infrastructure to support this for home / small business so unless you are buying an expensive connection, like a DS3 (or whatever they sell then), it may not be available at all.

...which renderd DNS64/NAT64 a bit pointless..

I don't agree and I think we need to break "customer" into classes here. For home/small business the carrier provides this service at the level of the router/modem. So the customer runs IPv4 internally, the equipment that can tunnel does and other stuff gets dynamically allocated IPv6 connections. So for example if my IPv4 printer needs to talk to
AABB:CCDD... it gets told it is talking to 192.168.5.24 the same way NAT works internally now. For larger business they are going to be buying their own equipment to do NDS64/NAT64.

I think this is going to be vital to do translations for years all throughout the internet.

Re:Werent we supposed 2 run out of ips a while bac (1)

FireFury03 (653718) | about 2 years ago | (#39488557)

Which means that either upstream from them the device is going to be doing IPv6 -> IPv4. This capability is going to need to be in Home / Small business modem/router/switches provided by carriers.

That seems silly. If the carrier is going to provide hardware to to IPv6 over IPv4 tunnelling because the customer's router doesn't do IPv6, they may as well simply provide a replacement router that _does_ do IPv6.

legacy equipment won't be able to connect to IPv6 services

They are going to have to. Which means some piece of equipment upstream from them is going to have to handle translation.

I disagree. I can't really see a reason for legacy equipment to talk to IPv6-only equipment. The sort of equipment we're talking about is stuff like games consoles, which may need to contact the vendor's servers to do DRM, etc. There's no reason why the vendor can't continue to provide servers accessible over IPv4 for the lifetime of the product - after all, they already have the v4 addresses since the servers are already running. If someone's running a PC that can't do IPv6 then they seriously need to upgrade it anyway because its presumably running Windows 95.

For home/small business the carrier provides this service at the level of the router/modem. So the customer runs IPv4 internally, the equipment that can tunnel does and other stuff gets dynamically allocated IPv6 connections.

Why wouldn't the customer run a dual-stack network internally (on all devices that are v6-capable)? Running only v4 internally and then playing messy NAT games to let it talk to v6 kit is crazy if the equipment is v6-capable anyway.

So for example if my IPv4 printer needs to talk to AABB:CCDD... it gets told it is talking to 192.168.5.24 the same way NAT works internally now.

Why does your printer need to talk to any v6-only equipment? The only stuff it needs to connect to outside your LAN is possibly the vendor's firmware update server, which is already available on v4 and can continue to be so for the support lifetime of the printer. The printer can talk to everything on your LAN because the IPv6 machines are also running dual-stacked IPv4.

Lets be clear: no one is going to be running significant v6-only services any time soon - the customer base just isn't high enough to support it. There will be all sorts of crazy NAT and proxy games on the datacentre side of the connection to make as much as possible appear on v4 addresses. By the time anyone starts launching significant v6-only services, v4-only devices are going to be very old and people will be willing to forego supporting them, just like websites frequently no longer support IE6.

(Yes, I'm aware there are already v6-only services. However, these have been launched in restricted markets.)

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39490953)

Lets be clear: no one is going to be running significant v6-only services any time soon

They already are for cell phones. The carriers are running all kinds of services to their cell phone / mobile customers. So far it is all internal to the carrier's networks but they exist. There are also services in Asian languages that are v6 only.

I agree we are still several years away from v6 only services.

As for the lifetime of printers. Good printers can have lifetimes in terms of many years. During the 90s I worked on channel printers from the 70s.

Re:Werent we supposed 2 run out of ips a while bac (1)

FireFury03 (653718) | about 2 years ago | (#39493689)

As for the lifetime of printers. Good printers can have lifetimes in terms of many years. During the 90s I worked on channel printers from the 70s.

And yet still, I see no reason why a printer needs to connect to an IPv6-only service on the internet...

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39495051)

To connect to an IPv6 user, like a cell phone.

Re:Werent we supposed 2 run out of ips a while bac (1)

FireFury03 (653718) | about 2 years ago | (#39495635)

To connect to an IPv6 user, like a cell phone.

I can't think why a printer would ever need to connect _to_ your cellphone.

You might want to print from your phone though, which would necessitate a connection from your phone to your printer. This is the same as connecting to any IPv4 service from an IPv6 device (except in actual fact it probably won't be possible anyway since your printer isn't going to have a global scope address). If your phone is connected to your local wifi then it will have a v4 address anyway, of course.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39495775)

TCP/IP is bidirectional.

Remember the context. Home network is IPv6. Home LAN is IPv4 since the printer is v4. Cell phone is v6 on a v6 network but could be going wifi off a v4 or v6 network.

Re:Werent we supposed 2 run out of ips a while bac (1)

FireFury03 (653718) | about 2 years ago | (#39496023)

TCP/IP is bidirectional.

Remember the context. Home network is IPv6. Home LAN is IPv4 since the printer is v4. Cell phone is v6 on a v6 network but could be going wifi off a v4 or v6 network.

Ok, with a v4-only printer on a LAN, the choices seem to be:

1. Cellphone also on the LAN (probably over wifi) and wants to connect to the printer: The cellphone has a v4 address so can just talk to the printer as usual.

2. Cellphonw is also on the LAN and the printer wants to connect to it: Again, the cellphone has a v4 address, no problem.

3. Cellphone is on a v6-only mobile network and wants to connect to the printer. The cellphone can connect to any v4 service through NAT64, including a printer, so no problem. However, in reality, tte printer doesn't have a global scope address, so it is impossible for something on the internet to talk to it; you might buy a v4 address from the ISP at a premium price in order to map it to the printer, but I question whether anyone actually wants their printer to be accessible from the global network anyway.

4. Cellphone is on a v6-only network and the printer wants to connect to it. Oh, this isn't going to be trivially possible, but I can't think of a reason why you'd ever want to do this anyway.

Yes, TCP traffic is bidirectional, but when we're talking about any kind of v4/v6 translation (NAT) then what matters is the direction the connection is made in (i.e. which side sends the initial SYN) - from that point on, the connection is being statefully tracked by the NAT and you don't need both endpoints to have globally reachable addresses.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39500885)

Agree with this. As for globally reachable addresses and printers. The way it is done now is using something like dynamic dns and port forwarding. For example the home computer might "check in" with its addresses every hour to a remote server. Now that is going to be the address of the router, but the router port forwards to the printer. So even though the addresses are dynamic the printer is reachable.

The only case you are missing.

Home router is on a v6 network but printer is on a v4 subnet. So the external address is v6.

Re:Werent we supposed 2 run out of ips a while bac (1)

unixisc (2429386) | about 2 years ago | (#39494053)

Actually, given the requirements of Mobile IP and the fact that carriers needs plenty of addresses for all the mobile nodes they'll need, IPv6 is their only option, given how NAT completely breaks the way they'd work w/ IPv4.

For printers, the only thing that makes sense is putting them in a VPN, so that an employee @ a remote location can print out something while he's out. Otherwise, there is no reason for printers to have public IP addresses. And the urgency for office LANs to be IPv6 is just not there, since there ain't an address exhaustion issue here the way there is for public addresses. The only reason to make office LANs IPv6 is so that they share the same protocol as the external network.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39495039)

The urgency for office LANs to be IPv6 comes from the fact that external facing systems start needing to be IPv6 and other resources start going IPv6. That's a while away. Eventually though it will make sense for new LANs to be IPv6 and old LANs to be dual stack.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39484609)

This reply is only going to deal with the CGNAT.

First off on the regulators I was talking ARIN and FCC, sorry typical American assumption that we are addressing Americans. I have no idea what the situation is in the UK, but the UK doesn't make a lot of its own carrier grade equipment so I doubt they are going to follow their own strategy in the UK, unless you've heard differently. As far as carrier strategy I assume USA, France (Alcatel-Lucent), Israel are the big 3 for whether CGNAT gets rolled out or not. Obviously there is nothing to stop the UK from going the CGNAT route on its own if they so choose.

In terms of ARIN they've declared this to not be "best practices" which means from a US legal standpoint using CGNAT would create liability situations that don't exist under an IPv6 transition. In other words if something went wrong for a client and it was a result of CGNAT they hurdle for proving negligence would be lower and the damages higher. There are also a few other things "not best practices" means in terms of US utility law. Basically though that stick is big enough for every carrier to indicate they ain't going the CGNAT route.

As far as the transition, as I mentioned cell/small business/home are going to go first. Once those go, you will see equipment that supports IPv6 for small business. Mid and large business and going to have huge headaches.

As far as allowing customers to access IPv4 content, we already have that for the cell networks and the few places it has been rolled out for home. What the carriers do is run IPv6 -> IPv4 translation so IPv4 resources look like they exist on a subnet within the carrier. From the v4 side it is a gateway with rapidly rotating IPv4 addresses.

Re:Werent we supposed 2 run out of ips a while bac (1)

FireFury03 (653718) | about 2 years ago | (#39485335)

In terms of ARIN they've declared this to not be "best practices" which means from a US legal standpoint using CGNAT would create liability situations that don't exist under an IPv6 transition.

I'd be interested to know what ARIN consider to be "best practices" in this regard. Obviously it is poor if ISPs are going to offer CGNAT *instead* of IPv6 support (I don't really see how this is viable in the long term though - at some point people will need to access v6-only content). However, ISPs are going to have to offer IPv4 connectivity for the forseeable future, until IPv4-only equipment and services have been almost entirely phased out. With a shortfall of IPv4 addresses, ISPs are going to have to use NAT in order to continue to provide IPv4 connectivity to everyone. The way I see it, best practice would be to provide IPv6 connectivity for everyone as standard, but also CGNAT IPv4 connectivity so that people can still access v4-only content and use v4-only equipment. By "v4 only equipment", I mean your IPv4-only games consoles, etc. which will continue to need to contact the vendor's servers, which the console vendor will need to ensure remain accessible over v4 for the normal lifetime of the equipment.

In other words if something went wrong for a client and it was a result of CGNAT they hurdle for proving negligence would be lower and the damages higher.

I don't quite see that - "something going wrong" is basically going to be 2 devices not being able to talk to each other. We see this all the time anyway, even where no NATs are involved. Misconfigured routers dropping TCP packets with the ECN bit set used to be a big problem, these days its still quite common for ICMP Frag Needed packets to be dropped by misconfigured routers, leading to hanging TCP sessions - all of this stuff is of a similar seriousness to any CGNAT related problems that might befall an ISP, and ISPs are rarely held responsible (in fact, in my experience, it's usually pretty hard to even convince the ISP to fix a problem, even when you provide ample evidence that it is a misconfiguration within their network, so they can't be that worried about their liability for obscure network problems).

What the carriers do is run IPv6 -> IPv4 translation so IPv4 resources look like they exist on a subnet within the carrier. From the v4 side it is a gateway with rapidly rotating IPv4 addresses.

This is DNS64/NAT64. It works fine in specific cases where you know the end-user equipment is fully v6 capable (for example, you sold them a v6-capable phone and you know the whole software stack does v6 just fine). I can't see it being an acceptable solution for generic networks, since they have all sorts of random equipment that won't do IPv6, and even on v6-capable machines, there's often lots of software higher up the stack that doesn't support v6. On the whole, I can't see a big advantage of NAT64 over CGNAT - in both cases you have a NAT interfering with the traffic, with pretty much every problem CGNAT causes also present in NAT64. The saving from NAT64 is that you don't need to build out a private IPv4 network, but the cost is that you break everything that relies on having an IPv4 network.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39487325)

I'd be interested to know what ARIN consider to be "best practices" in this regard

Dual stack. Customer should get an entire /64 or larger to build subnets and do translation on their side. Carriers should provide a IPv6 -> IPv4 gateway to access v4 resources from v6 networks. No v6 upstream from the customer's site, they do not want ISP's creating complexity in the v6 address space and maintaining the purity of the routes.

By "v4 only equipment", I mean your IPv4-only games consoles, etc. which will continue to need to contact the vendor's servers, which the console vendor will need to ensure remain accessible over v4 for the normal lifetime of the equipment.

That's a good example where a carrier gateway would work. Eventually though the gateway can get pushed down to the individual's modem/router so they see the v4 network as a subnet inside their individual v6 subnet. That way the game console sends a v4 packet and the router assigns a v6 address to the game console for the server to respond to.

On the whole, I can't see a big advantage of NAT64 over CGNAT
The big advantage is:

a) It puts the customer fully in control. They can implement their own NAT64 schemes however they choose.
b) No routing tables, which means carriers grade routers can be upgraded to the much higher speeds possible with non table based routing. Which will allow for protocols that are much more sensitive to jitter.

all of this stuff is of a similar seriousness to any CGNAT related problems that might befall an ISP, and ISPs are rarely held responsible

Correct because they are following "best practices". If they are not following best practices and something goes wrong utility commissions can nail them to the cross.

Re:Werent we supposed 2 run out of ips a while bac (1)

unixisc (2429386) | about 2 years ago | (#39488033)

What you seem to be describing in your first answer is Dual-Stack lite, which is somewhat the converse of tunneling. Here, the IPv4 packets get encapsulated in IPv6 before being sent over the network. Incidentally, this is where your CGNAT would be used - at the end points where the IPv6 decapsulation takes place and the IPv4 packet proceeds to its destination. Sounds the same as LSNAT. Dual stack OTOH simply means an IPv4 network and an IPv6 network running side by side.

Are no routing tables still an objective of IPv6? I thought that that concept was abandoned due to organizations having multiple ISPs, all w/ their own Provider-dependent Addresses.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39488889)

I don't know anything about LSNAT in terms of IPv6 and sharing. So I'm not following. I agree on what dual stack means.

As for routing tables I thought that was still an objective. And yes multiple ISPs means multiple provider dependent addresses I'm not following why that presents a routing problem. Two ISPs to the same box means two addresses which the company internally would translate.

Re:Werent we supposed 2 run out of ips a while bac (1)

FireFury03 (653718) | about 2 years ago | (#39488849)

I'd be interested to know what ARIN consider to be "best practices" in this regard

Dual stack.

Dual-stack requires either:
1. Enough IPv4 addresses for each piece of equipment
2. NAT

Customer should get an entire /64 or larger to build subnets and do translation on their side.

Do what translation exactly? Are you talking about tunnelling or translating? Bearing in mind that we're talking about IPv4-only equipment at both ends of the connection, I can't see how you can be talking about translating here.

Carriers should provide a IPv6 -> IPv4 gateway to access v4 resources from v6 networks.

So you're suggesting that the customer's router (which has no globally routable IPv4 address) takes v4 traffic from the customer's network, encapsulates it in v6, shoves it over a v6-only connection to the ISP where it gets de-encapsulated back to plain IPv4 and (wait for it) goes through a CGNAT (since nothing customer-wards of here has a globally routable v4 address)?

Firstly, how does this eliminate the "not best practices" CGNAT from the setup (it doesn't, you still need to NAT the traffic at the point it hits the globally routable v4 network).
Secondly, how does encapsulating it over the backhaul from the customer to the ISP help at all. Bear in mind that a PPPoE ADSL backhaul is basically IPv4 encapsulated within PPP, encapsulated within Ethernet, encapsulated within VC-Mux, encapsulated within ATM. The entire PPP stream is delivered to the ISP, so there seems to be no advantage in encapsulating v6 within the v4 rather than just shoving v6 directly on the PPP stream. Meanwhile, wrapping v6 in a v4 header increases the protocol overhead on the slowest part of the network even more.

It is true that the ISP may want to run the majority of their network as v6-only to avoid having to build out a v4 network, and that is may therefore be better to handle the v4 traffic as a plain v6 between a customer and the ISP's gateway, but this does not necessitate the customer's equipment doing any tunnelling - whether or not the ISP wants to do this is an internal affair and can be handled entirely internally (encapsulate the v4 traffic at the point the telco's backhaul reaches the ISP - no requirement to do this on customer-side equipment).

The big advantage is:

a) It puts the customer fully in control. They can implement their own NAT64 schemes however they choose.

Not really. The NAT64 gateway *has* to be on the ISP's network and shared by multiple customers, anything else requires each individual customer to have a global scope IPv4 address.

No routing tables, which means carriers grade routers can be upgraded to the much higher speeds possible with non table based routing.

I have no idea how you arrived at "no routing tables" from NAT64...

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39490891)

Dual-stack requires either:
1. Enough IPv4 addresses for each piece of equipment
2. NAT

That's NAT at the client side. Carrier modem/routers/switches for home/small business provide that today. The issue was whether the carriers are going to NAT throughout their network not after the handoff.

Do what translation exactly? Are you talking about tunnelling or translating? Bearing in mind that we're talking about IPv4-only equipment at both ends of the connection, I can't see how you can be talking about translating here.

OK again we use your game console. Game console is on an internal at 192.168.5.23 (internal IPv4 network) it is trying to get to 1.2.3.4. The home has an address of AA:BB:CC:DD:EE:FF:12:34 / 64 so console has assigned to it, an IPv6 address of AA:BB:CC:DD:EE:FF:00:00:01:00:05:17 (5.23). The console speaks IPv4 to the home router which tunnels to a gateway. Note the router tunnels not the game console and nothing on the carrier side say the gateway is at AA:BB:12:34:56:78:90:01:02:03:04 (carrier;'s virtualization). The carrier assigns a temporary v4 address to the home router / game console and passes this to the 1.2.3.4 server.

So the path is IPv4 -> IPv6 -> IPv4 a tunnel but the tunnel is not for each piece of equipment.

Re:Werent we supposed 2 run out of ips a while bac (1)

petermgreen (876956) | about 2 years ago | (#39484709)

That's called carrier based NAT and the carriers aren't setup for it. Further the regulators are hostile to it. So carriers would be looking at doing a change that's roughly as expensive as implementing IPv6 except they would also have to implement IPv6 soon thereafter

IPv4 addresses are going to run out for some providers before a critical mass of servers are available on IPv4. Those providers will HAVE to implement some kind of NAT like soloution at the ISP level regardless of whether they implement IPv6. The only question is whether it will be plain V4 NAT, an encapsulated soloution like DS-Lite or a protocol translation soloution like NAT64.

Carrier based NAT is not going to happen.

It's already happening with some providers, particually mobile ones.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39486819)

I agree I'm just saying they are going to do NAT64/DNS64 i.e. IPv6 -> IPv4 not Carrier Grade NAT.

It's [Carrier Grade NAT] already happening with some providers, particularly mobile ones.

Well yes, but there isn't as much mobile infrastructure. And note that most of the devices get dual stack capability.

IANA (1)

ThatsNotPudding (1045640) | about 2 years ago | (#39482995)

IANA, the top level of organizations which handle the allocation of IP addresses

I've been on Slashdot too long: "IANA... I Am Not A... what? What are you not?? Tell me!!"

Re:IANA (0)

Anonymous Coward | about 2 years ago | (#39483143)

I Am Not An Internet Assigned Numbers Authority.

Re:Werent we supposed 2 run out of ips a while bac (1)

unixisc (2429386) | about 2 years ago | (#39481917)

Another solution - stop any work on IPv4 so that it has more security holes, unresolved bugs and so on, and make new OSs not support it at all. At different pain points, people will be forced to switch to IPv6. Such a change would be even less painful than the switch to Digital TV.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39483197)

Right now it is not people who are the problem it is carriers. And they are under pressure, they no longer can get IPv4 addresses to grow their networks. Every carrier is working on IPv6 some at different rates, but they are all progressing.

Re:Werent we supposed 2 run out of ips a while bac (1)

jbolden (176878) | about 2 years ago | (#39483161)

The switch takes 5-7 years for most people. Last year there was some testing and some of the major services like google offered IPv6 services. The carriers are doing their part. This is not a small project and you will be hearing about it all through the decade.

Why should I trust Akamai to get it right? (1)

viperidaenz (2515578) | about 2 years ago | (#39480723)

Their website has a "Net Usage Indices" part with a combo. They only have a click listener so changing the value with the keyboard doesn't update.

If they can't get simple HTML/Javascript right, how can I trust them to get anything more complex right?

Re:Why should I trust Akamai to get it right? (1)

glaurungn (1253152) | about 2 years ago | (#39481151)

Maybe because they are in the bussines of content delivery, not content creation, so the inhability to make a simple HTML/Javascript site is not really relevant.

Re:Why should I trust Akamai to get it right? (1)

TheSunborn (68004) | about 2 years ago | (#39481863)

I have not looked, but I guess they have an onChange listener, and those are not activated by keyboard changes. If you want to complain about that, write a mail to w3c because they explicit said that this was the way it should be.

Re:Why should I trust Akamai to get it right? (1)

viperidaenz (2515578) | about 2 years ago | (#39481977)

Looks like they attached a change listener via jQuery 1.7 with a method that's been deprecated since 1.4. The change event is activated by any change, but only after the element loses focus. Its an implementation that looks like it works at first glance, but fails when interacted with in a manor they did not consider.

Just out of curiosity.... (0)

Anonymous Coward | about 2 years ago | (#39480881)

Theoretically speaking, could an all-IPv6 based CDN be used to serve the IPv4 internet, and is there any advantage to that if so? Don't know much about CDN's, only that they have "network" in the acronym. Are CDN's part and parcel of the "cloud" paradigm thingy?

Re:Just out of curiosity.... (1)

Midnight Thunder (17205) | about 2 years ago | (#39481155)

The only way to get IPv6 and IPv4 speaking together would be via a proxy and that would only work for certain protocols.

Many companies will probably find themselves having to do just that, because they have wanted to deny the reality of IPv6 and therefore have not developped a migration strategy.

Re:Just out of curiosity.... (1)

allo (1728082) | about 2 years ago | (#39487403)

no. There is a address-range for ipv4 in v6, so its no problem to transmit v4 packets in v6. The other way round is not possible without tunnels.

Re:Just out of curiosity.... (1)

unixisc (2429386) | about 2 years ago | (#39494795)

If you are talking IPv4 compatible addresses (::/96), that standard is deprecated. If you are talking about IPv4 mapped addresses (::ffff:/96), that is still available but its implementation varies from OS to OS, behavior is implementation dependent, and there are potential vulnerabilities if it is enabled. It was originally intended as a transition mechanism, but it caused more problems than it solved, so it is better left unused, and ideally, disabled.

I don't see tunnelling as them speaking together - it's more like the encapsulating header is like a tow truck, and the encapsulated packet is like a car being towed.

Dual Stack Lite (2)

unixisc (2429386) | about 2 years ago | (#39481571)

Not just theoretically, but this is one of the techniques likely to be used in the long term IPv6 transition. Essentially, the main CDN is IPv6 only, but @ the CPEs, a single IPv6 node address is used to serve several IPv4 nodes, all of which have private IPv4 address. As a result, it completely skirts the issue of IPv4 address exhaustion, and allows legacy IPv4 nodes to operate freely on IPv6 networks. Comcast used this in their trial runs, although for the final customer delivery, they went w/ dual stack. DS-Lite's advantage over DS is that the latter would still be impacted the day IPv4 runs out of addresses. The former won't.

Nice, but... (1)

WindBourne (631190) | about 2 years ago | (#39481265)

I want qwest/century link to get moving on IPv6. They WERE moving to it before century link merged with them. Now, they are going backwards. We need large ISPs to move ASAP to IPv6 to free up IPv4s.

Re:Nice, but... (1)

unixisc (2429386) | about 2 years ago | (#39481943)

The move to IPv6 wouldn't - and shouldn't - free up any IPv4s. IPv4s (I'm talking about routable IPv4s here) will still be needed and used to support dual stack. What would change is that for every node that requires external connections and offers IP based services, IPv6 would be used, while IPv4s would only be used for things like websites. In fact, think of IPv4s as mirrors of IPv6 websites for those who can't access IPv6. Or, in other words, use IPv4 only for services that absolutely must be offered to external facing visitors who have only IPv4.

On another note, a lot of applications just use bare IP addresses for things like NFS or NIS servers and so on. For such things, IPv6 is a godsend - they can use either link-local IPv6 addresses (0xfe80::/10) or global unicast addresses (0x2001::/3), thanks to the support that IPv6 has for multiple valid addresses (be it same or different subnets) for a single node. One could have one IP address for the HTTP server, another for the mail servers and so on.

Re:Nice, but... (1)

WindBourne (631190) | about 2 years ago | (#39482497)

The dual stack SHOULD only exist for a year or two. After that, the ISPs then drops the dual and only presents IPv6 first to all businesses, and then in another 6 months to all clients. The issue is that we need to have 1-2 years to shake it out. And it will take that long for ppl to realize what changes they need to do.

To make all this happen, the large hosting services and major ISPs should come to agreement on this. This is more true for the major ISPs in markets where they compete. For me, that is comcast and century link. If they both offer the dual stack at the same time, and then drop IPv4 at the same time, but only after giving businesses time to change their sites,

BTW, the nervana that you describe in the 2'nd paragraph is what many of us enjoyed in the 80's. I had my own class C at no costs. I got it from the university and then in the early 90's from the local ISP. The reason is that IPs were plentiful. Then it changed by '96. It will be nice to regain a decent network. I have hated this NAT bs.

Re:Nice, but... (1)

jbolden (176878) | about 2 years ago | (#39483243)

The internet is global. There isn't going to be a coordinated switch. Rather it is going to go:

a) Carriers go dual stack
b) Cell / Home / Small business on IPv6 with IPv6 -> IPv4 gateways. That's one transition.
c) MId / large business go internally dual stack while having IPv6 outward facing.

Then probably in a decade or more.

a) Most carriers stop offering IPv4
b) The gateways get crappier and worse and finally become an extra cost feature.
c) Mid / large business have only very small isolated IPv4 subsystems most likely running inside of virtual machines.

Re:Nice, but... (1)

jbolden (176878) | about 2 years ago | (#39483215)

Actually it will free up IPv4s because of pooling.

Lets say I provide internet connections to 1m people via IPv4. That is 1m IPv4 addresses, dynamically allocated but they are held for a day plus on average. Now I start pooling so that an IPv4 address is surrendered after 5 minutes of being idle. I might be able to drop down to 200k addresses freeing up 800k. That is the in fact exactly the incentive for the carriers to move home / small business to IPv6 with IPv6 -> IPv4 pooling.

mod 04 (-1)

Anonymous Coward | about 2 years ago | (#39481791)

'Yes' 7o 4ny To yet another

So when will Slashdot be on IPv6? (3, Insightful)

Skapare (16644) | about 2 years ago | (#39481855)

So when will Slashdot be on IPv6? Inquiring minds and nefarious hackers want to know.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...