Slashdot Mirror
Akamai To Offer IPv6 To All In April
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."
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.
EA David Gardner -"... but the consumers have proven that actually what they want is fun."
Fuck IPV6. Can't we just have a 36-bit or 48-bit IPV4 and keep everything else the same?
Think IPv4 PAE.
"feature parody"?
time to move off of norton then
i mean we all are just waiting on akamai, because without akamai ... or not.
nobody could run dns
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.
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.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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...
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)
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
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
APNIC (Asia) is already on the last /8 block: http://www.apnic.net/community/ipv4-exhaustion/graphical-information
ARIN (North America): http://www.compusophia.com/en/ipaddrstat/ipv4_arin_pool.html
LACNIC (South America): http://www.lacnic.net/en/registro/espacio-disponible-ipv4.html
AfriNIC (Africa):
http://www.compusophia.com/en/ipaddrstat/ipv4_afrinic_pool.html
When those are depleted, it's going to be NAT all the way down.
No, that would require every OS to replace the TCP/IP stack. No backwards compatibility and no better off than IPv6.
True, but high-end equipment has been able to run IPv6 for ages now.
If they can't get simple HTML/Javascript right, how can I trust them to get anything more complex right?
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?
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
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.
cloudflare is already doinf that for free : http://blog.cloudflare.com/introducing-cloudflares-automatic-ipv6-gatewa
Or buy them on the secondary market. The current price is around $12 per IP.
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.
Jumpstart the tartan drive.
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.
I prefer the "u" in honour as it seems to be missing these days.
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?
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.
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.
Have you got your LWN subscription yet?
Ah, but if only you had the remotest idea of how those 3.7 billion IP addresses are distributed - even within the US alone!
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.
Wah wah, we can't figure out where to put some more bits. There must be just no way. Right.
Have you got your LWN subscription yet?
So when will Slashdot be on IPv6? Inquiring minds and nefarious hackers want to know.
now we need to go OSS in diesel cars
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.
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.
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.
Have you got your LWN subscription yet?
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.
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
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 str
http://blog.nexusuk.org
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. :-)
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 obsoletestream 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.
Have you got your LWN subscription yet?
I've been on Slashdot too long: "IANA... I Am Not A... what? What are you not?? Tell me!!"
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.
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.
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.
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).
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.
"Parody"? Do you perhaps mean parity? Or do you really mean that IPV6 and security equipment is a parody?
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 n
http://blog.nexusuk.org
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.
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.
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.
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.
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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 - 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.
http://blog.nexusuk.org
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.
http://blog.nexusuk.org
ah the MS model
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.
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.
http://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
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.
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.
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.
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.
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.)
http://blog.nexusuk.org
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...
http://blog.nexusuk.org
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.
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 ther
Have you got your LWN subscription yet?
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.
Have you got your LWN subscription yet?
I hope you realize that ICMP does not replace layer 2. And that IPv6 is always encapsulated in some layer 2 protocol like ethernet, just as IPv4 is.
Have you got your LWN subscription yet?
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.
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.
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.
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...
http://blog.nexusuk.org
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.
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.
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.
To connect to an IPv6 user, like a cell phone.
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.
http://blog.nexusuk.org
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.
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.
http://blog.nexusuk.org
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.
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.
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.
Have you got your LWN subscription yet?
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?
Simple: if host A does not understand 5 byte IPv4+, it cannot establish a direct connection with host B. Host A should upgrade if it wants to connect directly to host B. Meanwhile, host B, with a 5 byte address, can connect directly to any IPv4+ enabled host whether the other host has a four or five byte address. To connect to an unaware IPv4 host, host B needs some help from a NAT. This is where having the fifth byte on the low order end is really helpful: the NAT does not need to be stateful and does not need to delve into protocols. It just needs to manage its pool of dynamic IPs as dynamic IP shemes already do.
Now here is the thing: dotcoms can run a 5 byte-aware stack while having a 4 byte address themselves. Unlike the big adminstrative headache of IPv6 dual stack, all the dotcom needs is the equivalent of apt-get upgrade. So IPv4+ traffic can just grow organically as routes appear and hosts come online, and there is none of this take a leap of faith and jump off the cliff into the huge, empty IPv6 internet that has dogged IPv6 from the start.
Have you got your LWN subscription yet?
How does host B know if host A will be able to receive host B's message?
Simple: if host A does not understand 5 byte IPv4+, it cannot establish a direct connection with host B. Host A should upgrade if it wants to connect directly to host B. Meanwhile, host B, with a 5 byte address, can connect directly to any IPv4+ enabled host whether the other host has a four or five byte address.
The question remains unanswered. How can you tell whether Host A AND your specific path to Host A supports IPv4+? Do you just try it.. if request times out assume it does not have connectivity? This delay is not commercially viable. What if the host was down or routing changed thru a router without support for IPv4+..how do you know? How does it work?
To connect to an unaware IPv4 host, host B needs some help from a NAT. This is where having the fifth byte on the low order end is really helpful: the NAT does not need to be stateful and does not need to delve into protocols. It just needs to manage its pool of dynamic IPs as dynamic IP shemes already do.
It most certainly needs to keep state... 1 real IP shared by a bunch of fake (IPv4+) IPs requires state to manage the 1:many association on the real IP. Running out of IPv4 addresses has consequences. Thinking there will be a "pool" of addresses is like attempting to alert your phone company of service outage via the same phone effected by outage.
Unlike the big adminstrative headache of IPv6 dual stack, all the dotcom needs is the equivalent of apt-get upgrade. So IPv4+ traffic can just grow organically as routes appear and hosts come online, and there is none of this take a leap of faith and jump off the cliff into the huge, empty IPv6 internet that has dogged IPv6 from the start.
I don't need to type apt-get cause all my toys are already IPv6 enabled. It takes an ISP to route me an IPv6 address the same as it takes an ISP to route me an IPv4+ address.
Your IPv4+ universe is the same empty cliff DISCONNECTED from the IPv4 universe. There is no direct communication possible without a NAT device the same way there is no direct communication possible between IPv4 and IPv6.
Deploying IPv4+ only is about as worthless as deploying IPv6 only without a NAT. The only difference is the end state.
With IPv6 at the end of the day you turn off IPv4 network/NAT when the transition is complete enough for your taste. You will easily know when this is because you will no longer be connecting to any IPv4 addresses.
With IPv4+ at the end of the day you turn off the NATs and pray cause you'll have no clue who is still using what.
How can you tell whether Host A AND your specific path to Host A supports IPv4+? Do you just try it.. if request times out assume it does not have connectivity?
That is how any connection to the internet works.
This delay is not commercially viable.
Only if you assume that a host with a 5 byte address tries to make all its connections directly before falling back NAT. But there is no requirement to do that. A 5 byte host can always use its ISP's nat, except when it discovers another 5 byte host via some out of band mechanism. For example, two users may be interested in establishing a secure connection for conversation or telephony, in which case they can well afford to take a few seconds to establish their route.
What if the host was down or routing changed thru a router without support for IPv4+..how do you know?
Hmm, it almost sounds like you have never experienced loss of internet connectivity. Never lost connectivity due to a routing loop? Then you haven't been on the net long. How it works is: nothing changes, it is just like the internet we all grew up with. Maybe it is different from some ideal you have in mind, but this behavior is in no way different with IPv6.
Your IPv4+ universe is the same empty cliff DISCONNECTED from the IPv4 universe.
Completely wrong. A 5 byte host is no more disconnected from the internet than an IPv6 host is today. See 6to4
OK, you are just hammering away at the same difficulties that IPv6 has and trying to assign these problems exclusively to IPv4+. I guess that means you ran out of points. Here is my point: there is such a notion as "more compatible". There is no bifurfaction of the form "either completely compatible or completely incompatible" which is used to justify the excessive compatibility break cheerfully engineered by the IPv6 committee, which has proved so dismally uninteresting to potential adopters in practice. IPv6 adption shortfall is not speculation, it is an easily verifiable fact. And it is blindingly obvious that throwing any effort at compatibility to the wind is the reason for this.
For a good example of a successful incompatible-but-compatible design, look at AMD's x64 effort. The 64 bit instruction set will not run 32 bit programs unaltered, but the designs are a similar enough that programmers could easily deal with the differences. Not perfectly compatible, but compatible enough. That point is the central one that IPv6 boosters are unable or unwilling to understand.
Have you got your LWN subscription yet?
OK, think about this. Clearly, IPv4+ will work just as well as plain IPv4 if you have a 4 byte address, whether that is static, or like the vast majority of connections today, dynamically allocated from a pool owned by the ISP. Now in addition you have the option of giving 5 byte addresses to up to 256 computers in your house or business or village sitting behind your four byte IP. These will all act just as if they had a four byte net-local IP, but in addition they all have globally routable addresses for whatever segment of the internet has also adopted 5 byte addresses. At least that is something, don't you agree? Or don't you?
All you had to do to get that was run apt-get upgrade. And don't fool yourself, you had to do that at some point to get your dual stack too.
Have you got your LWN subscription yet?
Routing tables and layer 2 still exist. It's just a differently sized header, and protocol version.
I can throw myself at the ground, and miss.
Only if you assume that a host with a 5 byte address tries to make all its connections directly before falling back NAT. But there is no requirement to do that. A 5 byte host can always use its ISP's nat, except when it discovers another 5 byte host via some out of band mechanism. For example, two users may be interested in establishing a secure connection for conversation or telephony, in which case they can well afford to take a few seconds to establish their route.
IPv6 uses naming system and standardized default host policy to avoid all of this guesswork. Saying if you don't use IPv4+ ("always use its ISP's nat") then its not a problem is rather telling. "out of band" is punting to a magic unicorn that in many cases does not exist.
Adding delay and unpredictability to the current system is not going to fly with content. Whatever we transition to needs to be at least as good as IPv4 if we expect content to be a driver for adoption.
Your IPv4+ universe is the same empty cliff DISCONNECTED from the IPv4 universe.
Completely wrong. A 5 byte host is no more disconnected from the internet than an IPv6 host is today. See 6to4
You can bridge them using a number of packet mangling bridging/tunneling devices if your clever at the end of the day IPv4+ hosts can't talk directly to IPv4 hosts. The address space is too small. There is no possible return address the IPv4 network understands to send a reply.
OK, you are just hammering away at the same difficulties that IPv6 has and trying to assign these problems exclusively to IPv4+. I guess that means you ran out of points
Please go back to my previous post and read it. I contrasted both networks and showed that the same problems exist in both. The problems that are exclusivly the domain of IPv4+ is unpredictability and unreliability.
IPv6 adption shortfall is not speculation, it is an easily verifiable fact. And it is blindingly obvious that throwing any effort at compatibility to the wind is the reason for this.
A lot of smart people tried and failed, multiple times... The number of transition technologies avaliable and still being cookied up is amazing and confusing. Almost as amazing as the number of seemingly good ideas that were later found to not be operationally viable.
The latest fad from softwires in Asia seems to be deploy IPv6 only and use it to backhaul IPv4 to CGN. Since IPv6 has a bigger address space they just map the global IPv4 to an IPv6 prefix .. like the depricated ::1.2.3.4 notation with some DNS tricks to make it all work. Certainly has its problems but works for the most part.
Most of the really creative concepts like using BGP anycast (6to4) to give v4 only hosts a voice on the IPv6 network turned out to cause more trouble than they are worth because of their unprdictability in terms of performance, scalability and reachability coupled with failure to work through NATs.
Paradoxically it is better to have no IPv6 connectivity at all than have crappy IPv6 connectivity because crappy connectivity scares and holds back content from deploying rather than encouraging adoption and feeding a positive loop.
The core issue is the IPv4 space is smaller than the IPv6 space and you can't address all of the possibilities in the IPv6 network using an IPv4 address no matter what you do...(Excluding of course the use of Mr Terrell's ternary logic) ... There is no working around this without a packet mangler. Whatever is done requires changes to the entire infustructure anyway..If your going to have to do mostly the same work regardless might as well do something that has a chance of lasting.
For a good example of a successful incompatible-but-compatible design, look at AMD's x64 effort. The 64 bit instruction set will not run 32 bit programs unaltered, but the designs are a similar enough tha
OK, think about this. Clearly, IPv4+ will work just as well as plain IPv4 if you have a 4 byte address, whether that is static, or like the vast majority of connections today, dynamically allocated from a pool owned by the ISP. Now in addition you have the option of giving 5 byte addresses to up to 256 computers in your house or business or village sitting behind your four byte IP. These will all act just as if they had a four byte net-local IP, but in addition they all have globally routable addresses for whatever segment of the internet has also adopted 5 byte addresses. At least that is something, don't you agree? Or don't you?
I think that would be really cool to have 5 bytes instead of four so we call get an extra 256 hosts per address.
Unfortunatly while cool the problem is the world is running out of IPv4 addresses. This means there will be no more 4-byte IPv4 addresses left under which an extra 256 computers could be made avaliable. The IANA free pool and APNIC are now mostly deserts and everyone else except afrinic will be deserts in a year or two.. Even the emergency reserved morsels to facilitiate IPv6 transition will eventually dry up.
...there will be no more 4-byte IPv4 addresses left under which an extra 256 computers could be made avaliable.
Not a problem, addresses already recycle regularly. Nearly every time you relocate your home, for example. Or every time you connect if you subscribe for a dynamic address like most people.
Have you got your LWN subscription yet?
Ah, and the point is that an ISP could put multiple subscribers behind one four byte address. And it would be better than today's NAT, which is limited by available port addresses and is really a nasty, nasty kludge. And 5 byte address owners can establish direct connections with each other.
Have you got your LWN subscription yet?
Ah, and the point is that an ISP could put multiple subscribers behind one four byte address. And it would be better than today's NAT, which is limited by available port addresses and is really a nasty, nasty kludge. And 5 byte address owners can establish direct connections with each other.
We're going to spin new ASICS, patch all network, naming, application stacks, databases and backends all to accept an extra byte..essentially the same work needed to deploy IPv6 then at the end of all that we still have NATs and severe addressing problems?
Say you wanted to be an ISP and picked up a shiney new 4-byte ASN with your name on it. What would you expect to be able to route to your customers after all IPv4 addresses are long gone?