El Reg & IPv6
I think El Reg looks for anti-IPv6 material just to run stories that they can use as a reason that they haven’t deployed it yet.
We've discovered another reason why IPv6 is, right now, a poor substitute to IPv4: fisticuffs have broken out over the protocol on the internet's trunk roads, causing traffic jams. In a report this month by Qrator Labs, researchers dug into what they are calling national internet reliability: the ability of a country's …
"the big players extort the small ones, who want to have a free ride on the big ones."
Isn't that how capitalism is supposed to work?
Of course, there is always the old Russian joke. "Everything Marx told us about Communism was wrong. Unfortunately, everything he told us about Capitalism was right."
As the perpetrator of the famous cake stunt mentioned/pictured in the article, I think I have some deeper than average knowledge of this situation.
I would not call either HE or Cogent a small network trying to freeload off the other.
The simple reality is that this is an absurd pissing contest between commercial rivals that have dug in their heels to the detriment of consumers and customers on both sides. Personally, I happen to feel that HE has the more reasonable position here, but not by a wide margin.
The bottom line is that this isn't so much an indication that IPv6 isn't ready for prime time... It's an indication that not enough people have adopted IPv6 and started pressuring providers to make it production-grade.
I thought an anti-IPv6 article was a refreshing change given their usual articles telling people to get on and more to IPv6.
IPv6 is not perfect, it could have allowed for this eventuality but the design teams were packed with people who thought that commercial decisions could be ignored.
Bring on IPv7, with additional health benefits and twice the amount of protein.
"Bring on IPv7, with additional health benefits and twice the amount of protein."
Perhaps we should hold off on IPv7 until we see some signs that IPvX specifiers have actually learned something from the world's failure to enthusiastically embrace IPv6. Next time maybe they ought to take backward compatibility a bit more seriously.
(There are,BTW, a number of medical conditions associated with excessive consumption of protein. Some of them are probably imaginary of course. But some aren't.)
As usually the first person to launch on them when they do so...
This article is probably deserving of a reprieve as it's discussing actual problems with IPv6 (rather than praising it and ironically telling us we're all stupid if we haven't already done it) and not discussing home/commercial deployments, but the back-end infrastructure.
" anti-IPv6 material"
Nope.. fact-is, the proliferation of IPv6 is so far really small. Its not for a lack of product or consumer support, my Router has supported it for the past 8 years, few mainstream ISP actual utilise it. The reason is, they are still bitching and biting each other in the background.
This article touched the next level idiosyncrasies of the Internet. Nevertheless, if the IPv4 version is working fine, why go through the trouble to IPv6? Of course, everyone talks about IPv4 address pool has been depleted. However, this baseline seems to be questionable from our analysis.
The main reason that IPv6 has not been rolling out smoothly is because it ignored the first rule of engineering in upgrading a working product / system, i.e., the backward compatibility to IPv4. Had it done so, the transition would have been completed a long time ago without even being noticed. Marketing type of persuasion has its limits, especially after nearly ten years if we do not count that development actually started two decades ago. At the current pace of electronic products, it has been nearly half dozen of so life-cycles already!
Our background in telephony enabled us to approach this Internet challenge from the knowledge of the PSTN (Public Switched Telephone Network) that developed practices to expand the assignable telephone numbers through the PABX (Private Automatic Branch eXchange) and the lesser known CENTREX (CENTRal office EXchange) technologies.
Instead of digging into the telephony details, we have submitted to IETF a proposal called EzIP (phonetic for Easy IPv4) about the solution from the networking perspectives:
Essentially, EzIP utilizes the very original IPv4 standard RFC791 and the long-reserved yet hardly-used 240/4 address block to expand each IPv4 public address by 255M (Million) fold. This is capable of serving an area with population up to about 39M which is larger than the largest city (Tokyo metro) and 75% of countries on earth. This capability not only enables governments, but also individuals to offer local sub-Internet services parallel to the current global version. There are other benefits such as mitigating largely the root cause to cyber security issues.
These render IPv6 unnecessary. Now, we can focus our resources on IPv4 and try to improve its performances.
Thoughts and comments would be much appreciated.
Abe (2018-08-28 23:06)
Under the Dual-Stack environment, the answer is "No". However, now that the main handicap of IPv4 is eliminated, it can compete against IPv6 and the users may make their own informed decision about which way to go.
Abe (2018-08-29 13:59)
Sounds like a stop-gap measure to me, and adding an awful lot of complexity into what was a very simple system for routing.
But I'll show you the death-knell:
"Many implementations of the TCP/IP protocol stack have the 240.0.0.0/4 address block marked as experimental, and prevent the host from forwarding IP packets with addresses drawn from this address block"
It will take you longer to find and remove such blocks over the world's legacy systems, in order for their "ordinary" IPv4 network to work as intended than it would to just deploy IPv6.
Hell, adding in use of a SINGLE BIT for ECN basically forced router upgrades world-wide, gave you an option in Linux to turn them off (still there I believe!) which many people used, and which stopped traffic routing to some pretty major destinations. Even when it was supposed to be an unused bit up until then.
Sorry, but it's dead. IPv6 is a specified requirement of DOCSIS, 4G+ technologies, in every major current operating system, accounts for 20% of Google queries and works. Nobody's saying it's perfect, but a far-too-late, far-too-complex system to extend IPv4 use and complicate the routing tables even more just sounds like a terrible solution at this juncture.
Hi, Lee D:
1) You might have read the quotation that you cited incorrectly. That is, by citing the road block faced by the prior art, we would not have presented the EzIP approach without a definitive solution around it.
2) What we did is to transport the 240/4 address as if it were any binary information carried by the EzIP header as its payload. Thus, all existing routers would not recognize it, and consequently will only forward the IP packet to the destination identified by Word 5 of the header. It is only the SPR at the destination that has the intelligence to decipher and then routes the packet further accordingly.
3) Since the EzIP is only extending an IPv4 address at its destination, there is no new "routing table" (global) entry to talk about. Of course, for routing 256M addresses in the 240/4 block, a "local" routing table will be needed that is created and maintained by the local IAP (Internet Access Provider).
4) "... 20% of Google queries ... ": Do not be misled by this kind of marketing numbers. Please have a look at the following regularly (about every 15 minutes?) updated worldwide statistics. It is being done by a neutral party. The graphs are very surprising. At the first glance, you may even question what are they presenting?
Abe (2018-08-29 14:22)
Measuring traffic size against queries is very disproportionate traffic to compare.
20% of Google queries come in over IPv6. It's that simple.
But one MP4 on YouTube could easily equal millions or billions of such queries. That the content providers aren't pushing stuff over IPv6 for their video CDN doesn't mean it isn't being used.
The rest of the implementation is just reminiscent of the whole range of 6to/in/over/etc.4 technologies. It's basically proxying "extra" IPv4 to/from a reserved address, over IPv4 packets to an endpoint capable of expanding them as necessary. Though traditional routers may be able to route such traffic, it requires all kinds of intermediaries to actually do the work, who could do the same work for IPv6 instead and you'd never need know.
I can't see it. Maybe 20 years ago. Maybe if there weren't everything from 6rd to 6-in-4 to all the other tunnelling protocols then you might able to do something. Fact is, you're not in any mainstream OS or router - they already are. With a 20 year headstart. And actually progressing out - they are all a ladder to the final salvation of native IPv6 for everyone, you're just circling round the bottom of the pit chopping rungs off the ladder.
I can't see it getting or going anywhere.
Hi, Lee D:
1) "Measuring traffic size against queries is very disproportionate traffic to compare.": If your mindset is from this angle, we shall not debate on which protocol is in more use.
2) Let's not get too deep into technologies. What I did not say (even the Draft only touched the surface) is what is the implication of one single IPv4 address able to serve an area of 256M IoTs. This opens up the PSTN equivalent of "Interconnect" business in the Internet.
3) That is, not only a government, but any individual can provide Internet services in a local area in parallel to the current global version. This is the type of open market competition that big Internet players have been bragging about knowing full well that there was no resource to do so. Now, there is. Not just a few, but there will be millions or even more competitors!
4) There is even a modern day analogy to the above. That is, the electric utility grid is supporting the islands of renewable energy generated by homes and businesses.
Abe (2018-08-29 16:39)
My understanding is that one of the few (maybe the only) actual benefits from IPv6 is more compact routing tables.
That's not really much of a benefit.. At least now old routers that didn't have enough memory for a full routing table have been retired. And relatively few routers actually need a full table anyway.
Issue's really around IPv4 address depletion. There are plenty of underutilised V4 addresses, especially in the legacy 'swamp', where early adopters ended up with /8s or large blocks that they didn't really need. That was further complicated by speculation and treating IPv4 blocks as an asset, eg Microsoft buying Nortel's old space. Theoretically, that should have been returned to the RIR who could then parcel it out to other users that could justify it.
As for using 240/4.. It would mean deleting it from ISP's 'bogons' filters, which are just a list of networks that shouldn't be routed externally. That's an easy config change and shouldn't be hard-coded anywhere. Or if you're nice and use the full bogon's list, it's here-
and can automagically get baked into BGP filters via their tools.. But there's a fair bit of address space there. Some, like 0/8 would confuse people who don't get subnet zero, others like 10/8 would confuse more. But 240/4 shouldn't have been used in any production networks.. But that doesn't mean it hasn't been, ie companies trying to avoid clashes inside 10/8 space.
So it's a reasonable proposal, but unlikely to gain traction given IPv6 is the solution.
Hi, Jelled Eel:
1) Thanks for the information about the IPv4 address pool swamp history. Yes, I was fully aware of them and knew it was so convoluted that it is practically impossible to dig into. So, we decided to pick the 240/4 block. It was kind in the "never land" since no router is allowed to touch it. And, it obviously is a joke to keep it still "Reserved for Future" while IETF is doing everything to kill IPv4.
2) By designing the SPR as a full spherical layer of new routers between Internet's ER and subscriber premises, SPR will not intermingle with existing routers. There is no need to modify any existing routers.So, your concerns may not apply.
Abe (2018-08-29 15:56)
Getting it out of millions of individually managed devices is a non-starter.
Or a software update. And some user education, which may be harder given the number of people that still refer to class A/B/C networks post-CIDR. So if I attempt to configure 240.x on a Win10 box, it goes 'bing' and tells me valid IP addresses are 1-223.. Which leaves a lot of unused IPv4 addresses denied by an ancient policy and an implementation of that rule.
Hi, Jellied Eel:
1) "Getting it out of millions of individually managed devices is a non-starter.": Where in the EzIP IETF Draft did you get this idea? With CG-NAT equivalent service built-in, all current IoTs will continue to function as they are designed for with SPR in place. It is only those IoTs that are enhanced (or factory preset when manufactured) will be able to take advantage of the simple EzIP router service. It is a gradual process at the individual customer's discretion. This is very much analogous to how Dial-Up modem got PSTN to begin serving as the infrastructure for the early Internet operations. (First was bulletin access which is equivalent to Internet's web-access. With enough Dial-Up modems, subscribes began to transfer data directly, or end-to-end connectivity.)
2) What is behind the scene is that the EzIP is best deployed in developing regions or rural areas of developed countries where IPv4 address is definitely in short of supply. They are lacking of not only IoTs, but also infrastructure. So, all the new equipment for them can be factory preset with EzIP-capable OS, F/W and S/W, etc. The urban areas of developed countries with EzIP-unaware IoTs will be the secondary target.
3) In addition, with the sub-Internet deployment configuration, those disadvantaged regions will be enjoying EzIP services more or less autonomously, without much reliance on the developed regions. Then, the latter can play catch-up if desired.
Abe (2018-08-30 11:28)
1) There is no new entry to the existing "global" routing tables because the 240/4 routing takes place only at each individual IPv4 address end point. Of course, the party who serves as the local IAP (Internet Access Provider) will have to create and maintain his own "local" routing table.
2) Since the use of the 240/4 block through the EzIP scheme will consolidate many of the current IPv4 addresses into one, the global routing table actually should get more compact.
Abe (2018-08-29 14:33)
The main reason that IPv6 has not been rolling out smoothly is because it ignored the first rule of engineering in upgrading a working product / system, i.e., the backward compatibility to IPv4. Had it done so, the transition would have been completed a long time ago without even being noticed.
Both NAT64 and NAT46 provide backward compatibility. Maybe you mean the IPv6 mainstream idea that NAT *cannot ever* work with IPv6? It is the ideas of the NAT haters have have *tried* to force IPv6 without NAT, which has taken out the idea of any possibility of backward compatibility. Funny, the NAT haters can unite, but will always lose their poor battle, all because the rest of us have been using this backward compatibility for many years now.
The 240/4 proposal, that is -- but AbeChen and gnarlymarley, et al. make a good point. The arrogance of proposing the wholesale replacement of the standard that the Internet was built on with a "new" and non-inclusive standard was not only socially inept, but a major engineering fail. Doubling down by rejecting solutions like NAT64 only makes it worse. After 20 years an objective mind might think, "I guess the market has spoken".
By this point in early computer history TCP/IPv4 had roared ahead of its rivals and made the expansion of the Internet possible.
The 240/4 proposal is a good stopgap and should definitely be pursued, but the "never NAT" IPv6 purists also need to give up on their opposition tot NAT64, which was itself proposed as early as 2002. Had NAT64 been supported back then, the transition to IPv6 might have been successfully completed a decade ago.
0) Maybe you can answer my puzzlement.
1) That is, where NAT64 or NAT46 is positioned, isn't it ideal to put a caching proxy as a gateway serving the same purpose for a block of subscribers that an IAP (Internet Access Provider) is serving? This will leave the current IoTs alone, and let the transition move at its own pace.
2) In our work, we identified that a caching proxy would serve the purpose of translating IPv4 public address used in the Internet and the EzIP extension address used in the sub-Internet, because the two port configuration.
3) What was the reason holding IAPs from doing so? Were they so aggressive that they wanted to push all IoTs to be IPv6 compliant right away?
Abe (2018-08-29 15:37)
> The arrogance of proposing the wholesale replacement of the standard
> that the Internet was built on with a "new" and non-inclusive standard was
> not only socially inept, but a major engineering fail. Doubling down by rejecting
> solutions like NAT64 only makes it worse.
Purists may have said NAT66 isn't needed, but that doesn't stop you using it. It can be done.
And as for NAT64, I don't know what you mean by 'rejecting' it - it exists too.
When you consider all the NAT66/NAT64 options, along with the other transition mechanisms, like 6in4, 6over4, 6to4, ISATAP, DNS64, SIIT, MAP, Terodo........... what else could be done?
How can you make a protocol which requires an extended header to be backwards compatible? Do you think there could be a scheme where sometime we'd get addresses like 218.104.22.168 - if we did, it would require an extended header, which would require a new protocol - and these magic addresses won't just work with old stacks.
Please, someone for once just explain how a protocol offering more addresses can be backwards compatible with one offering less? How would you make ip4 stacks magically be able to connect to an expanded space without modification?
Hi, Anonymous Coward:
1) ".... what else could be done? ": One simple alternative is put them all aside and go back to the basics. That is, RFC791 was released back in 1981. If it can resolve the current issue, why get everyone dizzy with all the new protocols that individually does only the job partially while creating other issues?
2) "How can you make a protocol which requires an extended header to be backwards compatible? ": The "Option Word" mechanism does not extending the IP header. It is part of the original format! There is nothing new in terms of defining a new protocol. All TCP/IP stacks should have been routinely handling it all the time (whether it exists in a header or not). Strictly speaking, EzIP is just using the facility in an old protocol. As pointed out in the IETF Draft, there were at least two prior cases (One is dated back in 1992) making use of this mechanism for extending the address pool. To give the credit where is due, what EzIP is using "predicted / imagined" by the original designer of the RFC791.It is called forward-thinking. I am using the backwards compatible expression to just go along with the common daily phrases.
3) "How would you make ip4 stacks magically be able to connect to an expanded space without modification? ": There is no magic. Remember that I brought up the reference to telephony technologies? If you are familiar with how CENTEX and PABX get their phone numbers to effectively expand the PSTN public phone numbers, EzIP numbering scheme is pretty rudimentary. EzIP is not dreaming up a magic block of numbers but only recovering them from the "never land". It was rather perplexing when we discovered that the 240/4 block has been "Reserved for Future Use" since 1981-09, while IETF tried to "SunSet" the IPv4 and eventually "concluded it which means that IPv4 has no future anyway.
Hope these help.
Abe (2018-08-30 08:37)
As pointed out in the IETF Draft, there were at least two prior cases (One is dated back in 1992) making use of this mechanism for extending the address pool
The history of the IETF is rich in poor decisions. So here's an example-
Discussing the future Internet architecture and the deficiencies with the pre-1991 version. That referenced an older idea by Van Jacobson that would've solved the problem, albeit in an.. interesting way. As a bonus, it would also have allowed more efficient routing. But the IETF were wedded to their Class A/B/C drugs, despite pressures to switch to CIDR. Which received many of the same objections, ie too hard, would need system changes etc etc. But it also threw out the idea of 64bit address fields, and the genesis of IPv6.
So a complete re-write, dual stacks, confusion and too few people asking 'about all that unallocated space..' :)
Hi, Jellied Eel:
1) Thanks for the reference to RFC1287. However, not only it predated (1991) so much from Reference  (2008) of the EzIP IETF Draft, but also only theoretically suggested extending to 64 bit address system. The former means that the authors of the Reference  would definitely know about it because their involvement with the Internet covered much longer period than that. The latter implied a lot of changes to deployed equipment. By treating the additional 32 bit address as IP header payload, EzIP becomes transparent to all existing Internet equipment, CR, ER, RG, etc., hence the Stupidly Simple scheme.
2) As described to "Alan Brown", EzIP is being reviewed by a couple of precisely those people involved back then, even though the only IPv4 activity in IETF was SunSet4 WG which has been "concluded" this past May. They have been chewing on EzIP proposal for near one month without comment, after a couple initial clarification questions, that I would classify as very pointed with substance, without vague general objections. So, to expedite this discussion, may I request you to approach from the similar angle by applying you knowledge in the Internet history? (As I professed in the EzIP Draft document, I know hardly anything about the Internet.)
Abe (2018-08-30 12:03)
(Re your earlier quote, it wasn't me who suggested millions of devices would need updating, that was Alan Brown..)
But I think the issue is best summed up by this line from the EzIP abstract:-
These proposed interim facilities would afford IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.
So political, rather than practical. Millions have been spent on creating IPv6 awareness activities to encourage and promote the exciting new Internet. That flows though into other activities like sunset4 WG, for example:-
This includes the act of shutting down IPv4 itself, as well as the ability of IPv6-only portions of the Internet to continue to connect with portions of the Internet that remain IPv4-only.
So they came to bury Internet v4, not to extend it. Which is partly the issue, ie the creation of IPv6 meant an entirely new protocol with limited or no compatibility between it and it's predecessor. Once it was decided that the 'fix' was IPv6, activity shifted to mostly making that happen.
That activity is then mostly driven by the vendors and ops community. So IPv6 sounds nice, where's my IOS/JunOS that supports it? Or supports it in such a fashion that my routers won't fall over regularly? That's where simple is good, ie minimal modifications to protocols so expensive ASICs or offload silicon doesn't need redesigning. That's also where proposals to utilise unused bits, option fields or headers kinda fall down. So core routers spend most of their time simply looking at the first few bytes to get enough header info to route/forward/switch a packet onward. Having to look deeper is more computationally expensive, which translates into $$$, and also often power budgets.
That's also the challenge with edge/overlay approaches like EzIP, ie getting someone to implement it, even if it might make sense. And many years ago, I asked Jon Postel at a NANOG meeting about the reserved addresses and the answer was basically IPv6 is the future.
Biting the hand that feeds IT © 1998–2019