Re: IPv4 Address Pool Has Been Expanded Significantly
Hi, Nanashi:
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.
Thanks,
Abe (2018-09-06 16:51)
Biting the hand that feeds IT
