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 2126.96.36.199 - 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.
Hi, Jellied Eel:
1) "(Re your earlier quote, it wasn't me who suggested millions of devices would need updating, that was Alan Brown..) ": Sorry for the misquote. It was a bit difficult for me to keep track of the short messages on this forum because it does not provide individualized notification for response. To minimize the mis-correlation, I tried to open my writing by addressing the person whom wrote the comment that I was responding to. In this case, you caught my cross-correlation among several comments arrived at the same time. My apologies, although my general comment stands.
2) "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 " : Yes, you are correct! Knowing the controversy of the general environment, the EzIP Draft was phrased as diplomatic as possible in order not to offend others with different mindset.
3) ". ... 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. ": Yes, the whole thing is incredibly convoluted among technology, business, politics (domestic and international) and personal ego. It has gotten to the point that If we try to dig into any one of these, we can waste an awful amount of energy and resources. So, if we want an alternative solution to this mess, it has to be modular enough for local deployment as the starting point. EzIP provides such facility to establish the Internet's equivalent to PSTN's "Interconnect" business (PABX as one of the main vehicles). Like it or not, Internet governing bodies can not stop someone providing sub-Internet services from one IPv4 public address, based on EzIP. It blows apart many of the Internet marketing banners. This is the punch line that I believe why EzIP is getting the attention from formal organizations now.
4) As I outlined to Nanashi an hour ago, let's focus on the technical merits of the EzIP technique itself, now that both sides (private and government) of the major organizations (IETF & ITU-T) on the subject have been informed of this technology. That is, if there were any fundamental flaw, either side would have shot the EzIP down already, instead of spending resources to evaluate it. From my limited knowledge of the networking, anything beyond RFC791, 240/4 address block, RG-NAT & CG-NAT makes my eyes watery. If we can stay within the boundaries of these few subjects, I am sure that more colleagues will be interested in participating the discussion. All the unnecessary advanced terminologies, especially those related to IPv6 just discourage many by making them feel inadequate or ill-equipped, which is counter-productive.
Abe (2018-08-30 15:24)
1) What I am saying is that IPv6 itself is not backward compatible with IPv4. I did not comment on the good services provided by NAT64 and NAT46 that make the two compatible, although at the expense of one extra layer of protocols.
2) The primary goal of the EzIP approach is to provide a simple new layer of routers utilizing no new protocol but the original RFC791. In fitting into the existing Internet configurations, we saw the utility of the CG-NAT for bridging the gap between the EzIP-unaware IoTs and the new service. So, we integrated it into the EzIP implementation module SPR (Semi-Public Router) as described in the IETF Draft.
3) SPR provides the appropriate connection service depending on which type of IoT is initiating a session. Appendix A. describes the operation details, while Appendix B.2. outlines the logic that determines the choice of service. These maintain the connectivity for the EzIP-unaware IoTs during the transition. With enough addresses in the 240/4 block and the straight router service from SPR, we hope that the EzIP-unaware IoTs will eventually fade out on its own, but not by force.
4) This is very much analogous to the rotary dial to DTMF dialing transition. The latter is much better in practically every aspect, while there were a lot of the former. Although the latter is dominant now, there are still some former types in use. The PSTN accommodates both all the way along. The intention of the EzIP is similarly deploying one solution with both EzIP-unaware and EzIP-capable IoTs in mind.
Abe (2018-08-29 15:04)
The 240/4 proposal is no more backwards compatible than IPv6. Once you consider all the likely combinations of "aware" and "unaware" endpoints and intermediates, you conclude that everyone's stack needs to be at least partially aware. That means writing, testing and deploying dual stack software on zillions of existing boxes. For IPv6 that task has largely been done. For any and all rival proposals, you are twenty years behind.
1) You might have misread the EzIP architecture. The only implementation module is the SPR (Semi-Public Router) that is to form a full spherical layer of simple routers as inline devices between the ER (Edge Router) and subscriber premises. The existing components do not need be EzIP-aware, but continue the operations as if they were under the current CG-NAT configuration.
2) Only if an EzIP-capable IoT initiates a session with EzIP header will the connection service be upgraded to EzIP router mode.
3) So, we are not going to modify any existing Internet components including IoTs in the field.
4) Perhaps the diagram in page 8 of the following would provide a better picture:
Abe (2018-08-29 16:13)
As a network engineer, there are two key problems with IPv6 that are holding back deployments in environments that have yet to move:
- it costs money to move and so far, the cost of not moving or using existing workarounds outweighs the benefits of moving for the majority of the existing user base.
- it's a little different from IPv4. Not much but enough to make enough things break or need tweaks that large environments won't move unless pushed. This is the "fear of change" rather than the cost implications, as there are still memories of getting the stack fully over to IPv4 in the last 10-15 years...
The workaround you suggest are affected by both issues and IPv6 has significantly more real-world testing AND scalability.
Hi, Anonymous Coward:
0) Thanks for your comments.
1) Yes, the challenge for IPv6 is that it is not an incremental change because it is not even backward compatible to IPv4. So, the cost is higher than reasonable. And, it does not promise enough benefits to justify the cost.
2) However, EzIP does not have your concerns. EzIP is formulated with not only backward compatibility to IPv4 by relying on only RFC791, but also incremental deployment in mind. It was designed from system architecture, not technology, point of view. And, the implementation has only one functional module, called SPR (Semi-Public Router) that is intended to be installed inline between an ER and the subscriber premises that it serves. Furthermore, the SPR consists of not only the eventual simple router, but also the CG-NAT function for transitional support of serving EzIP-unaware IoTs. So, the SPR may be installed wherever needed, not relying on any other parts of the Internet. In other words, all of the concerns identified by you have been designed out of the SPR.
3) The above may sound too idealistic to be explained over this kind of short forum chats. To expedite this dialog, allow me to share my LinkedIn profile. It would provide you some idea about the disciplines that I was trained for, thus the list of unspoken criteria applied to the EzIP project:
I look forward to your comments.
Abe (2018-08-29 22:48)
1) Thanks for your comment. I had the honor of learning from two great professors who taught me the "same" principle. That is, instead of being distracted by "multitudes of manifestations", one must trace back to the origins of similar subjects. Once the "common source" is identified, a "parallelism" may be established between two or more systems. Life becomes "simple".
2) For the incident case, please have a look at the diagram on page 12 of the following that pairs the PSTN with the Internet:
3) To paraphrase a politically incorrect phrase, KISS - Keep It Stupidly Simple.
Abe (2018-08-29 15:21)
".....backward compatibility to IPv4."
Idiots do like to prattle on about hthings they have no clue about.
IPv4 CAN'T be made compatible with IPv6 or vice versa. If it could have been done it would have been done. Kludging solutions were looked at and found to be even harder to implement than just using a clean sheet and dual-stacking.
And before we get yet another round of clueless raving about "ivory tower academics", fuck off and look at the actual list of IPv6 developers. It's full of senior engineers at networking companies trying to find a solution that can be implemented ONCE and not have to be redone every 20-30 years into the forseeable future.
"Essentially, EzIP utilizes...."
An idea which was looked at and discarded 20 years ago as being a useless kludge as it would buy an extra 5 years at most, whilst costing massive extra complexity AND STILL requiring a move to IPv6 in the long term.
Do the words "Heath-Robinson" or "Rube-Goldberg" mean much to you?
Hi, Alan Brown:
0) You posted consecutive three separate comments which are difficult to respond with the format of this forum. So, I will just start with this one that has the most critical subject that I like to share.
1) "An idea which was looked at and discarded 20 years ago as being a useless kludge as it would buy an extra 5 years at most ": I believe that you are referring to a long series of activities leading to the 2008 idea in Reference  of EzIP's IETF Draft document.
A. For sure, if we did not believe that EzIP has surpassed that last hurdle, we would not have mentioned it as "Normative ".
B. Without disclosing the specifics, I can inform you that a couple of precisely those people involved then have been chewing on EzIP proposal for near one month without definitive comments, after a couple initial clarification questions, that I would say very pointed with substance, but not vague general objections.
2) ".....backward compatibility to IPv4. ": As I explained to " Anonymous Coward", What EzIP is doing is taking advantage of the "forward thinking" that was embedded into RFC791 by its author. It is a more exact expression than the common backward compatibility phrase. In essence, it is one level higher thinking process because it was kind of predicting the future.
3) "As for using 240/4.. It would mean deleting it from ISP's 'bogons' filters, ": Pardon me to say that your mindset probably is still in the time frame of Reference . EzIP is using 240/4 in a different way that is why it offers a new approach (touching no existing equipment) that can last quite sometime to come (by expanding the IPv4 address pool by 256M fold).
Hope these help.
Abe (2018-08-30 10:53)
3) "As for using 240/4.. It would mean deleting it from ISP's 'bogons' filters, ": Pardon me to say that your mindset probably is still in the time frame of Reference . EzIP is using 240/4 in a different way that is why it offers a new approach
It goes back further than that to the 1-line reason why IPv6-
224.000.000.000-255.255.255.255 Reserved [JBP]
And like you say, why all these years later, it's still reserved. Me, being a simple type would say just allocate and route it. It's happened in the past with RIRs, and usually handled by announcements and 'please update your filters' messages.
But I've also seen 240/4 addresses used, ie create a 'legal' VPN using public addresses & then tunnelling 240/4 space. Which was considered 'secure' because 240 wouldn't get routed otherwise.. Which is probably an issue with EzIP given IETF reluctance to support anything that looks like an overlay network. Then there's the general position that IPv6 is THE solution, regardless of alternatives, or whether the problem was well defined.
And also as you say, RFC791 covered a lot of these eventualities in the first place, leaving hooks to support interesting features. It's also a good bit of history, eg the section on security classification bits showing the Internet's heritage.
If anybody cares, I actually went to the effort of getting my head around the linked draft a couple of months ago in the comments to this article:
The short summary is: it doesn't manage to be backwards-compatible with v4 in any way that v6 isn't already. It can't talk to v4 without using either dual stack (which v6 has) or cross-protocol NAT (which v6 has, as NAT64). And it works over the v4 internet essentially by tunnelling, which v6 also has (6to4).
This shouldn't be a surprise, because v4's design isn't forwards compatible, and as a result it's impossible to do direct backwards compatibility in the manner that people seem to want. There is no possible design for v6 that can change this existing limitation of v4.
Any engineer who claims that this lack of backwards compatibility in v6 is an engineering failure on v6's part is themselves failing at one of the fundamental requirements of being an engineer -- the need to understand what they're talking about. If you don't understand the limitations of v4, then you are in no position to insult the ability of the people that designed v6.
If you think I'm wrong, don't just downvote me. Reply with an explanation of how, exactly, you'd make that backwards compatibility work. All you have to do to show me that I'm wrong is to demonstrate how to do it. Put your money where your mouth is, and I'll give you fair consideration, as I did for this draft. But you won't be very convincing if your idea doesn't work, or if it has the same limitations that v6's existing options for backwards compatibility have.
0) I am a person believing in openness, even in debates. This is called mutuality in legal terms (whether lawyers actually do so is a question.). So, before any of us jumping into betting on something, I would like to make sure that everyone is aware of the following:
1) Without disclosing the specifics, I can inform you that a couple of people in the Internet governing bodies who are precisely those involved with this general subject back then have been chewing on the EzIP proposal for near one month without comment, after a couple initial clarification questions, that I would classify as very pointed with substance, yet without vague general objections. Since it is a well-known fact that IETF, etc. have been doing everything to shut down IPv4 related efforts, this situation makes me nervous.
2) By the way, many of the participants on this forum probably are aware of the ongoing debate / dispute between IETF and ITU-T on IPv6 numbering plan, etc. I just got an ITU-T message on my submission of the EzIP Draft that “it was not related with current work items. But the mentioned method is helpful and Q4 experts are encouraged to read it”. This is the result of a very compact online message that I sent to TSB Director due their word restriction in the form. I will follow up with more specific implications.
3) So, to expedite this discussion, I would request everyone to point out any specifics in the EzIP Draft that seems to lead to problems. It would limit the knowledge base to only RFC791 and 240/4 address block, therefore encouraging more participation because no knowledge of IPv6 is required. Fair enough?
Abe (2018-08-30 12:43)
I don't think that ignoring v6 in a discussion of v4 address shortage is appropriate. It's the solution that we've already developed and that we're already deploying. It's extremely relevant.
How can you hope to improve upon v6 without knowing about v6? ...and if you don't plan on improving upon v6, then why should we care?
0) Pardon me to be blunt.
1) Strictly speaking, since IPv6 is not backwards compatible to IPv4 which is the first rule in engineering for improving something that is working, it should have never been allowed to be deployed in the first place. (In the old days when I was working for the largest corporation in the world, such thought would send one out the door and hopefully back to school.) Now that IPv6 had the extra years (20 years of development and 10 years of deployment) to prove itself and still did not work (carrying only about 2% of the total Internet traffic), why should anyone care about safeguarding its welfare anymore?
2) Do you like to see the repeat of the US government bailing out the banking industry because it was "too big to fail", even though they themselves created the disaster by offering the sub-prime interest rate mortgage that old timers like me have never heard of?
3) Similarly, the auto industry was saved by civilian's money after their executives ran them to the ground while making a lot of money of the business.
4) Not talking about the long term prospect of IPv6, just ask what is happening to security breaches everyday. Are they necessary or the result of someone making money unethically?
5) In a sense, we just have to admit the mistake of the current IPv6 and swallow it, then move on with something more reasonable, instead of continue piling new ""6" related sophistication" onto it that fewer and fewer people can understand. What kind of technical empire are we trying to build?
6) Perpetuating something that does not have enough "Kosher" ground to stand upon is immoral in my book. When there was no alternatives to serve as a mirror to check it, we have to bear it. Once there is yard-stick to measure against, we better apply our true logic minds.
Abe (2018-08-30 19:16)
I think the issue is a combination of pragmatism and cold, hard commercial reality.
So a couple of decades ago, it was pretty much decided that Internet v2 would be Internet v6. Then much effort over those decades thrashing out the details, and getting boxes to market that can be used. And starting the painful process of implementation and encouraging migration. Plus some issues like this one, which are commercial/regulatory rather than technical. ISPs have a choice whether to peer or transit, the protocol is agnostic.
That's the Internet for you. It mostly just works, and there's a lot of inertia. So it would be very hard to get the Internet community to change course away from IPv6. Especially given some speed-bumps. Way back, CG-NAT wasn't really recognised as as bigger issue as it's turned out because carrier grade solutions didn't really exist, or were stonkingly expensive and unreliable. That changed, they're in widespread use and work. Or work well enough to disincentivise carriers from changing. Especially as they can also act as convenient choke-points for regulatory activities. Or inconvenient chokepoints for users. They make establishing inbound connections harder. But that can be convenient for carriers who don't want you having an ability to use telephony services they're not billing you for.
But along the way, there have been thousands of IETF drafts. Most go nowhere. The ones that succeed tend to have the support of the large vendors, or networks. So way back in the early '90s, Cisco created a tag-switching mailing list that caught my eye. That proposed using switching tags rather than routing, so a cheaper networking solution that also promised non-IP support. There were also some drafts by Kompella and Martini for allowing L2 VPNs across 'IP' infrastructure & Kompella was a Juniper engineer. At the time, I was doing product development, and these looked interesting for being able to offer fixed link emulations across a common infrastructure and being ATM-like, could be robust enough to convince classical telco types to trust them. Eventually those morphed into MPLS services, we launched one of the first EoMPLS services and they're widely used today.
But only because the big vendors supported it, ie Cisco & Juniper.. And also because big carriers wanted the service, ie there was an incentive to offer it when large networks could/would potentially order thousands of switch/routers to replace their 'legacy' L2 switch infrastructure and consolidate everything into MPLS backbones. That duopoly's being challenged by the likes of Huawei now, but still an issue, ie RFPs (especially on the wholesale/infrastructure side) want to know & trust how solutions are delivered. An unknown or lesser known vendor's going to be a harder sell. So anything new has a hard time gaining acceptance.
That doesn't mean it's impossible. So it's not really necessary to get the IETF's seal of approval and an RFC. As EzIP's an overlay network, find some operators that will implement it. If it works and it's seen to fill an operational need, it'll get more interest and become easier to get standards-tracked. Problem is again it's arguably missed the boat. Due to it's history and the US-centric nature of the Internet, address depletion largely affected the newer RIRs, ie APNIC/AfriNIC, who unsuprisingly became early IPv6 adopters due to necessity.
Hi, Jellied Eel:
0) Thanks for recapping details of the Internet history. As you correctly pointed out, much of the current Internet situation is the result of commercial efforts. In a perfect world, this openness would be great. But, we need to look at the result of the over three decades of "experiments". Essentially, we have fostered a few monopolies, one in each business sector. Now, they are not only swaying the general public's opinions, but also influencing government regulatory actions, while they are making the money off the consumers without feeling much obligation to their welfare. It is very scary.
1) " it's not really necessary to get the IETF's seal of approval and an RFC. As EzIP's an overlay network, find some operators that will implement it. If it works ": Correct. with the ability to establish a sub-Internet supporting 256M IoTs from a single IPv4 address, the EzIP deployment is pretty much a freelance operation. From the big picture perspective, each sub-Internet is just a CPE (Customer Premises Equipment), not affecting anyone else. So, we can just do it without telling any Internet governing body anything about it. However, this new type of CPE is capable of covering such a large area (as large as Tokyo metro or 75% of countries) that my system engineering training told me that it would be prudent to let the organization in charge of the Internet know about it. So that proper coordination activities may take place along the way. Then, using EzIP or not will be an informed decision. This is why we continued to submit several EzIP Draft versions to IETF, knowing full well that they have been winding down the only Working Group SunSet4 and eventually concluded it this past May. I have made this clear to a senior Internet governing body member in charge of this matter, upon finally getting through to him.
2) On the practical side, we need to inform the general mass of the availability of an alternative, ASAP. So that they may stop the current "suffering", or continue being led by current players. This is a tough challenge, because most people do not have any idea what is going on, besides it seems to be nice to have Internet services on daily basis, while "surprises" happen frequently. Since IETF has "institutionally" decided to go for IPv6, the only organization that may be able to provide some influence is ITU. This is where "politics" comes in. Internet camp has been against ITU participation with various reasons. Since ITU does not have much expertise in the Internet technology, they are at a difficult position to represent member states (in this case, mostly the developing countries, or more plainly, the non US-centric block). I believe that EzIP is the first facility that can clear up the smoke screen at the baseline, so that all parties can be relieved from the urgent tasks (address shortage and cyber security vulnerability) for focusing on the design of a solid next generation Internet, be it an improved IPv6 or a brand new version.
Abe (2018-08-31 10:40)
Hi, Jellied Eel:
0) Thanks for your in-depth comments with historical references. It is very educational, I appreciate very much. Sorry that I did not respond earlier because I was still trying to figure out how to present the EzIP. Some of the points that you brought up near the end are very controversial and convoluted. Fortunately, I believe applying the demarcation principle, the EzIP can largely avoid them.
1) I agree with your observation and recommendation. That is, EzIP could just go find a carrier / operator to deploy the SPRs without the blessing from the IETF, because each SPR looks like an IoT or one CPE from the Internet. We submitted the EzIP Draft to IETF just for the purpose of doing due diligence, because we are an US company. I wanted to be sure that all US related organizations got the right of first refusal.
2) The next step is to ask how big is the 240/4 address block and what does it mean when a CPE gets to be this size? Although the second letter of the SPR is spelled out as "public", you likely have realized from our description of what triggered this approach that it may be installed on a private premises just in front of the existing RG. Then, the "P" means "Private". Any two private parties may operate SPRs through the Internet as a telephone modem pair through the PSTN. This is subtle but extremely important, because the whole region (the sub-Internet in the Draft) served by an SPR utilizing one 240/4 block becomes much bigger than a LAN and about one sixteenth of the full IPv4 based Internet! Yet, it is practically transparent to the current Internet fabric. Let's call this as a RAN (Regional Area Network) for facilitating the following discussion.
3) The exciting part of a RAN is that as long as it is compatible with the interface to the serving ER for communicating with the global Internet, the SPR may be constructed with any technology. This gives SPR the freedom of pick and choose desirable characteristics from the current Internet, while rejecting anything that is known to cause issues. This is why we proposed to utilize one of the RANs (sub-Internets) in the EzIP environment for the proposed satellite based Internet which is still in the conceptual stage, with nothing concrete yet.
4) Along this line, the RANs will be perfect test beds for developing new Internet Protocols in real time and in coexistence with existing IPv4, IPv6, etc. based operations, as long as the interface through the single IPv4 address is compatible with current IPv4 packet definition. This can be easily achieved by using the Caching Gateway for the translation of the packet, only at one point.
I would appreciate your thoughts very much.
Abe (2018-09-28 23:05)
As I explained before, it's fundamentally not possible to do the kind of backwards compatibility that you seem to want from v6. v4 doesn't support it. There are a few ways of working around that deficiency of v4, and v6 uses those ways, and I would argue that v6 is backwards compatible because of its use of those workarounds.
You already know what those workarounds are. In fact, you figured them out yourself for EzIP, because it uses those exact same workarounds. (By your argument, this means that either EzIP isn't backwards compatible either, or it means that v6 is.)
and still did not work (carrying only about 2% of the total Internet traffic)
I know that's what is written on AMS-IX's graphs, but that's not an accurate measure of internet-wide v6 traffic. Over half of ISP traffic comes from on-net caches, which are typically v6, and over half of the remaining traffic goes via direct peering and never hits an IX. There's a correlation between "big enough to peer" and "does a lot of v6 traffic". IXs are going to see abnormally low amounts of v6 traffic.
25% of internet users have v6, and on average ~50% of traffic for a dual-stacked user goes over v6. These stats sound a lot better, don't they?
In a sense, we just have to admit the mistake of the current IPv6 and swallow it, then move on with something more reasonable,
Do you have something more reasonable? Because, as I've mentioned, v6 is already about as simple as it can possibly be given the constraints it's working under. EzIP ends up being more complicated because it permanently requires running on top of v4 using workarounds intended for backwards compatibility, whereas v6 is also capable of working without the workarounds.
EzIP also has the exact same deployment difficulties that v6 has (e.g. the need to upgrade everything that needs to interact directly with it) and offers nothing to ease those deployment issues that v6 itself doesn't offer.
So if you want us to use something more reasonable then EzIP isn't it, and I haven't seen any better suggestions. Why should we abandon the substantial v6 deployment we have to start over from scratch with something that isn't even better?
Also, seriously, you need to learn v6. It's not difficult, I swear. 80% of it is pretty much identical to v4 but with longer addresses. If you have your head around v4 (as you clearly do) then you already understand all of the concepts; v6 just makes the addresses longer, which doesn't change how any of it works.
Go and grab a tunnel from tunnelbroker.net and set it up on your network. Play around with it for a bit. Seeing it in action should show you that it's not as scary as you think.
0) It looks that we are getting into word-smith arguments.
1) To save both of our time, let me begin with a question which is stupidly simple. Send yourself back to Year 1982. After you studied the RFC791 and understood the 240/4 address block was "RESERVED" for "Future use". (Both were time marked in 1981-09), you read about EzIP. Could you understand it? If so, how could anything like IPv6 that is built on top of lots of RFCs afterwards be simpler?
2) "it's fundamentally not possible to do the kind of backwards compatibility that you seem to want from v6. v4 doesn't support it.": Of course, IPv6 can't because it is now publicly known that it ignored this basic engineering discipline. As to the second part, I am not sure what you are referring to. The only IPv4 standard that EzIP relies upon is RFC791. So, RFC791 has built-in "Forward Thinking" to support EzIP, while EzIP is backwards compatible to RFC791. Together, they are a pretty "Kosher" pair.
3) " AMS-IX's graphs ... ": You have another interesting argument. I do not know Internet enough to provide counter argument. However, two facts I can supply. First, this article talks about disputes among fairly good sized ISPs about peering arrangements. So, what portion of IPv6 traffic is peered would be significant factor in influencing this discussion. Secondly, I have been talking with fairly high level people in IETF, ICANN & ITU. None of them shot me down from this angle. If you can identify your level of expertise, maybe I will accept your opinion.
4) "Do you have something more reasonable? Because, as I've mentioned, v6 is already about as simple as it can possibly be given the constraints it's working under.": What constraints that IPv6 is working under? In comparison, EzIP gets the job done without relying on any RFC after RFC791. What could be more reasonable?
5) "EzIP also has the exact same deployment difficulties that v6 has (e.g. the need to upgrade everything that needs to interact directly with it) ": Please be specific. I can reiterate the deployment conditions of EzIP for you. The basic configuration is an inline device (SPR) between Internet's ER (Edge Router) and private premises RG (Routing / Residential Router). Nothing in the current Internet setup is affected. For its sub-Internet configuration, it is even more stealthy because an entire region up to the size of Tokyo Metro served by the degenerated SPR appears as one single IoT to the existing Internet. There is really no "difficulty" in deployment to speak of.
6) " Why should we abandon the substantial v6 deployment we have to start over from scratch with something that isn't even better? ": If something isn't delivering what it promised, anytime is a good time to abandon it. It does not matter how much we have sunk into it. The more we wait, the more we waste. I have seen enough cases of swallowing the missteps. IPv6 is just the biggest "public experiment" that has had its chance to demonstrate its wisdom. We have been dragging on by it because there has no alternative to challenge it and it is "too big to fail", until EzIP. And, you have not made clear enough description about why EzIP isn't better, except by statements of your own words.
7) "Also, seriously, you need to learn v6. It's not difficult, I swear. 80% of it is pretty much identical to v4 but with longer addresses. If you have your head around v4 (as you clearly do) ... ": Thanks for the compliment. However, as I professed, I have already stretched my brain cells to learn enough IPv4 to come up with EzIP. I heard enough negative experience from IT professionals that I am not able to get to the IPv6 level just because your encouragement.
8) Again, please come down to the earth by answering my question in Pt. 1) above. Then, we will have a common ground to proceed.
Abe (2018-09-06 16:51)
No, v6 didn't "ignore" backwards compatibility. v6 CAN'T DO backwards compatibility because v4 doesn't support it. There's no way to do complete bi-directional transparent backwards compatibility with v4. Nothing can be backwards compatible in that manner with existing, unmodified v4 nodes. It's not possible.
v6 isn't transparently backwards compatible with v4. Neither is EzIP, for the same reasons.
You need to decide whether you consider EzIP to be backwards compatible or not. If you think it is, then you also think that v6 is backwards compatible, because v6 uses the exact same mechanisms (dual stack, NAT, tunnelling) that EzIP does to be compatible with v4.
Do those mechanisms count as backwards compatibility or not? I'll let you decide. But either both v6 and EzIP are backwards compatible, or they both are not. You can't have it both ways. Not when they use the same methods.
If you don't believe me then you're welcome to learn v6 and see for yourself. If you're not going to do that, then you're going to have to rely on other people who do know it. Either way, please stop using your own preconceptions of what v6 can and cannot do, because they're wrong.
Re: peering, I'm talking about direct peering agreements between end-user ISPs and big content networks - people like Google, Netflix, Akamai. These people all push huge amounts of traffic, and they all do v6. Peering between end-user ISPs and content providers effectively takes that traffic off of the public internet (and it's the public internet that the article is talking about).
If so, how could anything like IPv6 that is built on top of lots of RFCs afterwards be simpler?
By not requiring that it be run as an overlay network. v6 can run as an overlay, but it also supports running natively, and running natively is way simpler than requiring a fully operational v4 internet and then running on top of it forever.
The number of RFCs isn't the important part. You'll find that going from a draft idea to something with completely defined behavior that can be implemented correctly everywhere requires thinking about and defining a bazillion things you never thought you'd need to deal with. That's what those RFCs represent. (That, plus 20 years' worth of further development on core internet protocols.)
Please be specific. I can reiterate the deployment conditions of EzIP for you. [...] There is really no "difficulty" in deployment to speak of.
Great to hear there's no difficulty! v6 can be deployed in exactly the same way. For example, you can deploy dual-stack routers without affecting anything in anybody's current internet setup. The various forms of NAT cover communicating between protocol versions. 6to4 covers the "give every existing IP more IPs" aspect (although it gives a trillion trillion IPs per v4 IP, rather than just 256M).
And, you have not made clear enough description about why EzIP isn't better, except by statements of your own words.
What else can I give? The way v6 works is public knowledge, and you're free to go and verify anything I've said.
0) Thanks for your comments. However, we must focus on essence, not on philosophy.
1) " No, v6 didn't "ignore" backwards compatibility. v6 CAN'T DO backwards compatibility because v4 doesn't support it. ... ": As I was saying, you seemed to be more interested in word-smith debates on conceptual topics than dealing with the actual technical subject matter. Allow me to repeat this truly "Back to The Future" question. That is, if you were sent back to 1982, could you see that making use of RFC791 and 240/4 address block in the way prescribed by EzIP could expand the IPv4 address pool by 256M fold so that the trigger for considering IPv6 was eliminated?
Note: Unlike the same titled movie that I am referring to that applied certain modern day knowledge and skills, the EzIP scheme does not rely on anything that came after RFC791.
2) All the rest of your opinions are the consequence and variations of not being able to achieve the above. So, let's concentrate on Pt. 1) to establish our baseline first. I will be glad to dig into them afterwards. Thanks.
Abe (2018-09-09 16:40)
If you insist, I'll answer it directly: yes, I can roughly figure it out. I don't agree that it would be the right way to do it, and at 60 bits I'm not convinced it would be big enough, but it's certainly a way, and I did think I made it clear already that I understood how EzIP is supposed to work.
(I also don't agree that it relies on nothing after RFC791. It relies on a lot of things after RFC791, including its own 43 page draft.)
Now perhaps you could answer my question, so that we can stop flip-flopping between two different definitions for it: what, exactly, do you mean by backwards compatibility? This is a technical matter, given that it concerns the technical capabilities of the things we're talking about.
1) " yes, I can roughly figure it out. ": Thanks, this is a good starting point for us to move forward. (Maybe I missed it. But I do not recall any positive statement from you previously.)
2) "at 60 bits I'm not convinced it would be big enough,": I am not sure where you get the number "60" from? Perhaps it is just a typo? A full EzIP address has 64 bits, 32 bits from the basic public IPv4 pool and 32 bits from the 240/4 block. This give us a 1BB (4B x 256M) combination. In addition, if you review the derivation / logic analysis in Section 5. that leads to paragraph 5. C., you will see that even a 128 bit address system out of the current IPv4 pool is possible, if we can give up the idea of keeping IP address as personal property. (This is a big philosophical issue that we can discuss about next, separately.) However, since the first two bits of each 32 bit segment are used to distinguish among the four evenly divided parts from the full IPv4 pool, the actual effective total address has only 120 bits. So, instead of 256BBBB combination that IPv6 has, EzIP can only get up to 1BBBB. Since the latter is huge already anyway, I hope we do not need to debate on which one is better based on their size ratio.
3) "It relies on a lot of things after RFC791, including its own 43 page draft.": All 43 pages of the EzIP are just describing in detail about how the 240/4 address may be transported across the Internet, so that it can be used by SPRs at either end of a link. They are NOT disclosing a new method / protocol in the strictest sense at all, according the disciplines that I learned through my engineering training. The key mechanism, the Option Word was defined clearly enough by RFC791 back in 1981-09. There have been many applications of it in the RFC library. To put in another way, the 43 pages of the EzIP Draft are kind like the lecture notes that a professor brings into the classroom to assist the student to understand the topic of the day which is "transporting new address across the Internet for new routers to perform an extra stage of routing". And, the ingredients to be relied upon were covered by earlier lectures.
4) "what, exactly, do you mean by backwards compatibility? ": Allow me to describe what I was taught in the good old days by the biggest telecom company (the previous life of the current AT&T). The "Kosher" definition of a product / system that is backwards compatible to its predecessor is that upon introduction, everyone (from operator to end-user) can continue what each has been doing previously. And, no one can tell something has happened. As time goes on, individuals will realize that the bad aspects of the old system have been eliminated, while those venturous will discover that new capabilities / features have been added. Of course, the designer of the new system is eager to tell everyone what is new. So, there would be normally a brochure of some sort with highlights of the new system distributed to everyone involved during the introduction. So that everyone can enjoy the new system, ASAP.
5) Based on the above outline, how close would you say that IPv6 is backwards compatible to IPv4? Hope you can now appreciate why I am so critical about various aspects of IPv6.
Abe (2018-09-13 23:06)
60 bits is 32+28 bits. 2^32 is ~4 billion and 2^28 is ~256 million.
The "Kosher" definition of a product / system that is backwards compatible to its predecessor is that upon introduction, everyone (from operator to end-user) can continue what each has been doing previously.
By this definition, v6 is definitely backwards compatible. Adding v6 support to a network, router or host has no impact on its existing v4 support, and you can continue using v4 as you were previously. So it meets this definition.
No, you are talking about IPv6 is "coexisting" with IPv4.
When I say "predecessor", I mean that the new one is providing the service in place of the old one. The old one is practically retired or being phased out. There is only one active system at a time that the operator or user sees.
Abe (2018-09-18 22:15)
It would've been helpful to put that in your kosher definition of backwards compatibility when I asked you for it. By this expanded definition, EzIP is not backwards compatible, because it uses v4 unless both sides have EzIP. Operators and users need to deal with both.
1) " By this expanded definition, EzIP is not backwards compatible, because it uses v4 unless both sides have EzIP. ":
Backward compatibility in this case means that the new system (EzIP) is able to transparently handle the old format (basic IPv4), so that no one is required to be capable of the advanced capability (EzIP) if not interested in it. Thus," falling back" to requiring both sides to use IPv4 when someone in the loop is not capable of EzIP is actually conforming to the Kosher definition of "backward" compatibility.
2) "Operators and users need to deal with both. ": Actually, the current "operators" (the CR & ER - Core and Edge Routers) are not expected to handle EzIP at all, because the Option Word is transparent to them. Only "users" are encouraged to upgrade their IoTs to be EzIP-capable, so that they can enjoy the straight routing that offers end-to-end connectivity.
Abe (2018-09-29 09:40)
By this definition, v6 is backwards compatible. It can transparently handle v4 on any system that has the appropriate software support, and it doesn't require anybody to be capable of doing v6 if they don't want to do v6.
Is this what you mean by backwards compatibility, or are you going to change your mind again?
1) "... any system that has the appropriate software support ... ":
What do you mean by this? Who is counting on some extra support? What is the "software support" that you are implying? And, it even has to be "appropriate"? Aren't you getting too vague now?
2) Putting it in another way, since IPv6 has been relying heavily on so much marketing push to get the deployment going, the activities are too explicit for anyone to overlook. It just could not be classified as "transparent" which is part of the implied requirements for being qualified as backward compatible.
(Remember what I described to you about hot-swaps and midnight cut-overs for the telephony equipment updates in the old days? Those events were so transparent to the subscribers that everyone executed as routines. No one made it a subject to talk about.)
Abe (2018-10-07 19:04)
I just mean any system that can parse a v4 address and generate a v4 packet. This isn't some extra thing that needs to be added, it's literally the software that's already in those systems and which they're already using for v4.
I don't think I even understand what you mean by "transparent" any more. Do you mean "existing devices keep working", or do you mean "end users don't need to change what they're doing" or is it "the engineers responsible for making the network hardware and software are unable to detect any changes in behavior or functionality"? Or maybe even something else?
1) If you are talking about v4, I agree with you that EzIP is attempting to do so.
2) All the "transparent" cases that you listed are correct, except the last part. That is, the engineers definitely have to know there is change.
Abe (2018-10-22 21:24)
1) Re: My Pt. 3) in my last reply: Come to think about it, since IPv4 is more mature, wouldn't it have larger percentage of the traffic going through the Peering arrangements instead of AMS-IX? It is IPv6 having trouble to get Peering agreements that is sending more traffic to AMS-IX, yet is still only about 2% of the total. Then, you are defeating your own argument. Correct?
Abe (2018-09-06 18:12)
"If you, as a network, fall into a tier where the exchange of data is so huge that it's not really worth tracking and charging others for, you have to start paying, all the way down from large ISP to small ISP to business to, eventually, the average consumer paying $50 a month for what is, comparatively, very little."
Can someone please explain the above paragraph? I am dim and don't understand it.
I think the article is missing the word "imbalance" - the point is that settlement-free peering only makes sense if both parties are providing an essentially equivalent service to one another.
That is usually considered separately in terms of transit provided to other networks than the two that are peering (on the basis that I'm not doing you a favour by accepting traffic destined for my own network).
So a (non-telco) business network, even a multi-homed one, is essentially never providing any transit to its peers, and therefore pays its provider the entire costs of its connections; a mid-size ISP may be providing some transit (to its multi-homed customers, such as smaller ISPs) and may have some settlement-free peering with other similar networks, and some partially or fully-paid peering with bigger, more connected networks.
I've reworded it to make it simpler. Basically, if you shift 1PB of data a day from your network through another network, and they shift 1PB of data a day from their network through your network, you pay each other the same amount and thus pay each other zero.
If you're a small network, and you run a lot of traffic through a larger network, and the larger player doesn't route much through you, then you need to cough up for the bandwidth difference.
Both of these scenarios involves a peering agreement - the latter involving money.
Hope this helps.
That's a good explanation - it sound like it would be possible for a large network to route some of the data to balance out the transfers where you would otherwise owe payments, and the rest of the data to networks so that you were owed money?
If you're a small network, and you run a lot of traffic through a larger network, and the larger player doesn't route much through you, then you need to cough up for the bandwidth difference.
In strict parlance, what you have there is not really peering (in the settlement-free sense). You're buying Transit from the bigger player.
It should also be noted that settlement-free peering isn't just for networks with mutually balanced traffic, it's for networks with mutually compatible traffic - lots of asymmetric networks peer for free precisely to reduce costs. For instance, If I set up a data centre in London (i.e. heavy outbound traffic to users requesting the content I host), I would seek to peer directly with the likes of heavy inbound networks (like ISPs) who connect me to the users trying to get at my content. Peering directly with other datacentres is less relevant because I won't be exchanging much data with them.
The alternative would be both myself and the ISPs paying a Tier 1 provider (like Cogent) to provide us both with transit.
Buying transit from Tier 1 providers is - overall - unavoidable because no datacentre can be directly connected to every ISP in the world and likewise, no ISP can directly connect to every possible content source in the world. But BT and Virgin (heavy inbound) make damn sure they're directly peered to Google and the BBC networks (heavy outbound) because it would cost both sides a fortune to be pushing YouTube and iPlayer traffic (for instance) over a third party like Cogent.
This is one of the problems with the US monopolies despite being heavy-inbound, they refuse to peer settlement-free with content providers like Netflix and also under-provision their Transit links so netflix traffic gets stuck coming over those connections, denying their users (who have paid for internet) reasonable service. The likes of Netflix are then forced to pay for the right to peer and gain access to the ISP's customers (even though the customers have paid for the right to access Netflix!).
This doesn't happen so much in Europe where we have lots of neutral, community Exchange Points where networks exchange data for free and minimise the traffic they have to send via a Tier 1 (and therefore their monthly Transit bill).
First define 'Tier-1'..
In classic sense, it's a default-free network. So the 'net is a blob of interconnected ASNs, each with it's own unique set of routes allocated by the RIRs. With peering, my ASN connects to your ASN and we have a route between our address space. There may be traffic.
But that won't let your traffic reach every destination on the 'net. So if you can't find the destination directly connected via a peer, you send it via a default route to an 'upstream' who may have a path. So a 'Tier-1' has a complete set of routes to every destination, either via paid or settlement free connections.. Which is also where marketing and the economics kick in. So assume..
If ISP1 peers with ISP2, traffic can flow freely.
If ISP1 buys transit from ISP2, traffic also flows freely.
Then capitalism kicks in. User pays ISP1, Content pays ISP2. Where the peering wars begin is with transit, where ISP1 has to pay ISP2, so ISP2 gets paid both sides of the session.
That gets especially contentious where costs are considerably different, ie operating an access ISP with millions of users costs considerably more than operating a transit network, that focuses on stringing fat pipes between datacentres/peering exchanges. It's also where there's an unequal value exchange, ie
User-Content is the cash flow for a Amazon/Netflix subscription.
Content-ISP2 is the payment for subscription delivery.
ISP1 gets... nothing except what it can charge for the basic Internet connection, and has to pay ISP2 to keep customers happy.
In the good'ol days, settlement free peering was often decided on mutual benefit, or traffic ratios. Content skewed this model because that's highly asymmetric, ie small session request generates a big stream back. Transit ISPs also have more economic power, ie if ISP1's user can't connect to content, they'll blame ISP1 and maybe switch. So ISP1 has to buy more transit to keep their customer's happy.
More rarely, 'peering' disputes can hit the content side, ie if say Netflix loses access to 10m customers due to a peering spat, then they'll start leaning on their transit provider. Generally though, the big content providers prefer the status quo, and as long as they can play T1 transit providers off against each other to lower their traffic costs, they're happy.
This particular case is just an extension of those disputes. It's difficult (read: Expensive) to challenge the current Tier-1s, but some providers saw IPv6 as a way to challenge that dominance, and become an IPv6 'Tier-1'. Naturally, the incumbents said 'Nope', and referred them to their existing peering policies.. Which are generally impossible to meet for most ISPs, especially regional ISPs.
And the economics behind all this lot are why the 'Net Neutrality debate exists, with the big content providers on one side trying to avoid costs, and access ISPs on the other looking to recover them.
There's also the case where the big content providers offer to peer or install caches. That may reduce the need for ISP1/access ISPs to buy transit, but still costs ISP1 a lot more to carry that traffic than it does the content provider.
The article makes the point that this peering problem is nothing to do with the IPv6 protocol, so why doesn't this happen with IPv4, in that case?
Perhaps because the sources, destinations, and volumes of IPv6 traffic differ from IPv4 traffic? An otherwise nondescript IPv4 ISP might, through circumstance, have a significant sink for IPv6 traffic in its customer base. While it will not be able to use its IPv4 presence to broker peering deals, it may be able to argue that the imbalance in IPv6 traffic justifies that it either charges other ISPs for IPv6 connectivity, or comes to a peering agreement which it would not otherwise be able to negotiate on its IPv4 traffic statistics alone.
What has this to do with IPv6? Well, it appears that IPv6 may have given some companies an opening to the big leagues, with some trying to become tier-one providers for IPv6 and hence the future of the internet. And not everyone is excited about welcoming newcomers to the club.
You are very welcome!
> The article makes the point that this peering problem is nothing to do
> with the IPv6 protocol, so why doesn't this happen with IPv4, in that case?
Whilst the tier-1 ipv4 companies had a hold on the ipv4 market, they were slow to provide ipv6.
Newcomers, who wanted to get into the top tier, took this as an opportunity to create large ipv6 peering networks.
When the ip4 guys came late to the party, the ip6 newbies were like "hey, we're here, we're big, we're tier 1 ipv6, peer with us"
the ip4 guys, not wanting to share their tier-1 hold with others are making it difficult - they expect to squeeze the newcomers out by establishing the same tier1 cartel with ipv6 as they have with ipv4.
It stinks. It's anti-competative, and should be looked at under competition rules.
Three cheers for Hurricane Electric - who for the last 4 years have provided me with a faster transatlantic ip6 connection that any ip4 has ever achieved.
Be more ambitious! IPv1000 for the win! Bonus points for calling it IPvM
It's 250 times better than IPv4, whereas IPv6 isn't even twice as good! I propose that we replace IP addresses with types of insect. Then the more research we do on rainforests, the more IP addresses we'll have available. There are tens of thousands of types of beetle alone, and we're still discovering a couple a day.
IPv6 is complex enough compared to IPv4 it needs far better support from software and devices to be deployed in SOHO and even SMB environments.
When I tried to setup IPv6 in my home network, for example I found that:
1) You don't have simple reserved addresses for local LANs. You have to generate a random one from the specified block (of course, if you don't have an ISP assigned one, as in my case).
2) Many examples correctly use the reserved "example" address space, but forget to tell you.
3) You can't hope to remember the addresses and use them, so you need software to generate (or at least handle) them and match them to host names, unless you want to manage manually your host files (you still have to write somewhere the important addresses if name resolution for any reason doesn't work,a nd you need to fix it).
4) isc-dhcp-server requires you to launch a separate instance to manage IPv6 addresses (you can use radvd but may not then send all DHCP options).
5) Of course, you have also to configure it to talk to Bind for proper name resolution as well
6) VLANs and subnetting in IPv4 are easier, as you often assign a subnet to a VLAN for easier management. In IPv6 everything becomes blurred and more complex, especially in the beginning.
7) Using hexadecimal notation could be easy for IT pros, not so much for those who are not.
All this issues can have an "easy" software answer - devices should have UIs good enough to let user select the desired configuration and then generate whatever is needed to make IPv6 work, instead of asking users to configure most options from scratch.
Simple SOHO setup with a single all-in.one router/AP/etc, device and everything connected to it may have little issues as soon as the ISP assign a block, but as soon as your setup is just a little more complex, everything becomes quickly less easy to plan and manage.
You see it was designed when there was a relatively few large networks managed by professionals, and others had a single machine connected via a POTS modem only.... they really couldn't envision small LANs managed by average users.
Quite a litany of things you don't know there. Which is to be expected for a self-proclaimed beginner working with a home LAN environment. Just don't go blaming the protocol or software for your own lack of knowledge.
1) fe80::/16 and fc00::/7
2) forget to tell you that examples are examples? introducing 192.0.2.0/24. ie. this is not a v6 problem.
3) 10.1.1.1 is harder than fc00::1, *::2, *::3 etc.
4) so use a DHCP server that doesn't impose those problems?
5) ah DNS, that newfangled 1980's invention. Such a chore to get that working.
6) er, no. just no. for v6 ... assign different subnets. then discover that you don't need VLAN at all, the job was done when subnet assignment happened.
7) same can be said for dot notation. Turn your SOHO device over and look at the "MAC" address it has been labeled with. There is the IPv4 layers hex notation. v6 is just copycat of the v4 worlds MAC notation.
BTW that device will be auto-assigned fe80::$mac as its address.
> as soon as your setup is just a little more complex, everything becomes quickly less easy to plan and manage.
In other words. You made up a network design that in v4 is "quite complicated" and have yet to figure out that v6 is so much simpler that most of the things you are thinking you need can actually be thrown away. The v4 world is a twisted maze of delicate layers all affecting each other - the v6 world is a flat open field with only the subnet, routing and firewall rules you choose to impose. Time to re-think your network design in light of the features v6 provides.
> You see it was designed when
So wrong. v6 is constantly being updated by admin with a very good knowledge of modern networking - a handful of updates are in review even today. That 22 year history is littered with attempts to add "critical missing features" someone just like you thought was super important to keep their v4 designs working as-is ... which routinely get abandoned and deprecated when they discover that v6 had better (but different) capabilities all along. Some turned out to be useful, most do not.
"6) VLANs and subnetting in IPv4 are easier, as you often assign a subnet to a VLAN for easier management. In IPv6 everything becomes blurred and more complex, especially in the beginning."
Running too many machines in a single segment doesn't work terribly well. If you start approaching the same numbers as the limiits of a /24 at gigabit speeds then you're going to have trouble coping with broadcast and multicast traffic, despite IPv6 being somewhat better than IPv4 on that score.
On this article, I introduced a separate thread entitled "IPv4 Address Pool Has Been Expanded Significantly" reporting a purely IPv4 based solution called EzIP that can expand each IPv4 address by 256M (Million) fold.
You may want to have a look at it:
Abe (2018-08-29 17:46)
... at Any Price and All Costs in Order to Simply Lead Remotely
Imagine small provider C runs a lot of internet traffic through large provider D, and D routes significantly less through network C.
It could equally well be argued that D is penalising C because of a dearth of suitable traffic via their networks of interest to C Clients and Advanced Intellectual Property Providers Attending to Raw Rare Source Suppliers.
Thus does D pay C for that lack of intelligence flow. Who/What else are you to blame and apportion responsibility for the Problem Searching Solutions failing to Deliver Lasting Resolutions with Immaculate Answering Machines in Serially IntelAIgent Networks.
Surely you are not going to deny your daily and future intelligence is provided by all manner of machine? Such would be patently false ... and easily quite popularly revolutionary.
Biting the hand that feeds IT © 1998–2019