Stern Vint Cerf blasts techies for lackluster worldwide IPv6 adoption Co-inventor of TCP/IP and so-called "Father of the Internet" Vint Cerf has urged network nerds to "get with the program" on World IPv6 Day. In a video to celebrate six years since the creation of World IPv6 Launch, Cerf offers optimistic impatience with the rollout of the next-generation network addressing protocol. He notes …
" it is very hard to get hold of IPv4 addresses unless you go to one of the grey markets where they cost significantly more than IPv6 addresses;"
It is not very hard to buy IPv4 addresses; going rate is about 10-20 per IPv4.
But it is very hard to implement IPv6 in an IPv4-only ISP: routers, CPE's, DHCP, management systems, legal intercept, monitoring tools, manuals, helpdesk, tutorials.
"mostly because people have figured how to do more with their existing IPv4 addresses,"
Quite. So if it's not broken there is no motivation to fix it.
"But it is very hard to implement IPv6 in an IPv4-only ISP"
And if you cared, you wouldn't chose an IP4v ISP. If you have a choice! But if stuff just works, why would the average punter care?
"PS: Yes, yes, we know, The Register is still IPv4, and not on IPv6. Word from our sysadmins is that we'll migrate Soon™"
Hoo-fecking-ray.
At least you're acknowledging it now, but my comment history shows a similar response for the last... five... six years? I can't be bothered to go back further than that.
It will be cheaper to jump straight to IPV8, and the savings can go to important community focused journalism like building a robot kegerator or developing the ultimate bacon sandwich.
I want my tech journalists worrying about journalism, not value signaling their hosting providers buzzword compliance.
Take your time Gents, the sky isn't falling this year.
I would prefer my tech journalists to stop whining about poor take-up of IPv6 when there is literally no reason not to instruct their host "turn on IPv6" on a test domain. It's seriously overdue given the amount of ribbing they want to give others, not that it's a vital technical resource. It's like mocking everyone for not using Windows 10 when they're stuck on XP.
Hell, it would make a whole series of interesting articles: How The Reg went IPv6, the problems we hit, and why haven't you done it yet?
Instead we get junk like this:
https://forums.theregister.co.uk/forum/1/2018/05/24/open_source_mano_release_four_lands/
Where there are literally two posts in the comments... me asking "WTH is this", and some random guy commenting "I don't know either", and that's it. Still none the wiser.
But yet every month, without fail, we get more and more dire warnings, articles about IPv4 allocations running out, coupled with statements like "It's about time everyone moved on because there are no addresses left", etc. but The Reg make no efforts that way. Not even tokens. Not even tests.
To be honest, the Reg reader survey is entirely "BI"-focused, yet most of their readers appear to be techy and wanting to forget just about anything to do with such managerial buzzwording - science, tech, sure. I'd much rather read a good article on the systems behind the Reg and what they use and how they implement a major project, than some guff. I suspect, however, that it would be technically embarrassing for them.
Journalists are journalists. But if they're sniping at the big places for not being ready, then they cannot ignore their own, much smaller, much easier, neglected internal system. Has The Reg updated their routers etc. against VPNFilter? What are they doing about Spectre/Meltdown? And how can they claim to be a good source of advice, articles and news about such things if they can't manage the basics?
Create ipv6.theregister.co.uk
Add an AAAA record to it.
Activate IPv6 on the frontend servers for that subdomain.
When it works, advertise it as a "prototype" and then start fixing things like logins, logfiles, etc. to work on it.
Even if it takes a year, two years, to get up-and-running you can THEN be sarky about places not supporting IPv6.
The Reg make no efforts that way. Not even tokens. Not even tests.
The hostname used for most images, regmedia.co.uk, has been returning an AAAA record, and has been usable over IPv6, since at least (let me check the changelog) three years ago.
My last comment on the matter of IPv6 still stands: https://forums.theregister.co.uk/forum/1/2018/05/21/ipv6_growth_is_slowing_and_no_one_knows_why/#c_3521098
Soon®
I'd much rather read a good article on the systems behind the Reg
See the https://www.theregister.co.uk/about/company/website/ ("under the hood") page; you can always fire off an email to webmaster@ and I'll be happy to answer any questions you might have.
As to your question about project management and "technical embarrassment" - you might be right; after all, it's a very small team and we're bound to get things wrong, or done slowly :)
Specifically about IPv6 on thereg, the main reason progress has been slow on the matter for the past few months (couple years now actually) is that I've not been able to secure a "proper" IPv6 connection for testing things properly with. This obstacle has now been stepped over, and as soon as my schedule frees up to allow me to do such tests, fix bugs and enliven things - there'll be IPv6 on thereg.
Mind you that adding IPv6 to ElReg is a little bit like adding icing to the cake. I can work on that icing once the cake's actually looking and tasting good, but if it looks like somebody stomped on it, I can't work on the icing and need to hold it off.
Hell, it would make a whole series of interesting articles: How The Reg went IPv6, the problems we hit, and why haven't you done it yet?
Excellent idea. Seeing a series of articles documenting it would be nice. It would be very good to see the transition as well as the excuses.
This can be as easy as setting up a box that has a IPv6 to IPv4 gateway along with both IPs and then a AAAA record and you will have it. Getting that working, though can be challenging if your admins are not familiar with it. Most operating systems have access to IPv6 built in already.
It took me about 30 minutes to enable IPv6 using a tunnel years back (using straight addresses on each server), but learning it took much longer. Where I had the most learning was seeing how it worked with different MTUs as well as routing and multiple tunnels. The ISP side could probably be the hardest part.
BTW, If you are using an updated OS (something within the last six years), you probably already have the IPv4 addresses which are mapped in the IPv6 address format in the logs. (This format could look like ::104.20.250.41)
Quite. Due respect to Vint Cerf (seriously) but if the designers of IPv6 had spent more time making it simple (enough) to implement for your average user -- even home user -- and more importantly: demonstrated clear benefit to doing it, for the same audience, maybe uptake would be better.
Instead IPv6 appears to the average consumer or user not as an upgrade, but rather a complicated bother they don't need anyway. Argue all you want about the reality and puff out your chest about how easy it is blah blah blah -- that's still the perception today.
Small demand from users and consumers means no incentive for the ISPs and cable companies et al to offer it. Seems simple enough.
"Instead IPv6 appears to the average consumer or user not as an upgrade"
It doesn't just appear to not be an upgrade, it isn't an upgrade. IPv6 is needed to address the overloading of the IPv4 space, and its value really only shines when you can't get another IPv4 address. I can't think of any strong reason to use IPv6 except to resolve the IPv4 address space issue.
This is something that genuinely doesn't affect the average consumer. It affects their ISP.
You only have to look as far as all the people asking for help with port forwarding or with closed NAT on their Xboxes to realize that it does affect at least some consumers.
(Then there are the indirect effects, like forcing all IoT stuff to go through a relay server because it's just too difficult to avoid it when everybody is behind three layers of NAT.)
"(Then there are the indirect effects, like forcing all IoT stuff to go through a relay server because it's just too difficult to avoid it when everybody is behind three layers of NAT.)"
They're going to go through a relay server anyway, because it's also the C&C server which means the vendor gets to feast on all your personal data by hiding away in a country not subject to privacy laws. Don't believe me? Why did Skype do it when it wasn't really broken to begin with?
Sure, a lot of IoT stuff is made by sleezy companies that'll do that anyway. But if you want to have any hope of ever avoiding the relays, then "just NAT behind CGNAT" is not the way to go.
We need to create and maintain an environment in which companies can do the right thing, before we get to complain that they're not doing it.
"Then there are the indirect effects, like forcing all IoT stuff to go through a relay server because it's just too difficult to avoid it when everybody is behind three layers of NAT."
I don't have any such issues. Oh, you meant allowing your IoT devices to talk to someone else's server? That might be a problem, but you can work around it. Or, better yet, avoid those sorts of devices. I'm continually baffled by people who are OK with filling their homes with such devices, particularly given that you can accomplish the same things without letting companies spy on you.
> Then there are the indirect effects, like forcing all IoT stuff to go through a relay server because it's just too difficult to avoid it when everybody is behind three layers of NAT.
This, in spades.
NAT is a hacked up kludge, _NOT_ some magic panacea. It breaks a lot of stuff and the workarounds open more security holes than it closes
Nobody's angry, Dan. The word I'd use is "dumbfounded". As in "Boy oh boy. That was the stupidest business decision I've seen in almost a decade. I'm dumbfounded. Utterly dumbfounded. Sure glad I sold off my Microsoft stock ages ago if that's the kind of business decisions coming out of Redmond these days."
"if all IPv4 addresses were contained inside a smartphone, IPv6 would fill a container the size of the Earth"
Sadly, this is nonsense. Because of the stupid and wasteful way that IPv6 addressing works, each LAN needs a /64 prefix (burning 2^64 addresses for typically a few dozen devices). And because it can't be subnetted on a longer prefix boundary, each subscriber who might need two or more subnets needs a larger allocation than that.
What it means is that in practice, an IPv6 /56 prefix is the same as an IPv4 single address with NAT - i.e. the unit that an ISP must give out to a "small" subscriber. Since the first three bits are fixed, this means that in practice that there are 2^53 usable IPv6 addresses. This is 2 million times (2^(53-32) = 2^21) more than IPv4; still a lot, but not mind-bogglingly vast.
The original plans assumed giving a /48 prefix to each subscriber. This would have meant that the IPv6 address space was only 2^13 times more than IPv4. IPv6 address depletion panic set in even before there were any users.
A few years ago, a single ISP - France Telecom - managed to get assigned a /19 of IPv6 address space. Remembering that the top 3 bits are fixed, this means they own 1/65,536 of the entire IPv6 unicast address space. And there are more than 65,536 autonomous systems making up the Internet today.
Clearly not everybody can justify a /19, but every member of RIPE gets a minimum of a /32, and can get a /29 on request with no questions asked.
@Crypto Monad
What it means is that in practice, an IPv6 /56 prefix is the same as an IPv4 single address with NAT - i.e. the unit that an ISP must give out to a "small" subscriber. Since the first three bits are fixed, this means that in practice that there are 2^53 usable IPv6 addresses. This is 2 million times (2^(53-32) = 2^21) more than IPv4; still a lot, but not mind-bogglingly vast.
The original plans assumed giving a /48 prefix to each subscriber. This would have meant that the IPv6 address space was only 2^13 times more than IPv4. IPv6 address depletion panic set in even before there were any users.
i was going to write similar,
Come on el reg, you need to bite the hand that feeds you this crap and get to the truth. IPv6 wanted to do away with NAT and just created an equivalence with its own issues, and the amount of non wasted addresses by design is vastly less than is being widely preached.
> France Telecom - managed to get assigned a /19 of IPv6 address space
Unlike IPv4 addresses, IPv6 allocations aren't "owned". FT would presumably have to show that they're actually using their allocation or some of it would be taken back. In theory, anyway, that's how it works. I'm not sure what justification they had for a /19, though...
> And there are more than 65,536 autonomous systems
Not sure what you mean by "autonomous system".
Slight modification, Alan ... A couple of the original Class As (and some of the Class Bs, and many of the Class Cs (including my own, given up in late '96[0])) were just grabbed by people who needed or wanted them. We often notified Jon they were in use after the fact. TehIntraWebTubes was a very different place back in the mists of time ...
[0] Seemed kinda pointless to own at the time; I had just sold my "portal" to idiots with more money than brains, and decided that I didn't need the address space anymore. In retrospect, it was a good decision ... Who needs that many routable IP addresses?
"this means that in practice that there are 2^53 usable IPv6 addresses."
No, it means that IPV6 can handle 2^53 routable networks.
"What it means is that in practice, an IPv6 /56 prefix is the same as an IPv4 single address with NAT"
Sure. But it's now the routable address of a network.
"2^53 usable IPv6 addresses. This is 2 million times (2^(53-32) = 2^21) more than IPv4"
No, IPv6 can handle ~ 2 million times more routable networks. IPv6 can also handle ~ 2^85 times more addresses than IPv4.
Also, even with /48s there are 2^45/7 billion = ~5000 per human. With /56s there are 2^53/7 billion = 1.3 million. Per human. And this is all out of 2000::/3 only; we still have five unused /3s that we can expand into with tighter allocation policies if it turns out to be necessary. These allocation sizes are fine, and we have an escape hatch if it somehow turns out that they aren't fine.
It's the same with that /19 mentioned above. France Telecom have 256 million customers, which is 3.7% of humanity. By that metric, their "fair share of the v6 space" (if we pretend for a moment that the concept makes sense) would be 2,360 /19s. One /19 barely even registers, and there's no reason to force them to conserve address space when we have enough available (plus an escape hatch just in case we're wrong). We made v6 overly huge precisely to avoid doing that.
" it means that IPV6 can handle 2^53 routable networks."
The Keyword in all this discussion is "networks"
When IPv4 was first created, the first octet was routing information, similar to an international dialling code. The idea that the first octet gave some indication of the network's position on the planet went out the window when the address space was broken up into Class A/B/C
Whilst IPv4 can only handle 65536 BGP4 networks one of the more important problems is the amount of routing update traffic that's flowing around and the number of updates that need to be made to memory tables in core routers. Calculating best paths is a big CPU hog.
IPv6 space is so big BECAUSE it makes provision for hierarchical routing, which in turn means that the number of routing updates flying around can be kept relatively low, which makes things more efficient at machine level (not numerically).
Sparseness in network addressing tables is a good thing. Imagine if your phone number was +441234567890 whilst your neighbours were +423210457895 and +622136 and that kind of chaos was repeated all the way up and down your street as well as across town.
Just because it can theoretically hold trillions of addresses, doesn't mean it is ever intended to. Once it sinks in that the first few bytes of IPv6 is supposed to be geographical/network routing information the size of the space makes sense - and the other reason it's "so big" is so that we don't have to go through this entire exercise again in a few years.
IPv4 was a hacky kludge only intended to remain in service for 5-6 years. That it's lasted as long as it has is a testament to ingenuity in the face of adversity more than Vint's original design.
This is 2 million times (2^(53-32) = 2^21) more than IPv4; still a lot, but not mind-bogglingly vast.
2^53 is over 900 000 000 000 000. That's approximately 1.2 million addresses for every living person on the planet.
Except it isn't -- it's 1.2 million network addresses for every living person. Each network can contain about 2^64 = over 1 800 000 000 000 000 000 devices for over 2 200 000 000 000 000 000 000 000 devices for every living person.
But what about companies, you say? Well, there are about 115 million companies in the world. Let's make them need about 60 x more network addresses (on average) than individuals. Why 60? Because that makes their total effect roughly equal to the individual effect, and I'm lazy. So instead of 1 200 000 networks with up to 2 200 000 000 000 000 000 000 000 devices per entity, we're talking 600 000 networks with up to 1 100 000 000 000 000 000 000 000 devices. (That would actually be 600 000 networks per person, and 36 000 000 networks per company.)
This means that even if 99.9999999999999% of IPv6 address space gets wasted, it's still bigger than IPv4.
Put another way, even with the waste you mention, IPv4's address space is less than 0.0000000000001% of IPv6's.
I read the Wikipedia article "List of unusual units of Measurement" and now I'm wondering how many IPv4 addresses fit into the complete works of Shakespeare.
https://www.opensourceshakespeare.org/stats/ after calculating stats on loading the page (wait, what? the works of Shakespeare are not a fixed thing, now he is dead?) reports that
There are 884,421 total words in Shakespeare's 43 works.
https://arxiv.org/pdf/1208.6109 says that for English, the average word length is 5.1. hmm. Close enough?
Add one for punctuation
(5.1+1) * 884,421 = 5,394,968.1 should be a fairly close estimation. But wait, that's modern English. Does Shakespeare's English differ?
Luckily enough, Copyright has expired, and the texts are available online from e.g. https://ocw.mit.edu/ans7870/6/6.006/s08/lecturenotes/files/t8.shakespeare.txt
Strip out the blurb to leave just the works and we have: 5,461,565
Hey, the estimation was pretty close!
We're forward thinking so lets use UTF-8 instead of ASCII. That's 87385040 bits of data. That's enough to store 2,730,782 IP addresses.
So the complete works of Shakespeare is a little under 2,3/4 MIP
*takes a bow*
I can't fit all the IPv4 addresses in my smartphone, coz I do block adverts and such. Though there is no such filter on my dumbphone, I don't use it for any Internet type stuff. On the other hand, the ISP my dumbphone is using has been offering IPv6 to it's costumers for many years, the ISP on the smartphone not so much.
My personal issue with IPv6 is that it seeks to replace instead of co-exist and I believe that this is what makes the whole thing so hard. Because even if you use IPv6 you're still often depending on IPv4.
My ISP for example supports IPv6, I even have a public IPv6 address. Unfortunately the router only provides this on the outside, on the inside only IPv4 is provided. I once tried to set up the DHCPv6 server but to little avail. And that brings me back to my dilemma: all my internal stuff uses IPv4 so the moment I try to connect to the Internet the first thing it does is contacting an IPv4 gateway. So where's the benefit here?
But I really think that they shouldn't have played cry wolf for so many times. Several times did they share doom scenarios about IPv4 running out and the Internet coming to a grinding halt UNLESS we would embrace the savior that is IPv6. The Internet mostly ignored that and the grinding halt never happened. It doesn't matter if engineers worked hard to prevent that from happening, what matters here is public perception: a doom scenario was predicted, and it never happened.
Not once, not twice but at least four times of the past years. And that's a really sure way to lose credibility. Good luck trying to convince upper management that IPv6 is important: "But haven't we heard those stories all the time now? So why should we invest when everything works just fine?".
What do you mean by "seeks to replace instead of coexist"? Dual stack is very much coexistence, and there's a whole bunch of transition techs (6to4, Teredo, NAT64+DNS64/464XLAT, ISATAP...) to help them coexist even better.
Perhaps you mean "unmodified v4 hosts can't talk to v6 hosts", but it doesn't make sense to pin the blame for that on v6 when it's a direct result of v4's design. v4's dest IP field is only 32 bits, it can't address anything more than that and any attempt to work around that is going to end up looking like one of the transition techs that we already have for v6. So why do you blame that on v6, when it already has the design that's as close as possible to the one you're suggesting it should have?
This post has been deleted by its author
"No it doesn't. IPv6 doesn't seek anything as such. It's just a standard - that can quite happily coexist with IPv4. It's your choice if and how you implement it."
I propose a new standard to bring all the other competing standards into one easy system.
(ICBA to link to XKCD. You all know which one it is already!)
"No it doesn't. IPv6 doesn't seek anything as such. It's just a standard - that can quite happily coexist with IPv4. It's your choice if and how you implement it."
No, they exist apart. To COexist (meaning existing together), then IPv4-only devices would need to be able to talk to IPv6-only devices.
"To COexist (meaning existing together), then IPv4-only devices would need to be able to talk to IPv6-only devices."
But you need to speak using terms the audience you're speaking to understands. Coexist means "both can exist at the same time". What you really mean to say is "interoperate".
"To COexist (meaning existing together), then IPv4-only devices would need to be able to talk to IPv6-only devices."
No, IPv6 traffic can pass on the same network as IPv4 traffic, That's what coexist means.
And most IPv6 devices are dual stack so they can also work with IPv4.
But IPv4 devices can't talk to IPv6 devices that doesn't co-exist in the IPv4 address space. This lack of forward compatibility (I mean, can't you use SOME kind of adaptation like a special pre-addressing packet?) scares people away from adopting IPv6 because they KNOW there WILL be some of us stranded on IPv4 for better or for worse. No one wants to strand customers.
" No one wants to strand customers."
At some point, someone's going to take a IPv4 ISP to court for misleading advertising.
If you're IPv4 only, then by definition you can no longer access all the Internet, just the IPv4 parts of it.
Remember when various telcos were flogging their walled garden web-only access as "internet" and got spanked?
At that point things might get "interesting"
I mean the ISDN Telephony network co-exists with the Internet. Those are highly different technologies, yet, at first we tunneled IPv4 over ISDN, now we connect the remaining ISDN Islands over IPv4.
Just like some people got rid of their fax machines, and many companies got rid of their BBSes after they got Internet access, people might build the cool new stuff on IPv6 while the legacy stuff continues to be on IPv4 until it's dropped.
@ShelLuser
My ISP for example supports IPv6, I even have a public IPv6 address. Unfortunately the router only provides this on the outside, on the inside only IPv4 is provided.
My ISP for example supports IPv6, I even have a public IPv6 address. Unfortunately the router only provides this on the outside, on the inside only IPv4 is provided.
are you sure?
most domestic routers and clients will use SLAAC which auto configures a host based of a routers WAN IP. otherwise if you know your WAN IPv6 address you could make up an IP for your host using the WAN Ip as DG and just change the last digit for the host address.
what happens when you do route print in dos or netstat -r in unix?
Using FUD ("oh noes, IPv4 running out! Epic fail!!") does seem to have worked against IPv6 adoption.
Might have taken a page from the Apple playbook and tried selling IPv6 as the next must-have upgrade instead of banging on about punters being left out in the cold on "IPv6 day".
Probably doesn't help than an IPv6 address looks more like line noise than the dotted quad most people have come to recognize as an "IP address". From sci-fi and police procedural TV shows, if nothing else.
"You've seen something that approaches real world accuracy in sci-fi and police TV?"
Of course not -- don't be dense. But if you've ever seen a CSI or NCIS or Spooks or some similar show then you've almost certainly seen them with the resident techie looking at a screen with IP addresses like "365.29.1.903".
Valid or not, that pattern is recognizeable even to non-nerds as "IP address", even if it's fiction.
Which was my point. Back to your regularly scheduled pedantry.
"You've seen something that approaches real world accuracy in sci-fi and police TV?"
Yes, you should check out the shows made by Jack Webb's Mark VII Limited, which includes Dragnet, Adam-12, and Emergency!. All three were particularly noteworthy for their real-world accuracy when it came to actual events. Indeed, the first two always included a True Events disclaimer ("The story you have just seen is true" for Dragnet, "incidents" for Adam-12).
Well, something might need to change. I'm vaguely aware there's a way to partly anonymise addresses but I don't know how that works. So until I work out how IPv6 works in my own time (because my job doesn't demand it), I'm sticking to IPv4.
IPv6 seems to be based on the premise that it would be cool for every device everywhere to be findable with the same address. I still don't know why that would be, we have DNS for that. I know why Google would be keen on it though.
IPv6 was published over 2 decades ago and still hasn't gained traction. It seems to be a solution looking for a problem, but it's the only one that also expands address space. Look how easy it would have been to expand an IPv4 address to 64 or 128 bits but keep the rest the same.
IPv6 seems to be based on the premise that it would be cool for every device everywhere to be findable with the same address.
Nope, more IP addresses are needed than IPv4, but the sensible addressing helps routing and reduces latency. IPv6 comes with privacy extensions to reduce the risks of having such specific ip addresses because IPv6 doesn't require a device to have a single, static ip address.
It seems to be a solution looking for a problem
No, it's more like IPv4 has been kept around by a whole heap of kludges and workarounds (mainly carrier NAT). These have increased the stop energy or inertia of the system which has led to more kludges and workarounds. We don't really notice the problems and costs associated with the fixes in the West but in the many countries with large populations and small IPv4 address spaces, it has been causing problems for years. Hence, unsurprising to see IPv6 being adopted in places like India: get it right and you've got quite a few less problems to worry about.
"IPv6 comes with privacy extensions to reduce the risks of having such specific ip addresses because IPv6 doesn't require a device to have a single, static ip address."
Which is better than nothing, but still rather inadequate. RFC 4941 defines the privacy extensions, and they rely on the use of "temporary IP addresses". The privacy gains from this aren't fantastic, and it comes with the downside that you can't have static IP addresses. The lack of static IP addresses is often not a problem, but it is also often a really huge problem.
For that reason, the privacy issues with IPv6 cannot be considered "solved". RFC 4941 describes a hack to try to give some measure of protection, not a solution.
Actually, using privacy addresses doesn't stop you from using static addresses too. You can have multiple addresses at the same time.
I agree the privacy gains aren't fantastic, but that's because most privacy issues are a result of cookies in browsers, or of mobile apps sponging every piece of data they can off of your phone. Obfuscating the right-hand 64 bits of your address, however you do it, is never going to give you fantastic privacy gains in a world where most privacy breaches come via a different vector.
"Actually, using privacy addresses doesn't stop you from using static addresses too."
Yes, I didn't mean to imply otherwise. But if you're using static addresses, then you have zero privacy protections, so it just makes the situation worse. The only available mitigation that I can see is to use NAT -- which, fortunately, you can do with IPv6.
"The only available mitigation that I can see is to use NAT -- which, fortunately, you can do with IPv6."
repeat after me: NAT IS NOT A FIREWALL - not in any sense of the world. if you want a firewall then bloody well use one.
Most dual-stack routers implement the same sets of rules on the IPv4 and IPv6 stacks. If yours is crufty enough to be broken in this respect spend the 20 quid to get one that does.
"No, it's more like IPv4 has been kept around by a whole heap of kludges and workarounds (mainly carrier NAT)."
But there are lots of people out there who LIKE (even LOVE) the kludged because they come with side benefits. For local network admins, it's a free layer of defense against outside intrusion (It's not like someone from the outside can directly connect to a machine behind a NAT, right? Instant benefit). And ISPs will probably accept the management of NAT's (especially carrier grade NATs) because it hamstrings their customers. No home servers without THEIR permission, for example (at a premium).
"I've been running servers out of my home for decades without my ISP's permission. Their NAT doesn't stop that."
My ISP just lets people run home servers if they want, you don't have to ask permission, and they have an opt-out firewall. Which I opted out of, coz it blocks the servers I want to run. A small extra charge if you want a static IP, no extra charge for IPv6.
"I've been running servers out of my home for decades without my ISP's permission. Their NAT doesn't stop that."
If you're running servers without the ISP's permission, odds are you aren't behind a carrier-grade NAT (otherwise, how would the other end know how to reach you without the ISP's OK?). I'm not, and I can run servers. But I'm noting that ISPs that DO use a CGNAT probably find the ability to control the customers' use of servers a bonus.
"And ISPs will probably accept the management of NAT's (especially carrier grade NATs) because it hamstrings their customers. "
What's actually happening in developing countries is that there end up being multiple layers of NAT
$LARGE national ISP has a /24. it assigns IPs to a bunch of smaller ISPs, who NAT it and onsell to smaller ISPs or home users who NAT as well.
It's not unusual to find 3-5 layers of NAT in some countries - and at one point the _whole_ of Vietnam was NATed via one IP address. NAT screws up connectivity pretty badly and that many layers makes things a clusterfuck as you can't rely on helper programs like you can if you're only NATing a small /24
"It's not unusual to find 3-5 layers of NAT in some countries - and at one point the _whole_ of Vietnam was NATed via one IP address. NAT screws up connectivity pretty badly and that many layers makes things a clusterfuck as you can't rely on helper programs like you can if you're only NATing a small /24"
Thing is, if they're resorting to multiple CGNAT layers versus IPv6, they probably don't care about the side effects. Worse, they may WANT the side effects as a means of control.
Yes, yes, we know, The Register is still IPv4, and not on IPv6. Word from our sysadmins is that we'll migrate Soon™
TFFT!®
Joking aside, that is very welcome news, although "go dual stack" would probably be more appropriate a phrase than "migrate," which has connotations of leaving v4 behind.
IPv6 has no business benefit. It won't increase sales or drive a business forward, so the bean counters won't fund it's implementation.
They would rather role out SAP for 100x the cost as there is a business case that accountants can understand, something IT infrastructure projects never have. IT is just a cost like Facilities, but least with Facilities you can see and feel it and it looks good when you repaint it..
Who is "Colt"? I assume not the firearms manufacturer, as it seems a stretch to claim having an IPv6 network will help you sell guns. So probably some sort of network related company? OK, if your business requires expertise with networking, eating IPv6 dogfood is necessary.
So what about a car company, say Ford? How does implementing IPv6 help them sell more cars? What about Kraft, how it does it help them sell more Velveeta? Even for tech companies....how does it help Apple sell more iPhones or sell more Apple Music subscriptions? OK the iPhone needs to (and does) support IPv6, but does Apple NEED to actually use it themselves other than for testing their products? No.
That's what it comes down to for the beancounters, you have to show that implementing IPV6 will pay for itself in increased business, or that not implementing it will cost them business. Neither is true for the vast majority of businesses out there, and won't even if most of the world has converted to IPV6 - because IPv6 clients can still access IPv4 hosts, and companies can continue to use IPv4 10 net addresses internally.
IPv6 has no business benefit.
Two words: Routing tables. Once IPv4 trading of sub-class C blocks begins in earnest (you ain't seen nothing yet) the black boxes that connect the dots that your MBA mentality doesn't even think about are going to start breaking in new, hitherto unseen and quite probably amusing ways.
IPv4 was designed with the old class system in mind. CIDR was an afterthought. Like so many of these afterthoughts such as PAE, it was a half-arsed, horrible bodge that just happened to mask one symptom while leaving the underlying disease in place.
Besides, this is the Internet. "Business interests" should not be your first concern. Keeping it open, neutral, working and self-healing should be. Again I find myself checking the address bar to make sure I'm on El Reg and not some bloody awful, buzzword-laden business think-tank site which has a bottom line of "how can we give everyone else a smaller share and us a bigger one?"
>Once IPv4 trading of sub-class C blocks begins in earnest (you ain't seen nothing yet) the black boxes that connect the dots that your MBA mentality doesn't even think about are going to start breaking in new, hitherto unseen and quite probably amusing ways.
I get the feeling another RFC is on the way...
Yes, it might be yet another 'sticking plaster' but to TPTB in business and government, such matters need to be resolved by those responsible for the Internet.
Re: MBA mentality
Remember the problems that were had in getting business to take Y2K seriously and more recently GDPR? "MBA mentality" is more widespread than you may think - particularly outside of the IT department.
Roland6 wrote: Re: MBA mentality
Remember the problems that were had in getting business to take Y2K seriously and more recently GDPR? "MBA mentality" is more widespread than you may think - particularly outside of the IT department.
Well said. Until the iceberg makes a hole, we steam on at full speed. Then we all go down together¹. I think they teach that damned mantra in Business Schmooze 101.
¹ Except Ismay, the White Star chairman, natch.
" never had to deal with RFC1918 clashes."
Or worse - someone who's pulled numbers out of their arse for internal usage "because we'll never connect to the Internet so it doesn't matter"
cue calls a few months after being connected "We've been hacked, our internal logs show mountains of connections from berkeley.edu (when they were using berkeley's IP ranges and an external IP resolver)
that it is much easier to type 121.234.56.24 than 2001:0db8:0000:0000:0000:ff00:0042:8329
which may have something to do with slow uptake by the rulers of the interweb. Obviously once the techies have done their bit and sorted out all that hex, Joe Bloggs shouldn't even see the difference.
>. IPv6 pretty much makes DNS mandatory.<
And my Name Server provider still doesn't provide IPV6, and my WWW host still doesn't provide IPV6.
No reason I suppose for my host to privide IPV6 when there is no way to link to it, and no reason for the Name Server to support IPV6 when there is nothing to link to. But since that's the case, no wonder my ISP provides routers that don't do IPV6.
But as a techie too, its much easier to work with 12 digit decimal numbers than 32 digit hex. You can fix the one in your mind, less so the other. But it was RFC1597 that killed fast IPV6 adoption. RFC1597/1918 also forces a number of convenient security practices, and also effectively prohibits a number of foolish practices, which is a useful weapon for techies seeking to impose good practise on management. So all in all sticking with IP4 generally suits the techies as well as the suits.
Have you worked with v4 and v6 networks? v6 networks are way easier to work with than v4 networks (which are inevitably NATed).
Even v6 addressing is easier, because hex lines up with subnetting boundaries better than decimal does. It's also possible to arrange for your v6 addresses to be more memorable than your v4 ones (compare 2001:db8:42::1 with 203.0.113.42+192.168.0.1 -- which of those is shorter?), although you don't need to most of the time because you generally work with hostnames, not IPs.
Who gives a soaring screw about boundaries and all that? It's still a lot easier to remember 24 digits than 32 alphanumerics, especially since we've spent decades memorizing telephone numbers which are practically all numeric. About the only random alphanumeric we encounter every day is the license plate, and who remembers any given license plate, let alone their own? Plus numbers are easier to convey orally, especially if you only lifeline is inconsistent.
I've always thought it would have been better if IPv6 was 64 bit instead of 128 bit. I mean, we went from a 32 bit to 64 bit address space in our computers , and there are no CPUs actually capable of utilizing all 64 address bits yet - even in a virtual address, let alone physical!
But yet someone thought we needed 2^64 more potential IP addresses than we need potential bytes in the largest possible servers?
These stupid IPv6 addresses would be a lot easier to work with / remember if they were only 64 bits, and you wouldn't have to worry about the ::: stuff because you wouldn't have all that wasted space in the middle that's so trivially zeroed.
Maybe someday in the far future, after most of those reading this are dead, 64 bits might become a bit tight. I highly doubt it, but I accept the possibility. OK then, decades later we will probably want new features for IPvNEXT and can go to 128 bits at that time. We will hit the need for 128 bit CPUs long before this day might arrive though.
>Even v6 addressing is easier, because hex lines up with subnetting boundaries better than decimal does.
Different design philosophies, with IPv4, it was to make things easier for human users before the days of DNS and real-time auto-lookup/complete of web addresses...
What is going to be interesting is how vendors get around default configurations. Suspect even after the world has gone IPv6, vendors will still use the IPv4 192.168.1.1 address (or similar) for the out-of-the-box default.
> You do know that you don't have to type all those zeros, right?
I think this 'convenience' is one of the things that puts people off as it results in what always looks like an inconsistently presented notation that on the face of it is less clear than the thing it's supposed to be an improvement on.
It's already a difficult sell and I'm wondering if they should have just left that out - we are not incapable of dealing with long numbers, even ones with letters in them.
And more emphasis on likening the prefix to country/area codes as a familiar concept would have helped, perhaps even without the apparent randomisation of prefix length and its representation.
At the most basic level it's a new numbering system that just looks too weird and quirky to enthuse people.
I don't think "inconsistent notation" is a problem for v6. I sat down and worked out sixty-six different ways to write a single v4 address, without even relying on padding zeros. If having multiple ways to write a single address was a problem then it's a problem that v6 actually improves on.
"But," you're thinking, "we never write v4 addresses like that.". Yeah, well, you don't ever write v6 addresses with leading zeros either; people who write them like that don't have much, if any, operational experience with v6. It's seriously not a problem in practice.
Here's the full list of v4 variations, for the interested. Sorry the list is a bit ugly, but I don't really have any way to make it look better in an El Reg comment. Every single one of these represents the same address, and they all work perfectly, at least on Linux with any program that uses getaddrinfo(). If we can handle v4 supporting all of these, then we can handle v6 supporting a few leading zeros in each field.
10.24.42, 10.24.0.42, 10.24.052, 10.24.0.052, 10.24.0x2a, 10.24.0.0x2a, 10.030.42, 10.030.0.42, 10.030.052, 10.030.0.052, 10.030.0x2a, 10.030.0.0x2a, 10.0x1a.42, 10.0x1a.0.42, 10.0x1a.052, 10.0x1a.0.052, 10.0x1a.0x2a, 10.0x1a.0.0x2a, 10.1572906, 10.06000052, 10.0x18002A, 012.24.42, 012.24.0.42, 012.24.052, 012.24.0.052, 012.24.0x2a, 012.24.0.0x2a, 012.030.42, 012.030.0.42, 012.030.052, 012.030.0.052, 012.030.0x2a, 012.030.0.0x2a, 012.0x1a.42, 012.0x1a.0.42, 012.0x1a.052, 012.0x1a.0.052, 012.0x1a.0x2a, 012.0x1a.0.0x2a, 012.1572906, 012.06000052, 012.0x18002A, 0xa.24.42, 0xa.24.0.42, 0xa.24.052, 0xa.24.0.052, 0xa.24.0x2a, 0xa.24.0.0x2a, 0xa.030.42, 0xa.030.0.42, 0xa.030.052, 0xa.030.0.052, 0xa.030.0x2a, 0xa.030.0.0x2a, 0xa.0x1a.42, 0xa.0x1a.0.42, 0xa.0x1a.052, 0xa.0x1a.0.052, 0xa.0x1a.0x2a, 0xa.0x1a.0.0x2a, 0xa.1572906, 0xa.06000052, 0xa.0x18002A, 169345066, 01206000052, 0xA18002A
> I don't think "inconsistent notation" is a problem for v6.
It is when you are trying to convince people that it is an improvement, and no amount of 'operational experience' willy-waving is going to matter if you can't convince people to take up v6 in the first place.
It's not the specifics, it's the lack of overall consistency of presentation of it, as I said in my remarks about the way it is put forward, and already being a difficult sell, i.e. to people not already using it.
Perhaps weirdly the inclusion of zeroes would probably be better because then the audience can be sure you didn't do a typo on the slide. There could even be a 'this massive set of zeroes is due to be split/used for x' remark to hint that there's an actual plan beyond just adding more numbers.
"You mean that in the early days somebody actually seriously proposed 16-bit networking addresses for a networking protocol that exited a building?"
At the time, there were probably only 50 institutions in the USA that might have a big enough budget to buy a computer, so using the second byte was considered future proofing, 4 whole bytes was exceptionally extravagant!
Seriously, though, who thought this kind of network breaking upgrade was a good idea?
Nobody thought it was a good idea, but it was considered the least disruptive with the most benefits of all the alternatives.
And if you look at the history of some of the more common protocols you can see the problems associated with maintaining backwards-compatibility for too long: SSL springs to mind.
"Nobody thought it was a good idea, but it was considered the least disruptive with the most benefits of all the alternatives."
In 1993 at the NANOG meeting there was a meeting to try and get IPv6 finalised and deployed before "the killer app" came along that drove usage sky high.
2 meeting rooms along at the same time, a presenttation was being made about NCSA Mosaic.
That's a really poor excuse. Why would you need to?
In my entire network, I "know" two IP addresses. One is the gateway. One is the DNS. The gateway is also a DNS server. Everything else is in DNS.
Hence, no matter what I do, I never need more than those two. And I need those precisely when: Setting up some brand-new, from-scratch settings for, say, DHCP. Which happens, what? Once in each job? Maybe once every few years at best?
Literally the last time I read out an IP address? I can't remember. Machine imaging? No address needed. Configuration? No addresses needed (it pulls from the image or the DHCP or the network in some way). Giving remote access to someone? Cool... remote1.domainname.com (which is the first external IP address... remote2 is the other one... I have LITERALLY no idea what they are, and don't need to know. They are documented somewhere, but I've never had to type them or read them out except to create that DNS entry). Printers? Nope. All DNS nowadays (and no user needs know the IP and I don't WANT them to know, and knowing doesn't even help them, as they are VLANned and go through the print management system anyway - which is only thing that actually talks to a printer direct - and the IP of the print management that shares out all the user-visible printers? Yeah, that's in DNS somewhere).
Hell, I don't WANT to hard-code IP's into the system (into devices may be different, but you can usually always let them get a DHCP allocation and then just reserve it). It makes replacing a machine so much more tricky. Wanna take serverA offline? Okay, spin up serverB. Make sure it's working and synced.
Change serverA DNS record to point at serverB instead (hell, you can CNAME it, still no IP address!). Hey presto, done. Did it all go wrong? Remove the CNAME. Did it all go right? Retire serverA. What their IPs were is literally unnecessary for anyone to know.
And I've yet to deploy a service where it demanded an IP address and wouldn't accept a fully qualified domain name instead (an IP range might be asked for, but I can't think of anything I'm deploying that requires a specific IP address - and if you have half a brain, your IP range is easily discernible from your any of your IPs and your subnet - and you use, say, the first address as the gateway, the second as a DNS, etc. so it's easy to set up anything you do have to touch).
About the only thing I know that might demand IP is things like HA heartbeats and stuff but even then I'm pretty sure you can just use DNS addresses. I very much doubt that Google are sitting them coding in thousands of individual IP addresses.
Yep, when I consult I see internal corporate networks ALL THE TIME that don't have proper DNS. The need to type IP addresses is constant. Sure, that can be fixed (would have to be) if they go IPv6, but it is just another in a long list of barriers.
But mostly, what the heck benefit is there for a company to run IPv6 in their internal network. They have a whole /8 to themselves. If the IETF wants to push IPv6, assign the 10 net and require routing it on the internet. That'll get action (of course the action might be burning at the stake whoever approved that RFC, but still)
But mostly, what the heck benefit is there for a company to run IPv6 in their internal network. They have a whole /8 to themselves. If the IETF wants to push IPv6, assign the 10 net and require routing it on the internet. That'll get action (of course the action might be burning at the stake whoever approved that RFC, but still)
its called Unique Local Address in IPv6 and its address is fc00::/7
https://en.wikipedia.org/wiki/Martian_packet#IPv6
do you just have 1 giant subnet with all your systems in it?
you will see significant benefits by subnetting. Even if you just have the 3rd octet for different systems than users things will be better as you cut out all the broadcasts being sent to systems that don't need to see them.
Vint:
"It's certainly been a long time since the standards were put in place"
Internet Society:
"On 14/07/2017, the IETF with the publication of RFC8200 announced that the Internet Protocol Version 6 (IPv6) had become the latest Internet Standard."
Less than a year doesn't seem a long time to me.
It must be frustrating for Vint Cerf to have fathered the internet yet be unabled to really influence what people are doing with it. I think Tim Berners-Lee must be feeling the same with respect to the WWW.
Respect to both for their visionary ideas and what they've given us, but I don't think even they could have seriously imagined that in such a short time we would be in a world where people can own and use multiple independent and separately- addressable devices.
This world has grown from people running with what they invented and isn't (was never) controllable by them.
As with real fathers, they ought to be listened to with respect, but they shouldn't expect to have too much influence - they have to let go of their children eventually.
I'm a contractor
I get paid through projects
What project gets financed when there is no need to implement it?
IT department, we need money to implement IP6 and there will be downtime for users and customers.
Board - Do we need to do this?
IT Department - No, not for ages, and even then probably we can get away with NATing stuff
Board - F**k O**f
Why fix it if it ain't broke?
We routinely use IPv4 on our sites.
I expect we will continue to do so - and just have a firewall NAT'ing between IPv4 and IPv6 should all the ISP's go over to IPv6 anyway.
Will have to wait and see what happens. Until then I'm not going to break anything yet.
There will come a point in time when there will be no more v4 addresses availble. Won't there?
So, businesses, old and new will not be able to expand if any part of their business, and any business plan, requires new IPv4 addresess on the assumpton that they cannot access v6 addresses.
It seems to me that being prepared for this scenario is common sense.
I remember working on C code bases for the Y2K problem in 1998 onwards.
It had to be done. Or else what have been the consequences for not doing the preparation?
'If it ain't broke don't fixit' is sometimes used as an excuse for the lack of courage to tell some other person that doing something will cost money now.
Sure they can. They'll just go into the address market and say they're seeking an IPv4 address of a certain range and see if someone's willing to sell it. Simple supply and demand are why people aren't absolutely forced into an IPv6 address even now.
"'If it ain't broke don't fixit' is sometimes used as an excuse for the lack of courage to tell some other person that doing something will cost money now."
Which could STILL mean someone's not that willing to jump. After all, aren't there tons of firms on razor-thin margins that still use lots of IPv4-ONLY equipment, meaning jumping to IPv6 isn't an option? And unlike with Y2K, a lot of the problem is hardware in basis for performance reasons, so they're basically stuck.
"say they're seeking an IPv4 address of a certain range and see if someone's willing to sell it. "
And when /24s are worth $250k a pop?
How are you going to justify that kind of spend to your accountant when once you get past the inflection point for IPv6, those IPv4s will be not only valueless but useless?
And when /24s are worth $250k a pop?
Well if there isn't a functional IPv6 well before then, there will be no Internet - if consumers are complaining about paying £30 pcm now for all inclusive Internet, I doubt they will stand paying an additional £10 pcm just for an IP address.
At some point it will become viable to discard the Internet and replace it with something else ie. Internet 2
Sure they can. They'll just go into the address market and say they're seeking an IPv4 address of a certain range and see if someone's willing to sell it.
...and hello routing table madness. Your "just" in that post assumes a simplicity that, while it's SEP (someone else's problem) invisible to the halfwit who caused it, certainly isn't simple. When we get to the stage that every company and its uncle Freddy has a routable /29 (six usable, probably NATted at the gateway on one of them) because that's all they could afford, let's just see how long the core routers stay up with all that extra load.
I'll say it again, you cannot do this reliably with v4. The infrastructure just doesn't support this level of granularity in the address space - which is before we consider rDNS, delegation of off-boundary subnets, misconfiguration and/or assumptions leading to broadcasting on someone else's block etcetera.
Makes remembering 2001:f00:f00::/48 seem a bit like whining about the weather, doesn't it? If your NOC still has kit from nineteen-hundred and frozen stiff that doesn't support v6 and/or admins who refuse point blank to re-skill to v6, perhaps it's time to replace them? They will be full of bulging capacitors, the congealed remnants of the shed skin and sandwich crumbs of a couple of decades, inefficient and power-hungry. The routers won't be looking too healthy, either.
"I'll say it again, you cannot do this reliably with v4."
Bull-crap will say the higher-ups. We're not plunking down and that's that. No budget. And messed up routing tables? Explain the jumble of telephone numbers. Now JFDI...or rather, DIE before we decide to start looking for someone who WILL JFDI.
@chronos
When we get to the stage that every company and its uncle Freddy has a routable /29 (six usable, probably NATted at the gateway on one of them) because that's all they could afford, let's just see how long the core routers stay up with all that extra load.
I'll say it again, you cannot do this reliably with v4. The infrastructure just doesn't support this level of granularity in the address space -
we are almost at that stage already & the world hasn't broken. The biggest problems are when the IP's are used out of region, but even when reused in region between different IPS's from where the main block originated it causes a new global route entry, so the mere act of creating / having a /29 is most likely to have caused a new route entry anyway, doesn't matter where it is.
It is slowly breaking, however. We're spending a lot of money shoring it up and trying to work around the parts that are creaking and groaning, sometimes with more success and sometimes with less success.
Just because it hasn't actually snapped into two yet doesn't mean there aren't problems.
So long as you like spending money on life support, relying on third-party relay servers for everything and enjoy NAT, CGNAT and RFC1918 clashes and networks that are hard to reason about and require workarounds everywhere to deal with address space shortage, then sure, no incentive.
...in other words, no, there's quite a lot of incentive. Why would you deliberately ignore it all?
"So long as you like spending money on life support, relying on third-party relay servers for everything and enjoy NAT, CGNAT and RFC1918 clashes and networks that are hard to reason about and require workarounds everywhere to deal with address space shortage, then sure, no incentive."
If YOU'RE the one in control of the relay servers (like Microsoft and Skype), then you WANT the status quo. It gives you an in to valuable demographics (one reason for the AT&T/Time Warner merger). And as long as the NATs and so don't negatively and directly affect you (which they don't if you control the relay server; the user connects to you through the NAT), then it's SEP.
My router is 10.0.0.1 Main PC 10.0.0.2 [ ... ] I'll never remember: My router is 2001:0db8:85a3:0000:0000:8a2e:0370:7334
Apples and oranges.
The ip6 you give is a globally routable address.
There's nothing stopping you validly configuring your private lans as
fd00::10.0.0.1
fd00::10.0.0.2 etc.
(Yes, you can represent octets as dot-seperated decimals if you want) or if you prefer to go all BCD, you could use:
fd00::10:0:0:1
fd00::10:0:0:2
etc.
There is nothing magically different about the IP4/IP6 addresses - each one is just a number - one happens to be 32 bits wide, the other 128.
This post has been deleted by its author
1) 20 years of failed migration is a big fail!
2) It is too late to re-engineer IP/ng
3) Next time, make sure the engineers get prime role, rather than academics, the corporate lawyers etc, who were sent to IPv6 standards committees
4) Go back to old IETF policy of competitive protocol proposals and (more importantly) bake-offs to see which work best.
It is very enlightening to read the comments here.
A few years ago, we ventured into studying the IPv4 address pool exhaustion subject by accident, perhaps due to our background in telephony. We now have submitted a proposal to IETF called EzIP (phonetic for Easy IPv4). It will not only resolve the IPv4 address shortage issues, but also mitigate the root cause to the cyber security vulnerabilities, plus open up new possibilities for the future Internet, all within the IPv4 domain, by just enhancing it with existing technologies and standards.
It looks that many colleagues here are expressing their own experiences with the IPv6 which validate the "myths" that led us to begin our efforts. I would like to share our approach with whoever interested.
For the record, he seems to be referring to this spec submitted to the IETF. From what I can make out, it essentially leverages the RFC1918-defined private spaces to extend the publicly-accessible space, though the document is a little hard for me to grok completely. Perhaps one can provide a slightly-less-technical version of what it's trying to do.
Sorry to get you digging up the antique stuff.
Because this is my first posting on this website, I did not know the threshold for restrictions. My initial posting got rejected probably because I included explicit URLs to the latest IETF paper on the subject through my business's website. My resubmitted version without URLs appeared to be acceptable since you have read it. However, I knew it was so academically vague that it could lead to misunderstandings.
I am glad that you know how to find material on the web from sketchy data points. Since you have located the beginning of my public reports (which referred the solution as ExIP), may I provide you the follow-up hint that the document series has been advanced to version 03 with an even more condense title?
It appears to me that you hide the URL behind a hyperlink to get through the screening. So, if you can not find the EzIP version on IETF, let me know. I will try to provide that URL through the hyperlink technique.
Thanks.
It's not the link that's the problem. It's probably because you're new here and posting a business address ... which, three or four nines of the time, is spam these days. If you instead post a link to the IETF site, I'm fairly certain that the ElReg mods will allow it.
(Note: I don't speak for ElReg, I'm just making a couple educated guesses.)
Hi, Jake:
I did not include a business address in the initial posting, but used our website (could be interpreted as so) to cite two reference documents. One is the hyperlink to the IETF paper and the other is a short summary that Charles 9 asked for, after he located the very primitive version of what I intended to share.
Anyway, let's proceed step by step. Below is the direct URL to the latest proposal to IETF:
https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03
Let's see if this gets through the screening.
Then, if a short summary is still needed, I would need your guidance to figure out how to share it without breaking the rules on this website.
I'm probably the wrong person to ask about not breaking (or bending) rules on this web site :-)
The forum rules, such as they are, are here: https://www.theregister.co.uk/2012/02/01/register_comments_guidelines/
Your link is up, but I rather suspect that this particular comment thread is the wrong place to post it, for a lot of reasons. You might be better off creating a new topic for it in the User Forums , probably under "Chew The Fat". Note the "Creating a new topic" rules in the above guidelines (Hint: You'll need to make a couple more posts before you'll be able to create a new topic).
I found the IETF draft from the hints in your first post. I'll probably look it over tomorrow. I'm all for increasing address space, but I in no way agree that we need a separate globally routable IP address for every person, place and thing online. I'm not even all that certain that each home needs it's own IP address ...
Hi, Jake:
Thanks for the link to the forum rules. I have read it but was not sure what particular threshold that I crossed. Rather than digging into them, I will just do "try and error" approach for now.
I fully agree with your general concepts about what the Internet should be. I can assure you that the EzIP approach was developed based on such principles. Although it started with the goal of providing every IoT a public address, that was because it is the primary feature of the IPv6. Between lines, you will find that the NAT is not excluded from the EzIP plan. In fact, a comment is made in our report that with the use of private networks, there will be even more public IPv4 addresses available for assignments.
I look forward to your comments, in particular, those topics that do not agree with you.
Abe (2018-06-20 06:49)
Hmm, it pretty much reads like I thought it read originally. The essential idea is to use the IPv4 equivalent of a PBX router at IP endpoints. These endpoints will then be used to interpret specially-formatted IPv4 packets (they have RFC1918 addresses and a specially-encoded Option Word that IS part of the IPv4 spec) to act as extensions. Still have to wonder how these extension packets would get routed correctly, especially since most outside routers are supposed to drop packets with RFC1918 addresses. It's similar to a concept I'd thought about to introduce an extended routing packet to an IP endpoint to tell it to continue routing something internally, but I realized that implementation would not be as easy as it sounds, particularly if a single IP endpoint is simultaneously handling multiple connections.
Hi, Charles 9:
It sounds that you read the version 03 of the IETF proposal, but somehow locked onto the original understanding about ExIP making use of the addresses out of the RFC1918 specification, without recognizing that it has been changed to 240/4 block. This is one of the key breakthroughs in our work, because EzIP implementation can now be independent of rules and restrictions imposed by existing routers.
While the principle (making RFC791 to transport the "extension address" information) behind EzIP (Ver. 03) is the same as that for ExIP (Ver.00), the address block utilized is totally different, making the SPRs (Semi-Public Routers) in the two versions of proposal distinct in terms of avoiding to affect existing Internet operations, etc. The EzIP makes use a long-reserved address block 240/4 which has always been rejected by all existing routers because it is marked as "experimental" as you correctly stated. In addition, by placing SPRs between the ERs (Edge Routers) and the private premises (either the RG- Routing Gateways or the directly connected IoTs) and exclusively making use of the 240/4 address block, a full spherical layer of new routers is formed. Essentially, IP packets go through a complete isolated new world with routes defined by the 240/4 block to get the number or addresses multiplied by 256M fold without the involvement of any existing routers. This happens at both source and destination ends of a link.
In fact, by utilizing RFC791 to carry these 240/4 addresses as payload of the IP header, the existing routers will not be expected to route such addresses, thus avoiding being dropped.
Examples in Appendix A.2. of the IETF proposal Ver.03 (EzIP) illustrate the transitions through the routers.
Please let me know if the above clear up the subject.
Thank you,
Abe (2018-06-20 17:09)
I spent some time ingesting that draft, and I have a silly question... how is it different to running 6to4+NAT64?
To explain, I'm going to describe a network setup using Figure 1 as a basis, but using 6to4 and NAT64 instead of EzIP.
First, convert the WAN IPs of the SPRs into hex (4529be6e/4529be94), and set up 6to4 on each of them. SPR1 gets 2002:4529:be6e:/48 and SPR4 gets 2002:4529:be94::/48. Now set up NAT64 on SPR1 and SPR4, such that the 240/4 addresses behind SPR1 are mapped into 2002:4529:be6e:64::/96 and the 240/4 addresses behind SPR4 are mapped into 2002:4529:be94:64::/96.
It's also necessary to put /64s from the 6to4 allocation on each network. Let's say that T1a/T1z's network gets 2002:4529:be6e:1::/64 and T4a/T4z's network gets 2002:4529:be94:1::/64. T1z now has two IPs (192.168.1.9 and 2002:4529:be6e:1::9) and so does T4z (246.1.6.40 and 2002:4529:be94:1::1640/64). T1a and T4a still only have one address each (192.168.1.3 and 240.0.0.10), since they only support v4 -- but they are also reachable by 2002:4529:be6e:64::192.168.1.3 and 2002:4529:be94:64::240.0.0.10 due to the NAT64 running on SPR1 and SPR4.
The DNS records for T4a are now 69.41.190.148 and 2002:4529:be94:64::240.0.0.10. The DNS records for T4z are now 69.41.190.148 and 2002:4529:be94:1::1640.
Now consider the example in A.1 (a connection from T1a to T4a). How does it work with this 6to4+NAT64 setup? Basically nothing changes here; T1a sends a plain v4 packet from 192.168.1.3 to 69.41.190.148 and SPR4 needs to DNAT or DMZ it somewhere. A.3.1's scenario (T1a->T4z) is also essentially the same as this.
Next, consider A.2 (T1z->T4z). T1z sends a v6 packet from 2002:4529:be6e:1::9 to 2002:4529:be94:1::1640. The packet is routed through RG1 and reaches SPR1. SPR1 extracts the address of SPR4 from the dest IP (2002:4529:be94:1::1640 -> 4529:be94 -> 69.41.190.148), wraps the v6 packet in a 6in4 packet, and transmits it over the internet to 69.41.190.148. SPR4 receives the packet, unwraps the original v6 packet and forwards it to T4z.
Finally, A.3.2 (T1z->T4a). A.3.2 is weird in your draft, because it says that T1z should send a native v4 packet, and that the packet will be treated the same as the A.3.1 case... but that would mean that T1z has no way of addressing the packet to T4a. It has to resort to talking native v4 to SPR4 and then relying on port mapping or DMZ on SPR4. Doesn't this completely invalidate the point of the draft? It would make more sense for T1z to send an EzIP packet addressed to T4a (that is, 192.168.1.9 to 69.41.190.148 with extension headers that specify 69.41.190.148-240.0.0.10), and have SPR4 convert it to a native v4 packet for delivery over Premises 4's network to T4a.
I'm just gonna assume that's what A.3.2 supposed to say. The 6to4+NAT64 equivalent is for T1z to send a packet from 2002:4529:be6e:1::9 to 2002:4529:be94:64::240.0.0.10. The packet reaches SPR1, which sends it inside 6in4 to 69.41.190.148. SPR4 again unwraps the packet, but this time it spots that the destination is in 2002:4529:be94:64::/96, so it converts the packet to a native v4 packet with a dest IP of 240.0.0.10 and sends it to T4a. The reply packets get detected by SPR4's state tracking and converted back.
That's pretty much how things would work with 6to4+NAT64, and it seems to me that it largely has the same properties as your draft does. but with the added benefit of already being supported by existing software and hardware.
There are some other weird parts in the draft; for instance it says that RG1 is EzIP unaware, yet appendix A says that RG1 needs to insert "TCP ports" in the forwarded packet, which is an operation that routers don't currently do. There are other mentions of TCP ports elsewhere too which I kinda glossed over a bit, because TCP happens at a higher layer than IP and so should be irrelevant here. It's not supposed to be TCP-only, right? That would be called out right in the abstract, or better the title, if so. If not, then those "TCP ports" are actually weirdly-named extra option headers... but that's inconsistent with the IHL field which is explicitly 5 in the example packets shown with them.
The primary difference between the 6to4+NAT64 setup above and the setup described in Figure 1 seems to be the network behind RG1, which is described as being v4-only with an EzIP-unaware router in front of it (but, as I say, there's some disagreement about whether it's actually unaware or not). If RG1 is indeed unaware then nobody will be able to address T1a and T1z from outside their network, because they're hidden from SPR1 by NAT. Inbound connections to them aren't possible without relying on port forwarding rules.
In the 6to4+NAT64 setup, RG1 is definitely aware and inbound connections work fine. It's possible to set up a network where it's not aware, and if you do that then inbound connectivity ends up looking the same as it would with an unaware RG1 in the Figure 1 case. The problem is that T1z will lose its ability to directly address T4a and T4z, since it was relying on v6's dest IP field for that and it can't use that when on a v4-only network. You'd need some mechanism for T1z to communicate its desired dest IP to SPR1, and I don't think that's actually something we have yet. (Perhaps Teredo would do the job, if both SPR1 and SPR4 were Teredo relays. If they're not relays then you end up relying on both Teredo and 6to4's native IPv6 interop, which ought to work but doesn't always.)
If this is really the main difference, then wouldn't you be better served by focusing on this specific aspect (of T1z-on-unaware-network) and relying on technology that already exists for everything else? What advantage are you getting from reinventing those things rather than reusing them? At the moment it just seems like you're unnecessarily raising the implementation and deployment hurdles for yourself.
[This was a bit of an epic post for a comments section, but at least nobody can accuse me of not thinking about their suggestions -- when the suggestion is more substantial than the typical "just add an extra 0-255 to the beginning of the address", at any rate...]
I think part of the disagreement is over what to do with still-in-use legacy stuff (especially legacy hardware which can't be expected to be retired or replaced anytime soon) that can ONLY grok strict IPv4. They can't be replaced or upgraded to grok IPv6, yet there may be a need for it to cross the IPv6 network. Supposedly, someone's proposing a way to make this possible using nothing but IPv4, though I also have questions about how the whole business would go down in practice.
Hi, Charles9:
0) Thanks for your comment.
1) "legacy hardware which can't be expected to be retired or replaced anytime soon ... ": This is the first criterion when we started to formulate the EzIP scheme.
2) "there may be a need for it to cross the IPv6 network ": Yes, we want IP packets to be able to cross the Internet which does not need to be IPv6. Under the Dual-Stack configuration, we can view the Internet as based on IPv4.
3) "make this possible using nothing but IPv4": Yes, the facility has been in plain sight ever since the original RFC791 that defined IPv4. It has the Option word mechanism in the IP header that can carry any binary string (formed into 8-bit octets) as payload. So, existing Internet routers will not act upon the extension address information contained in the Option words.
4) The EzIP is not implemented into existing routers, but into an added "sphere" of new routers, called SPR (Semi-Public Router), inserted inline between an ER (Edge Router) and the premises it serves. So, the SPR is installed where the service is needed, not affecting the existing equipment.
Hope these clear up the concerns that you have.
Abe (2018-07-06 18:25)
How can we be sure routers will honor the option fields since there are already security concerns about the option fields: they already tend to block options around Record Routes (either for Loose or Strict Sources), so they may be leery about accepting other options. Next, how will the legacy hardware use the system if they aren't able to insert Option fields themselves? Sounds like a similar problem from a different angle. Furthermore, since the scheme requires the use of a new kind of edge router, why not just use the same location for some kind of proxy server for those instances where an IPv4-only device MUST talk to an IPv6-only device (as a proxy is the only practical approach to bridging the protocols) without using options that they may not be able to make?
In essence, using the option field seems to have incompatibility issues of its own that make it just look like IPv6 in another package.
1) "How can we be sure routers will honor the option fields since there are already security concerns about the option fields ": Yes, this could be a concern, potentially on purpose due to "political" positions. This is covered in Para. 4. A. Fast Path with a positive tone.
2) "how will the legacy hardware use the system if they aren't able to insert Option fields themselves? ": The proposed SPR (Semi-Public Router) will be designed with CG-NAT equivalent capability to deal with the legacy hardware during the "transition" phase (We know that this could be very long). The IP header transition examples in Appendix A. and descriptive text in Appendix B. detail this process.
3) "why not just use the same location for some kind of proxy server for those instances where an IPv4-only device MUST talk to an IPv6-only device (as a proxy is the only practical approach to bridging the protocols) ": Yes, after working out the basic scheme for extending the address pool under the constraints from the existing Internet structure, one of the deployment configurations is to just take one IPv4 public address to serve an isolated area (like an island) with up to 256M IoTs. In such case, a proxy would be utilized as the gateway to this "sub-Internet". This is mentioned in the Abstract and in Para. 3. C. c. 2. Also, you may see this even more clearly in Slide 10 of the graphic presentation whitepaper that I mentioned previously:
http://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf
Although the context here is all about staying withing IPv4 domain, there is nothing preventing the WAN facing port of the proxy gateway to operate based on IPv6.
4) "using the option field seems to have incompatibility issues of its own that make it just look like IPv6 in another package": Aside from Pt. 1) above, the EzIP does not run into any baggage issues like IPv6 because we consciously avoided them following backward compatibility discipline. The interesting thing is within the "sub-Internet" as defined above, the 240/4 addresses can be, (and we recommend) used as regular Source and Destination addresses in the IP header since carrying the common external IPv4 public address for the entire island is unnecessary. In fact, it is wastefully meaningless duplication and tends to cause confusion. Please refer to Para. 3. C. c. 3. of the IETF draft. This is where the networking parallelism to PABX becomes vividly clear.
5) Hope the above are clearing up the topics. By the way, I am very grateful for the opportunity to chat with you like this in sorting out technical topics. I am curious of your background and expertise. To start with, allow me to submit you the URL to my LinkeIn profile page.
https://www.linkedin.com/in/chen-abraham-b7a918/
Regards,
Abe (2018-07-07 18:04)
Hi, Nanahi:
0) Thanks for your comments.
1) "I have a silly question... how is it different to running 6to4+NAT64?": However, I can't even fathom what your question is. As hinted from my initial writing, my knowledge base is just barely capable of understanding IPv4. What I was attempting was to deal with the IPv4 address pool exhaustion issue with technology available within the IPv4 domain. Once you start to make use of IPv6 terminology, you have lost me. I must raise my white flag to avoid wasting your energy further. I hope you understand.
2) On the other hand, the underlying preamble of this series of the discussions is that if the need (for more addresses) can be resolved within the IPv4 domain, there is no need to bother going beyond (such as relying on IPv6) at least for now. Would you agree?
3) With the above references, let's carry on. Since you are obviously very familiar with IPv6, I must assume that you are fluent with IPv4, as well. Then, my anxious question is, do you see anything wrong with the EzIP technique? Putting away advance solutions that are based on IPv6, any flaw that you can spot in the EzIP? Let's focus on these basics, first. Thanks.
Abe (2018-07-06 18:03)
Okay, you really need to familiarize yourself with v6. You have no reason not to be familiar with it already, especially if you're trying to make something like this.
It's already possible to deal with v4-only devices in a v6 world with NAT64/NAT46, and to deal with communicating over a v4-only internet with 6to4. What you've come up with more or less replicates features that are already available in v6, and you haven't managed to avoid any of the backwards compatibility issues that v6 has. That's the main technical issue I have with it.
If you want to do better, you need to know what's already possible.
Hi, Nanashi:
Sorry that I am not following your logic at all.
That is, if I can get a job done (getting much more assignable public IP addresses than the foreseeable need) with a pair of forty years old well-tested IPv4 technology (RFC791 and 240/4 address block) without knowing a thread of hint about IPv6, why should I beat my brain to death in studying anything to do with the immature IPv6 techniques?
On the other hand, please do not evade my question. That is, can you find anything wrong with the EzIP scheme? For example, you mentioned "you haven't managed to avoid any of the backwards compatibility issues that v6 has." Good, at least you do agree that IPv6 has this issue. But, could you identify what aspect in EzIP caught your eyes? Please be specific.
Thanks.
Abe (2018-07-26 22:15)
The problem is that no matter how you sugar-coat it, no device can talk to a device behind a one-to-many NAT without help. It's a physical impossibility, like trying to figure out which Bob is Alice's Bob. Your solution doesn't address that issue. You use an edge proxy in your scheme. Switch that for a NAT46 proxy and you achieve the same function with an external IPv6 Internet (and note: NAT46 and NAT64 have been on the IETF drafts for nearly 20 years), with your IPv4-only devices none the wiser. Either way, you're still going to need the complete address of the other end (the option fields in your scheme, the IPv6 address with IPv6) to feed to your edge proxy.
And in the meantime, your system doesn't address some of the other reasons for IPv6's enlarged address space, such as simplifying the routing (which is now not only a matter of space but also time: a critical factor when high-end high-throughput routers and so on get kneecapped by latency).
IOW, everything you propose with EzIP already has equivalent solutions in IPv6, including ways for IPv4-only devices to access IPv6-only devices by proxy. Meanwhile, IPv6 addresses other issues NOT covered by EzIP.
The SPR under EzIP scheme is a simple router. It does not use NAT. So, the SPR is transparent in both directions. It does have NAT (or, CGN) function for transitional purpose because legacy IoTs need it, This is for backward compatibility.
Let's focus on what we set out to do 30 years ago. As you said, do not sugar coat the IPv6 with secondary features while the main solution even does not follow the basic engineering discipline. Remember the starting point for IPv6 was to solve the IPv4 address shortage issue. Why didn't we work out a straightforward upgrade procedure for such basic function, but now relying on a lot of "features" as selling points for IPv6?
Again, please be specific about what you see in the EzIP description as issues. Thanks.
Abe (2018-07-27 20:13)
Hi, Charles 9:
What I meant was what do you see in a proposal (EzIP) that is simply utilizing something purely "historical" (Both RFC791 was released and 240/4 block was reserved in 1981) that is not backward compatible with "today's" Internet? Thanks.
Abe (2018-07-29 13:23)
I'm not suggesting you bust your brains over it. It's just v6, it's not difficult.
I did largely answer the question: you've basically come up with v6+NAT64+6to4, with more or less the same features and drawbacks as those. So it should work about as well as they do, but also have the same drawbacks as they do You still have the same "existing hosts need to be upgraded" problem, the "existing routers need to be upgraded" problem, the "existing software needs to be upgraded" problem, the "you can't talk between them without a translator" problem, and roughly every other problem. It's still not backwards compatible, except in the ways that v6 already is backwards compatible.
That's the general problem with it: that it brings nothing new to the table, doesn't solve any unsolved problems and doesn't add any new backwards compatibility that we don't already have. It also doesn't solve some of the problems v6 does solve, so it doesn't avoid the need to do v6. Plus, it currently has no software or hardware support and no existing deployment, while v6 already has many well-tested implementations and is actively in use by 25% of internet clients already.
That just doesn't seem like a great combination of things to be spending our limited effort on.
Hi, Nanashi:
It appears that you are stuck with the IPv6 mentality, so to speak.
Please note that there is nothing to do with IPv6 in the whole EzIP schema. We are dealing with the fundamental address pool shortage issue. The only protocol involved is RFC791 which is as old as the Internet (1981). It can not be more simpler. We do not need to draw in IPv6 protocols to diffuse our attention, by sugar coating.
To start with, the only module needed to realize the EzIP service is the new inline SPR. All current Internet components do not need be modified. Only certain IoTs need be upgraded to be EzIP-capable if they desire to enjoy the router, instead of the CGN, service from the SPR.
Without disclosing the specifics, I can inform you that the EzIP proposal has gotten a couple senior Internet governing body experts into the thinking mode for awhile, because it reminds them about what dial-up modem did to PSTN and NAT did to Internet as well as the far-reaching implication of the stealth sub-Internet configuration that can implement the ITU-T's CIR (Country-based Internet Registry) model in a much concise and non-confronting manner.
By the way, you may know that the only IPv4 activity in IETF was SunSet4 WG which has been "institutionally" "concluded" in May. So, the above event is significant.
Your thoughts?
Abe (2018-08-18 10:41)
But it does NOTHING to the routing table issue, which is ANOTHER thing addressed by IPv6 AND one with real-world consequences. Because of the IPv4 address shortage, the organization of the addresses got thrown out the door. Basically, you can't be sure an address starting in 109 or whatever goes to the same physical region anymore, and if you're an upstream router, that means your routing tables just got complicated. Sure, the telephone exchanges have to deal with this now, but their problem isn't of the same scale. Instead of millions of requests an hour, it's per minute. The end result is increased latency all throughout the Internet, multiplied by each hop the packets have to make. So there's more problems to IPv4 than just address exhaustion.
Hi, Charles9:
0) It seems that you are diverting to other topics.
1) "it does NOTHING to the routing table issue ": What EzIP does is to create a huge public sub-Internet (up to 256M extension addresses) under each current public IPv4 address. As long as the party assigning these "extension numbers" refrains from giving them to subscribers located all over the world, there is no routing table expansion to worry about, but only the local new routing table to maintain by whoever responsible for that sub-Internet.
2) " Sure, the telephone exchanges have to deal with this now, but their problem isn't of the same scale. Instead of millions of requests an hour, it's per minute. ": What I will say below may sound like out of sync. But, it could illustrate the concept. It appears that you likely have not being in a telephony local CO (Central Office). In the old days, a CO in US served 10K subscribers max per unit (Each group of the last four digits was assigned a EXChange number which was the fifth and up numbers) because the size of electro-mechanical (step-by-step) switching components. When one walked into one of such equipment room, it sounded like a tin-roofed shack in a thunderstorm! That would give you some idea how much calls were going through and why the telcos were making so much money. Nowadays, an ESS (Electronic Switching System) room just got humming sounds which come from sealed miniature relays and ventilation equipment. One of the "scale" difference that you are inferring to is probably because a voice call needs only one setup, but each packet needs be routed individually. On the other hand, they are by design. That is, can per packet routing be more efficient, say by per session basis?
3) "The end result is increased latency all throughout the Internet, multiplied by each hop the packets have to make. ": The number of hops can be controlled if the IP addresses were assigned hierarchically by geophysical locations of the subscriber which is the rule that PSTN followed. The switching hierarchy (equivalent to Internet's Core Routers) takes advantage of this to limit the maximum number of trunks (equivalent to Internet's hops) to only 5 around the whole US (and at most one more for international calls). In fact, many calls are connected by fewer trunks through the use of direct trunks between COs with high traffic. For example, between SFO and NYC and many other similar major cities around USA have direct optical fiber trunks. As a matter of the fact, I believe Internet has similar facilities.
4) This leads to one of my long time puzzlement that you may be kind enough to explain. That is, since IP addresses in the IP packet header do not indicate the physical locations of the sender and receiver, how does a packet get routed through the Internet? I begin to look into Autonomous Systems (AS) that mentioned here and there. They seem to be the actual equipment doing the routing. But, I was shocked to find that their numbering system appears to use also 32 bits just like IPv4! Could you briefly describe how all these play together to deliver an IP packet that does not have the destination information to a human's eye? Thanks.
Abe (2018-08-22 20:07)
I spent quite a few hours getting my head around your draft. I don't think I'm stuck in any thinking here; it's just that the draft really does describe a system that is largely the same as IPv6 with 6to4.
If you want to convince me that's not the case, then you're going to have to explain exactly how it's different. I went to a lot of effort to explain to you why it's not different; now it's your turn.
"I don't understand v6" isn't enough to convince me that you've come up with something that's different to v6. If anything it just makes it even more likely, because v6 is about as simple as it can be given the constraints it's working under, which means it should be no surprise that an independent attempt to do the same thing ends up looking more or less the same. How can you be so sure you've come up with something different without knowing the thing that you claim it's different to?
Please note that there is nothing to do with IPv6 in the whole EzIP schema. We are dealing with the fundamental address pool shortage issue. The only protocol involved is RFC791 which is as old as the Internet (1981).
This isn't true. You're building a new protocol on top of v4, so you're no longer dealing with only v4. And it so happens that the manner in which the protocol you built works is exactly the same way v6 with 6to4 works. There is the minor difference of using an extension header rather than a protocol, but that's just an implementation detail.
To start with, the only module needed to realize the EzIP service is the new inline SPR. All current Internet components do not need be modified. Only certain IoTs need be upgraded to be EzIP-capable if they desire to enjoy the router, instead of the CGN, service from the SPR.
And all of this is exactly the same as it is in v6. The "SPR" is basically a dual-stack router. In v6, you can deploy a dual stack router without touching anything else. Only "certain IoTs", to use your term, need to be upgraded to use the dual stack router instead of relying on CGN. You aren't describing anything that we don't already have in v6.
Hi, Nanashi:
1) Appreciate your efforts. However, I am afraid that you are still looking at the EzIP from the vantage point of your IPv6 knowledge, What you really need to do is pretend that you only know RFC791 and walked into the "never land" of 240/4 address block that was "Reserved for Future use" for all these times. Can you see the EzIP scheme? In a sense, this is a real life "back to the future" case.
2) As I wrote in one of my comments, we are really not talking about "backwards compatibility", but making use of the "forward-thinking" of the RFC791 author. This is the art of system engineering that not only sorts out the current situations, but also lays out some ground work to cover the imaginary future, whatever it may be.
3) "I went to a lot of effort to explain to you why it's not different; now it's your turn.": Unfortunately, standing at my disadvantage point, I have not gotten a clue of your explanation at all. Allow me to explain:
"the draft really does describe a system that is largely the same as IPv6 with 6to4.": As I professed that I know barely enough about networking to figure out EzIP. IPv6 is way above my head. The four time address length already threw me into the dungeon, let alone the new header format and beyond. that is, anything touches IPv6 is different from IPv4 for me, unless you can describe it. So, I am hopeless to understand your explanations packed with IPv6 terminologies. I am very honest about this. Please see my LInkedIn profile below to see where I came from:
https://www.linkedin.com/in/chen-abraham-b7a918/
4) So, I can't accept your challenge to understand what you have been talking about even if I tried very hard. On the other hand, one of my favorite professors told me that "if you can not explain what you think you know to a random person from the street, you do not really understand your subject yet.". I strive to follow this teaching throughout my life on everything I do. On the other hand, I am not shy to admit that I don't know or can't do something. So, allow me to reverse the challenge to you, since you know both IPv6 and IPv4. Do not just throw terminologies at me, but verbalize them in descriptions and use graphics if needed. To do this more efficiently and without burdening other colleagues on this forum, let's do this offline. You can reach me through the author's eMail address in the EzIP Draft.
5) For example, I hinted about the parallelism between PSTN and Internet at some point. You can find a graphic presentation of the overall system architectures with description in page 12 of the following whitepaper:
https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf
Thanks in advance for you kind patience.
Abe (2018-08-30 16:16)
Since I'm going at this more from a layman's perspective, perhaps I can explain.
1. Imagine your walk into a bar with a pint glass and find everyone drinks their beer by the liter. Sort of a "When in Rome" kind of situation. Which would be easier: getting them down to your level or adapting and fitting in to theirs?
2. RFC791 was necessarily constrained due to the limits of computing technology at the time (think 1MHz processors and where kilobytes were at a premium). It's like the whole "640K" thing. At some point, reality eclipses the imagination, at which point it's time to start fresh.
3. The IPv6 packet format isn't so much more complicated as it is different. It's like an Englishman suddenly getting thrown deep into China. You're just going to have to sit down with the specs and work this bit by bit, much like a language course. One thing about IPv6 is that its most basic header just gets down to the nitty-gritty. The rest of the stuff is optional. Wikipedia provides some relatively simple descriptions and diagrams. Compare IPv6's format to IPv4's. As for the 128-bit address format, that's future-proofing. It's not the first standard to even use it, either (look up ZFS and its thought process for using number formats that large). Current theory is that there aren't even that many molecules in the entire universe. So there's room to solve that other problem I've been mentioning but your system never addresses (complicated routing tables--that MUST be addressed from the root to be effective or you just have TWO complicated routing tables to mess with)..
Hi, Charles 9:
1) Re: Ur. Pt. 1.: From my perspective, IPv4 is the "liter" and IPv6 is the "pint" in terms of how much each is carrying the load (Internet traffic / beer):
https://ams-ix.net/technical/statistics/sflow-stats/ether-type
2) Re: Ur. Pt. 2.: Let's do not get into "the newer is the better" mentality. When dealing with the same task, "the simpler is the better". The beauty of great engineering is to get the job done with minimum resources. I often like to paraphrase an originally politically incorrect expression, KISS for this kind of situation: "Keep It Stupidly Simple". To me, bragging about doing the same job with super fancy and over capable tools does not impress me, but exactly on the contrary.
3) Re: Ur. Pt. 3.: Again, if we can get the job done with 32-bit system, why go to 128-bit? I must profess that the former is about my mental limitation, while the later throws me into the dungeon. Most of people that I came across are not shy about admitting this. The fact of the matter is that IPv6 unnecessarily created a long numbering system that get most people lost, and then begins to make use the "rich bits" for purposes other than addressing which increases the cyber security vulnerability. This is an angle that no one has talked about yet.
Regards,
Abe (2018-08-31 13:07)
Hi, Charles 9:
1) Re: Ur. Pt. 3 "ZFS": I just had a chance to look at the Wikipedia description of this Sun Microsystems 128-bit filesystem. It reminds me of an even much bigger address system proposed by RFC1385 that is listed as Reference [11] of the EzIP Draft. If you look at its Figure 1 on page 4 and then the description of "EIP Extension Length: 8 bits" on page 4/5, you will find that it was proposing an address system that could be up to 256 bytes long, which would be 16 times of the IPv6's 128 bit system! As commented in the EzIP Draft, the RFC1385 approach required modifications to CRs (Core Routers) which appeared to be non-trivial. It sounds to me that the IPv6 implementation may be even more complex, because I never heard about upgrading an IPv4 router to be IPv6 capable via S/W or F/W download process.
Abe (2018-09-03 10:02)
Well Vint, you were one of the originals, you made up TCP/IP because it just worked.
But it's crap, and now it's cemented into the base of the internet infrastructure, it's there to stay.
It just works, but it does a bad job and allows a multitude of sins which are continuously patched over.
Sometimes a rethink and rebuild is the best answer, but rarely is it done.
"
mostly run by tech giants like Google – for who Cerf works – and who go to some lengths to make sure that they can be accessed by IPv4.
"
look, a great big IPV6 bandaid
Dear Colleagues:
You may like to have a look at the feasibility demonstration report below.
https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf
It should provide some material for furthering the discussion.
Abe (2020-08-29 12:22 EDT)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
