Internet engineers tear into United Nations' plan to move us all to IPv6 A newly released draft of the United Nations' masterplan to transition the internet to IPv6 has met a furious and despairing response from internet engineers. "Utterly, utterly, broken. It has no redeeming or worthwhile qualities at all," commented one engineer to an dedicated IPv6 working group at Europe's regional internet …
the IPv4-IPv6 1:1 mapping plan that has internet engineers up in arms.
Forgive me for not seeing a big problem with this, or for understanding why it would reduce address space by 25%, but can someone explain what the underlying issue is?
In my naive mind I would think that a 32-bit address for IPv4 need only take 1/2^96 of the 128 bit IPv6 addresses to work, or around 1.3e-29 of addresses. What have I missed?
Anything that poses a problem for the IoT is to be encouraged.
The ITU, of course, has been in a permanent state of being miffed ever since the world preferred Internet technologies to its own on account of the former being here and working and the latter being in committees.
Don't confuse politicians with common sense (and many of the "Internet Engineers" are politicians).
The people who devised IPv6 were NOT engineers - any sensible engineer knows the KISS principle and would not produce such an overblown structure as IPv6. IPv6 was designed by theorists. An IPv6 designed by engineers would have been an addressing extension of IPv4 and would almost certainly have had a direct mapping from the public IPv4 addresses to a (tiny) subset of the IPv6 addresses. If that had been the case then IPv6 would have been in widespread use years ago.
would almost certainly have had a direct mapping from the public IPv4 addresses to a (tiny) subset of the IPv6 addresses. If that had been the case then IPv6 would have been in widespread use years ago.
This is also in reply to the first poster above...
One of the goals of IPv6 was to make things easier for the routing system. Basically, the address space is carved out hierarchically with a top-level address registrar feeding down through RIRs (regional IP? registries) and so on down to local resellers and eventually users. It is assumed that the mainly geographical hierarchy will match up more or less with the actual routing infrastructure at at least the higher levels. Ultimately, the aim is to shrink the routing tables down.
IPv4 is decidedly not based on a geographical hierarchy. If you try and graft IPv4 addresses into the IPv6 system, you end up with an explosion of routing table entries that need to be taken care of. So no matter how you try to devise an IPv4 to IPv6 transition mechanism, if it involves a 1:1 mapping of old to new addresses in any way, you effectively break routing (or at least negate IPv6's native advantage there), and thus pretty much break IPv6 for everyone.
At least that's what struck me when reading the article.
The other two posters here covered alot of the broad strokes with the routing issues. 6 to 4 translation/mapping can happen at an endpoint router like the one at your home or a single site office at low/impact cost, when you are routing to one of your primary links. That is because the v6 address block is being routed to your internet connection from the outside. Since the IPv4 address space isn't assigned in the same structural hierarchy it appears the UN/ITU proposal wouldn't be able to to efficiently map to one block, it would require blocks in each division of the hierarchy for the legacy address space. That's where your big chunk goes.
The IPv6 space is STUPID BIG. Losing 25% wouldn't be a non-starter in and of itself, but the rest of the proposal appears to have other huge problems beyond the address space useage.
Unsurprisingly, the idea of reverse mapping the address space is not new. I set up one up in two days when I started breaking in my first IPv6 hand-off. The trick is that efficiently mapping address spaces in a trivial way leads to inefficient routing. The working group I was in was playing around with creating virtual IPv4 tunnels that overlay the IPv6 network. The key thing is you'd want your IPv6 block hanging as close to the tier 1 space as you can, as you will be bouncing traffic off of it in a somewhat inelegant fashion. It does work without breaking much, at least when the entire internet isn't doing it at once. You can spin up an Amazon tiny if you want to try it for yourself. It wasn't as horrible as it sounds as the IPv6 part of the routers were already dual stack anyway, and IPv4 stuff doesn't freak out about address translation that often these days. The project never went anywhere because it didn't get buy in from the people who really matter, the people who slinging networking silicon. If Broadcom, Qualcom, or Cisco don't back it, it's not happening.
That won't fix the IPv6 roll out though. IPv6 was and remains a lesson in failure. Too much forcing academic theory, not enough requirements analysis, and some bad assumptions on the wisdom of encouraging 25 year support windows for your core internet routing hardware.
I hope that IPv7 or IPv8 routers are all software running on upgradable hardware with the expectation that anything that's running older than last years LTS with the latest patches will be voted off the island. We have two perfectly useful broken Internets for anyone that doesn't want to keep up.
> I hope that IPv7 or IPv8 routers
At the risk of having a Bill Gates moment, what on earth do you think we'll be doing in the future to need such an immense address space.
Perspective time. The surface area of earth is roughly 5.1 x 10^8 km2
IPv6 gives 2^128 addresses (ignoring reserved ranges for the minute). That's a big number*.
That results in 667,220,330,000,000,000,000,000 ipv6 addresses per square metre on this planet. How much IoT tat do you need?
*Citation needed
(Edit: my earlier comment was incorrect, here is the correct quote) - So we could assign an IPV6 address to EVERY ATOM ON THE SURFACE OF THE EARTH, and still have enough addresses left to do another 100+ earths. It isn’t remotely likely that we’ll run out of IPV6 addresses at any time in the future.
"The people who devised IPv6 were NOT engineers"
Wrong. And they were very aware of KISS, which is for example why the IPv6 header has a simpler structure than the IPv4 header, and why the original transition model was pure dual stack.
Things got complicated largely because of reluctance in the industry to adopt this simple transition plan.
" direct mapping from the public IPv4 addresses to a (tiny) subset of the IPv6 addresses."
Naturally this model was considered (in 1994 or thereabouts). Also, to keep the ITU happy, a mapping to OSI addresses was considered (also in 1994). The trouble is, neither of those models actually works. It's truly absurd that in 2018, the ITU comes up with a naive idea that was ditched more than 20 years ago.
The good news is that nobody who makes their living out of IP service provision will waste any time on this nonsense. IPv6 works well already; just use it.
Wrong. And they were very aware of KISS,
Yeah. Sure. Tell me how IPv6 address and parameter configuration follows the KISS principle.
Listening to an IPv6 evangelicals defending the necessity to have two half-baked mechanisms for this (DHCPv6 and v6 autoconfig) is almost as entertaining as listening to true evangelicals proclaiming that the Earth was created 6k years ago and dinosaurs walked the Earth together with Adam and Eve.
While v6 may have started as KISS it has been bogged down day one by technoreligious madness where anything and everything should also throw spanner in the v4 works. One of the best examples here is that a v4 DHCP server is not allowed to supply v6 information which is a restriction which has absolutely nothing to do with engineering - it is purely political.
Why should a DHCPv4 server carry IPv6 information?
Adam. Eve. Snake. Dinosaurs next to them. v6 Autoconfig. Goodness. Half of the parameters missing. Still goodness because scriptures say so. Asking DHCPv6. Half of the parameters conflict. Still goodness because the holy scriptures say so in RFC6214.
The core issue here is that autoconfig has the implicit assumption that routers should supply configuration information and vice versa. That assumption is "your ship of fail has arrived" for proper network management. Big time. This was something which became absolutely clear when DHCP become the de-facto standard for v4 management combined with things like DHCP to DNS integration, option 82, etc. 15 years ago to be more exact. That was the point when autoconfig should have been buried 6 feet under with a stake through it so it does not get up.
Autoconfig is a big fail in a modern campus architecture today where you may deploy vlan choice, broadcast isolation and/or multicast limitations based on the actual DHCP events and specifically option 82 in its "authenticated client ID" incarnation.
Shipping full v6 info in DHCPv4 allows you to reuse existing layer 2 legacy infrastructure including things like option 82 without replacing all of it because the holy prophet* of v6 said so. It just works and if it was done, we would have had 40%+ of hosts on v6 by now instead of having technoreligious arguments with evangelicals which continue to explain that the holy sepulture, err simultaneous coexistence of autoconfig, DHCPv4 and DHCPv6 is somehow a good idea.
The holy prophet is usually depicted as a Fred Bake-like charging rhinoceros accompanied by a large number of Homenet attendees in acolytes garb.
Autoconfig is a big fail
Should not post before the 4th espresso.
I meant Autoconfig + RA. Both. They need to be dead and buried and fully replaced by DHCP. They made sense in the 90-es when the protocol was designed. In 2018 they are a solution looking for a problem. Both of them and especially RA.
The problem is that IP6 was a bad design. It was later fudged (not relating MAC to an IP6). It was designed with no thought of backward compatibility.
Yes, ITU is probably wrong. So is IP6, we need an IP8, with security & privacy designed in.
My router & ISP both have IP6. I can't change over.
1: Privacy of LAN. 2: Security of LAN. 3: Many things I have don't do IP6. 4:Many sites don't do IP6, all IP6 sites I use do have IP4.
The Router essentially has no Firewall or NAT if using IP6.
Yes, ITU is probably wrong. So is IP6, we need an IP8, with security & privacy designed in.
This brings two things to mind: the ilusion of sunk cost; and the illusion that the next version will solve all the problems of the current version.
There's no doubt that IPv6 isn't perfect, but, as the implementations show it does at least work and we have worked how to have both protocols working together.
Regarding going back to the drawing board I suggest that not only would this lead to the same kind of delay that we've seen with IPv6, but also that it wouldn't get traction. IPv6 installations are already big enough to dominate the near future, ie. industry will enforce IPv6 as a de facto standard. Much better to be thinking of ways of updating the protocols in the future with less disruption.
"The Router essentially has no Firewall or NAT if using IP6."
Firewalling rules are the same at ipv6 or ipv4. Just make sure you apply them to both, most decent consumer routers will do that for you.
NAT is not a firewall, not even a poor substitute for one.
IPv4 NAT breaks a shitload of things. It's a kludge and a rotten one at best which requires a lot of workaround on IPv4 networks (There is the possibility of NAT in IPv6, but it's 1:1 mapping, not the 1:many of Ipv4 NAT and you'd generally be bonkers to use it unless you absolutely had to)
Anyone raising these arguments as a reason not to go to Ipv6 isn't competent to raise the objection.
Adding "security" and "privacy" was one of the things that badly slowed down initial iterations of IPv6 getting off the ground. If you really want to go and reinvent that wheel then be prepared to spend a decade or two arguing about the minutia, because you're tacking so much onto TCP/IP that you really want to start over and redesign the entire packet structure from scratch - and good luck with getting THAT adopted within the next 30 years.
IPv6 isn't perfect, but it's a hell of a lot better than what we have now - and what we have now is creaking badly. Yes, you could redesign BGP to have more than 65k routes whilst keeping IPv4, but why bother? It'd take 30 years to drive adoption of it when BGPv6 already exists.
"NAT is not a firewall, not even a poor substitute for one."
True -- NAT does something entirely different. However, it is still useful, and should I even move my LAN to IPv6, I'll still be using a NAT to present a single point of presence to the internet.
and why the original transition model was pure dual stack.
Things got complicated largely because of reluctance in the industry to adopt this simple transition plan.
And the fact that the original IPv6 model didn't work in the real world.
Security? Nah - you don't need that.
IP address auto-allocation? All handled. Except when it isn't.
In short, all the modern OSes have been IPv6-enabled for years. But we are still not seeing mass takeup because it still doesn't (despite all the tweaks and kludges) work well in the real world.
"The people who devised IPv6 were NOT engineers - any sensible engineer knows the KISS principle"
I have to agree. Anyone familiar with v4 looking at v6 initially goes, "wtf is this?"
That's not normal with properly engineered stuff building on previous things.
And why is UN involved of all entities?
"And why is UN involved of all entities?"
The ITU is basically All The Legacy Telcos, who are still miffed that the ever-so-elegant OSI protocol stack [/sarcasm] lost out to a bunch of neckbeards who actually did *engineering*, and have been trying to claw back some validity ever since. "rough consensus & running code" >>>> kilopage specs with zero interoperability.
[ I was *at* AT&T late 80s, they had an OSI package for their nascent 3B midrange line, and a third-party TCP stack for 'transitional purposes'. Shocked the feces out of them when World+Dog ignored the former, even/especially inhouse... ]
"The people who devised IPv6 were NOT engineers - any sensible engineer knows the KISS principle and would not produce such an overblown structure as IPv6."
Could not agree more. A simple extension of the address space to create a 128-bit IPv4 would have by now been in use worldwide for at least a decade. See Dan Bernstein's quite old article "The IPv6 Mess" https://cr.yp.to/djbdns/ipv6mess.html. Nothing much has changed.
I don't suppose you have a suggestion for what that simple plan would be? I'm guessing you don't, because it's not possible to get any simpler than the plan we already have.
djb also falls into this trap with that article -- he points out a bunch of problems, and then just sort of goes "these should be solved", without mentioning or apparently even realizing that they can't be solved in any better way than the way that v6 already solves them (with 6to4, Teredo, NAT64, DNS64/464XLAT and API translation).
In my naive mind I would think that a 32-bit address for IPv4 need only take 1/2^96 of the 128 bit IPv6 addresses to work, or around 1.3e-29 of addresses. What have I missed?
Its to do with how they map them, and how the routing to those mappings absorb or make unusable other addresses.
The point of IPv6 is not simply more IP addresses, it is designed to make routing and routing decisions easier and more logical. Current IPv4 routing requires a global routing table of ~800k BGP routes, which is expected to grow to ~1.4 million routes by 2022, as the fragmentation of ranges requires even more routes.
IPv6 on the other hand is intended to be given much larger allocations initially, which drastically reduce the number of routes required. IPv6 is expected to have no more than 130k routes by 2022 (not because it isn't used!).
That follows on to FIB table size. IPv4 FIB tables are expected to grow above exponentially, reaching 1M entries by the middle of next year, which is the magic number of entries that many routers will go "pfffft" at, and start dropping traffic or using excess CPU.
IPv6 isn't a magic bullet, but it is designed to fix these routing issues that affect the core internet, and this proposal aims to piss all over those designs in order to simplify migration - in effect making IPv6 just IPv4 with more addresses, but still with all the complexity that IPv6 needed to solve these routing issues (but not solving them).
>IPv6 isn't a magic bullet, but it is designed to fix these routing issues that affect the core internet,...
I was under the impression that IP6 traffic was supposed to carry its routing information embedded in the packet headers. Is this correct? (I was never much of a fan of v6 because it assumed varying length packet headers which according to my upbringing is not a good idea, it makes routing messy.)
I was under the impression that IP6 traffic was supposed to carry its routing information embedded in the packet headers. Is this correct?
The Source and Destination IP addresses are routing information. Next hop router etc is something the machine doing the routing needs to know and is not in the packet.
IPv6 DHCP will contain default gateway info though which your machine needs to know about to send traffic to a different network.
1.4 million routes doesn't really sound like much to me for 2022. Other than the big service providers who really needs to carry the full bgp table anyway? Most folks that use BGP will probably only need a tiny fraction of it, or for the rest of us just uplink to a good service provider(in my case Internap) and let them do the routing.
I have a document here for a high end core switch from May 2004 where a vendor was using a IXIA traffic test tool against a couple of different products, once of which was capable of 1.2 million routes, though on a per port basis it was 230k. But still that was 14 years ago, and it was a switch, not even a "router"(which typically have a lot more memory).
Most companies have had to upgrade their hardware anyway just for increases in throughput.
Today I see routers at least claiming over 2M IPv4 routes and 2M IPv6 routes in hardware(vs 230k on that switch from 14 years ago) on modern equipment just on a quick search I'm sure there are others that can scale higher.
1.4 million routes doesn't really sound like much to me for 2022.
It's the exponential part of it that is the issue, 1.4 million in 2022, 2 million the next year. The more we squeeze IPv4, the more fragmented IPv4 space becomes, and more routes are required.
As an example of an affected router, 3 years ago the thick end of $20k bought you a Cisco 7600 series, which has a hard limit of 1 million IPv4 routes/512k IPv6 routes (IPv6 routes takes twice as much space, your choice on how you split it), and 512k IPv4 FIBs and 256k IPv6 FIBs - ruh-roh.
That router is EOL/EOS, but still supported by Cisco until 2022 (assuming you keep paying).
You may have missed the bit about developing countries...
They have slower connections, which don't need these new expensive routers, so they buy older routers that providers in developed countries have discarded, which is part of the problem as many are using equipment which doesn't support ipv6 or incurs significant performance penalties when doing so (eg ipv4 in hardware, ipv6 in software on a slow cpu).
"You may have missed the bit about developing countries..."
I didn't, and experience in actually being in places like outer bumfuckistan shows that the telcos have just as new shiny shiny kit as anyone else.
The developing countries are actually the perfect fit for large scale deployment of IPv6, but there's more money to be made selling them huge CGNAT systems and management defer to furren conslutants with shiny websites instead of actual engineers.
1.4 million routes doesn't really sound like much to me for 2022. Other than the big service providers who really needs to carry the full bgp table anyway? Most folks that use BGP will probably only need a tiny fraction of it, or for the rest of us just uplink to a good service provider(in my case Internap) and let them do the routing.
If you are single-homed (only one connection to the ISP), you are correct, you do not need the full BGP routing table - a default route will do.
However, many organisations wish to have resiliency/redundancy. At one level, you can have two connections into your ISP and do some mucking about to avoid needing the full BGP routing table by setting route preferences etc (bearing in mind that if you want load-sharing rather than just failover, it gets 'tricky') - and you need cooperation from the ISP. If, however you want independent routes to separate ISPs you need to use the full BGP routing tables approach with some very capable routers on your autonomous system (AS) boundary to the multiple ISPs you are connecting to. It's very easy to get wrong. Once your organisation gets big enough to want multiple connections from multiple autonomous systems spread across the globe, you might want to start dealing with Route Reflectors and other techniques used to make managing multiple entry/exit points manageable rather than polynomially hard.
IP routing, at scale, is an amazing piece of co-operative software and protocol engineering which requires expertise to understand. I take my hat off to the folks who do, and listen seriously to the ones who can give reasons behind the design decisions in IPv6. It's an example of where listening to your technical experts is worthwhile, because the alternative is chaos.
@Nate Amsden
Quite a few Enterprises have valid reasons as to why they might want full routing table.
And I say that as somebody who has exclusively worked in the Service Provider sphere, never worked for Enterprise.
Although agreed it is not for everybody though. Many SPs themselves can do well with 2 or 3 x default route-only from different Tier 1 or maybe some sort of partial routing table mix from the likes of Lonap and Linx (assuming UK-centric ISPs).
IPv6 isn't a magic bullet, but it is designed to fix these routing issues
At the cost of making implementation for the end user much, much more complex. Even my small home network is hard to configure for IPv6 (router, firwall, VM host - they can all see each other but can't route IPv6 packets successfully..)
IPv6 was designed by theorists who designed 'the perfect addressing model'. Once that was presented to people who actually do networking, the kludges needed to make it actually work started appearing. Like DHCPv6..
Even my small home network is hard to configure for IPv6
Perhaps that's a router issue? My v6 network autoconfigures fine - I just run radvd and it all happens. The firewall config wasn't too hard - lots of good info on the net. It's true I have some v4-only hosts (TV, etc mostly) so run dual-stack. But all my laptops, phones, servers etc all use v6 when they can.
I think the home router manufacturers have a lot to answer for here. Mine is a home-brew linux-based router, and once you get the design right it all just runs. So why can't the mfrs get with the program?
>You're on TalkTalk aren't you?
Nope CenturyLink. Wrong continent. Probably the equivalent in that they are one of the slower options with crap customer service but also only choice for getting decent standalone internet for $40 a month (no bundling garbage).
>you can do it with a 6in4 tunnel.
Completely indifferent to ipv6 so if it doesn't autoconfig then I can't be bothered. Network engineers care a lot more about it than end users at this point.
"Even my small home network is hard to configure for IPv6 (router, firwall, VM host - they can all see each other but can't route IPv6 packets successfully..)"
You should give the firwall back to your cat, and put in a firewall :)
(Watch out for those hairballs, they're non-routable, and induce hacking).....
There is already a mapping from ipv4 to ipv6 - the 6to4 address space:
https://en.wikipedia.org/wiki/6to4
Every routable ipv4 address has a /64 of ipv6 space in this way.
The way to encourage ipv6 adoption is to make it a desirable feature that users demand from their ISPs... Microsoft do this to a small degree by stating that the xbox one works better with ipv6, but more is needed.
If big services like google and facebook start promoting ipv6, and making new desirable features available on ipv6 first then people will start asking their isps for ipv6, and are more likely to favour providers that are offering it. ISPs don't bother at the moment because its a cost, if they start to lose customers due to lack of ipv6 then they will take action.
"The way to encourage ipv6 adoption is to make it a desirable feature that users demand from their ISPs"
What you're recommending here is a bit like extortion. The plain fact is that for 99% of end end users, IPv4 vs IPv6 doesn't matter. This is an issue that matters to ISPs and other industrial routers.
I disagree with the notion that it is OK to artificially degrade the end user experience just so that users will get mad at their ISPs.
I think ISPs will rapidly adopt IPv6 the minute they can't add any more customers due to address exhaustion. DSL modems and mobile devices are probably the best use case for IPv6.
Their problem is that it spoils their billing model. If they are giving every home a /56 they cant charge you for extra IPs anymore.
@Paul Crawford
IPv6 is set to use just a fraction of its pool of addresses until some time in the very distant future.
Global routable addresses issued by the IANA start with prefix 2000:
https://en.wikipedia.org/wiki/IPv6_address#General_allocation
Only one eighth of the total address space is currently allocated for use on the Internet, 2000::/3, in order to provide efficient route aggregation, thereby reducing the size of the Internet routing tables; the rest of the IPv6 address space is reserved for future use or for special purposes. The address space is assigned to the RIRs in large blocks of /23 up to /12.
other addresses are also reserved for IPv4 mapping and translating
https://en.wikipedia.org/wiki/IPv6_address#Special_allocation
This does depend of course on the mechanism they use for mapping but 25% is a stupidly wild number, maybe they meant 25% of the 2000::/3 prefix?
So yes, address space reduced by 25% is complete and utter bollux as they could use a new prefix like 4226::/3 if they wanted and retained the already huge space in 2000::/3 for pure IPv6 use and still avoid address wastage.
there is a lot of misunderstanding, slight of hand and deception going on around IPv6 and all its doing is making people hold onto IPv4 longer. Its time we ditched IPv6 and made a start on IPv8 (odd numbers are experimental apparently) taking advantage of the positives we have learnt in IPv4 and removing the negatives from IPv6.
It's worthwhile noting that IPv6 looks to be designed as a marriage of MAC addressing & IP addressing in 1 protocol. In its original incarnation, it would not have been too hard to get cheap switches to do routing by reading the first 64 bits of the destination address for routing and the last 64 bits for switching, paving the way for the Ethernet frame and IP packet to be collapsed into 1 framing process thereby saving some bits on the wire and making things a bit quicker.
The way we use IPv4 has evolved hugely since 1994 and IPv6 has not kept up which is another reason why IPv6 adoption is so low, its doesn't have any mature tools to go with out and it's like going back to 1994 again in terms of features and how we can use them.
It's the UN. They come out of their cocktail hours in NYC on a regular basis, look around, pontificate about their own importance and then go back inside.
Let's ask them a real question: Has the UN ever done anything of significance? What qualifications do they have for tech? Politics is one thing but tech is something they should just stay out of as they are not tech types and in reality, they have their own self interest in mind.
Side bar: Even their politics are screwed up with corruption amongst the delegates and a total lack of comprehension about problems and issues in the real world.
Downvote away, but UN has pretty much been crippled by politics and made meaningless for a long time.
UN has pretty much been crippled by politics and made meaningless for a long time.
Yes it has, but the value of the UN and active participation is seriously hampered by the few countries that have 'veto' rights. This essentially means that as a non-veto country the only way you can pass any significant changes is if you make sure any proposal you want to pass is in the interest of the countries that do have veto rights.
The only way to fix this is to remove veto rights completely.
I sympathize with your frustration with the veto, but I'm afraid it is basically required. The existence of veto rights for some nations reflects the reality that they can basically do what they want, ignoring the U.N. If the U.N., now minus its veto capacity, were to pass something that went against the wishes of the U.S., Russia, China, etc., U.S. Russia China would cheerfully ignore it. I hate that this is the case, but a mechanism that can decide things and kind of get them started as long as U.S., U.K., France, Russia, and China have no problem with it is better than a system that can't do anything at all. As I see it, your choices are about 0% functional and about 0.7% functional. If someone can create a 1% functional or better, I'm all ears.
thing is, Russia having veto power is a relic of the past. Having GDP far smaller than Italy, let alone other EU economies.
It's nothing to do with the size of the economy. But you're right that there is something out of date about which countries have veto power.
If we adopted the true principles underlying the original list, then India, Pakistan and North Korea would have a veto.
Hint: would you rather Russia vetoed a proposal or nuked the countries making the most fuss about wanting it?
Not quite there yet IINM. They can START World War III but may lack the arsenal to FINISH it. Russia, the US, and so on CAN.
Yes, but the UK couldn't finish it either, nor could France. Doesn't really matter. All you have to do is lob enough nukes that Russia or the US or China lob enough back to finish it. Bonus points if you can lob nukes at the US and make it look like they came from China. Chances are the fallout and nuclear winter will finish most of the rest of us too. But even if the big boys don't retaliate, they don't really want one or two of their biggest cities destroyed. So the minor players still ought to get a veto.
BTW, I forgot to add Israel. But they don't admit to having nukes anyway, so we shouldn't let them have a veto.
> A country that can singlehandedly start AND END World War III deserves attention whether you like it or not.
I somehow can't see a situation in which just few ICBMs are in the air that doesn't end in an all-out WW III. So either everybody that has nukes gets the veto, or the people that don't use veto exclusively to stop investigations into their own war crimes get the veto.
Also, while the Oligarchs exploit Russians, they do it to fund their extravagant lifestyles in the West, not in Russia. Doing that in a nuclear wasteland is rather hard.
If Pakistan and/or India start getting nuclear on each other's asses, I don't think that would trigger World War III. It would be ugly, yes, but I could see there being enough restraint among the remaining powers to, pardon the pun, "go ballistic". It's not like either country has that big an arsenal to begin with, anyway. As for North Korea, that's also questionable. Given the limited size of their arsenal, if they were to use it in anger, they'd probably use it The Sum of All Fears-style in a sneak attack for maximum impact.
"UN has pretty much been crippled by politics and made meaningless for a long time."
I prefer that country reps bang gavels with their shoes and rave on endlessly in a debating chamber than get into shooting wars with each other over a perceived insult over aunt esmerelda's waist size.
At that (as with the EU), the UN has been a qualified success - yes there are still conflicts but the number of them is lower and they tend to be resolved quicker than in centuries gone by.
Well the old guard have had 20 years to get v6 to work and have failed dismally. Maybe it is time to let someone else try.
Doesn't really matter if you knock 50 years off of the life of v6 if it would have taken 50 years to get v6 adopted or if v6 will be obsolete well before it runs out of space.
"Doesn't really matter if you knock 50 years off of the life of v6"
I'm inclined to agree especially if this is accurate
"The model shortens the expected usable life time of IPv6 by at least 25 per cent, or 42-plus years at the current internet growth."
It would imply that 25% of the projected life of IPv6 is 42 years, meaning that even under this flawed plan it would have a life of ~126 years?
I would be shocked if it was still relevant in 126 years, or would be if it weren't for the fact that I'll be long dead, I'm more than happy to let my great grandchildren deal with running out of IPv6 addresses.
Unlike climate change this is definitely a problem where a plan that only works for another 100 years will do just fine.
"It would imply that 25% of the projected life of IPv6 is 42 years, meaning that even under this flawed plan it would have a life of ~126 years?"
I have no idea where those numbers come from. IPv6 allows for about 35 trillion networks with a /48 prefix under the space so far allocated to the registries, which is only 1/8 of the theoretical total space. The address space lifetime isn't even worth calculating. IPv6 may have a lifetime, but without idiocies like this ITU proposal, it isn't limited by address exhaustion.
> the old guard have had 20 years to get v6 to work and have failed
Please explain. The IPv6 network is already a great deal larger than IPv4 was 20 years ago, and is growing daily. Coexistence for many years was always part of the plan. I don't see failure there. You might as well say that electric cars have failed.
"Please explain. The IPv6 network is already a great deal larger than IPv4 was 20 years ago, and is growing daily"
If that's your measure of success then great. But it wouldn't be mine. v6 has roughly double the number of hosts that v4 had 20 years ago but it's still 0.2% of the Internet, and most of those will be dual stack.
So v6 can continue to grow at that rate and it will take 10,000 years to displace v4, assuming v4 doesn't grow too.
I call that a failure.
So v6 can continue to grow at that rate
This is a dumb assumption. I think the only safe thing you can say about IPv6 adoption is that it will be erratic. Some carriers and countries will adopt wholesale while others avoid it. At some point there is likely to be an (or many) inflection point where adoption picks up significantly. This could be for technological (end of the road for NAT), regulatory, or financial (it becomes cheaper to run only IPv6 kit), but the important thing is minimal disruption to users.
Please check your figures.
IPv6 has 20% not 0,2%.
http://6lab.cisco.com/stats/index.php?option=users
https://www.akamai.com/de/de/about/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp
https://www.facebook.com/ipv6/?tab=ipv6_country
The IPv6 network is already a great deal larger than IPv4 was 20 years ago
Given that 20 years ago the nascent internet was pretty tiny (I remember it well - Usenet and FTP were king) that's not saying much..
I very much doubt that IPv6 will follow the growth curve of IPv4 unless something changes rapidly - either the ISPs will have to start selling IPv6-only connections or the big calble companies (Virgin/Sky in this country, Comcast et. al. over the pond) convert over to it (doubtful - that involves big investments that will make for smaller shareholder dividends and executive bonuses) it ain't going anywhere fast.
Ok, I'll take the bait...
How is a system running 20% of the world's active internet connections not working?
It's not a case of getting ipv6 to work, it's a case of getting ISPs to implement it. The assumption that this is not happening because of some inherent problem with ipv6 is disproved by the many successful cases.
The reason for slow adoption is simple enough to explain: pure corporate inertia. They need a "business case", and ipv6's main selling point is extra address space, which isn't much of a carrot as long as enough ipv4 addresses remain available. It's taken the stick of address exhaustion to get Western ISPs moving.
The lower adoption in developing nations probably has something to do with the fact that their regional registries still have a fair bit of their ipv4 address allocation left unused. It's not rocket science, and it doesn't require UN interference to solve.
" ipv6's main selling point is extra address space, which isn't much of a carrot as long as enough ipv4 addresses remain available."
It's even less of a carrot if you can milk the artificial scarcity of address space caused by not moving off IPv4 and sell addresses for a premium.
There's the added factor of explaining to your shareholders that all those hideously expensive IPv4 /8s are now essentially valueless. Accountants don't like that.
Scrap the UN. Bunch of snout in the trough wastrels, I can't think of anything useful the UN has achieved that wouldn't have been delivered through other means. And all too often the UN takes credit for things organised by, delivered by, and paid for by particular countries. Crap at peacekeeping, crap at famine relief. Now being crap at technology.
The odd numbered versions for IP standards are the experimental or working drafts. So IPv4 was preceeded by someone playing around in a standard called IPv3, IPv6 had IPv5 before it and IPv7 was being kicked about years ago as far as I know. I think this might be true for everything the standards body that deals with IPvX churns out. The experimental odd versions are never designed for real world release but as test platforms to evaluate ideas.
The odd numbered versions for IP standards are the experimental or working drafts. So IPv4 was preceeded by someone playing around in a standard called IPv3, IPv6 had IPv5 before it and IPv7 was being kicked about years ago as far as I know.
Nope. IPv4 was the first release, the name is a retronym coming from the 'type of packet' field to allow multi-protocol links atop DLLs that don't provide an equivalent capability natively (ISTR HDLC is one but don't quote me on that). The first IP got assigned a code of 4, by the time its successor arrived 5 had been allocated so it got 6. The 'version' numbers simply reflect those codings.
The odd numbered versions for IP standards are the experimental or working drafts.
So IPv4 was preceeded by someone playing around in a standard called IPv3, IPv6 had IPv5 before it and IPv7 was being kicked about years ago as far as I know. I think this might be true for everything the standards body that deals with IPvX churns out.
The experimental odd versions are never designed for real world release but as test platforms to evaluate ideas.
See a lot of this on a much smaller scale with IT projects where the disjoint between user requirements and reality is piped through project management, system archtects and business analysts and is spewed out on unsuspecting IT dogsbodies, that make stuff actually work in the real world, who just look, shake their heads and either laugh or cry at yet another unrealistic solution to a problem that didn't exist.
"address allocation optimization requirements for IPv4 bear no relation to sensible and relevant optimization strategies for IPv6."
https://tools.ietf.org/html/rfc6177#section-2
Hence, this document still recommends giving home sites significantly more than a single /64 , but does not recommend that every home site be given a /48 either.
/64 1 IPv6 subnet 18,446,744,073,709,551,616 IPv6 addresses
Now, I'm not sure how much IoT shit I'm supposed to put in my house, but 4 billion ipv4 internets worth seems like a lot? Maybe they could have increased the lifespan of ipv6 by only giving homes 1 ipv4 internets worth.
If the minimum subnet size is 2^64 , and the complaint is "the routers will fill up if we have millions of routes". how exactly are switches going to cope if you put millions quintillions of hosts on one subnet? It's all just wasted address space at the cost of much longer addresses.
Of course, ipv6 may give you quintillions of routable ip addresses but only has one loopback address.
The address space is not wasted, it is just vast. At my previous place, I had a fixed IP, a /64 allocated out of the /32 (I think) that my provider got assigned, out of the, say, /16 assigned to Canada. This way, anyone in the world just needs to know about the /16 to route packets for me to "roughly Canada", the (say) Toronto Internet Exchange just needs to know that 16 bits further down it went to my old provider, etcetera. It limits route tables to really manageable entries and you can still have tons and tons of top level ISPs.
The /64 in my house gets subdivided as well: privacy IPv6 addresses, MAC-based IPv6 addresses, and then a couple of DHCP ranges that for example routed between my regular network and a bunch of docker swam networks on Raspberry PIs (don't ask ;-)). I wasn't using my whole address space, but I certainly had another subdivision going on.
Having 340282366920938463463374607431768211456 addresses makes large scale routing really efficient by purposely going sparse. It's a bit of a twist from IPv4, but it makes a ton of sense. 128 bits is so mindbogglingly big (picture all of space and a sign "you are here") that it enables these sort of strategies and still be future proof, even though the allocation strategies seem wasteful at first sight.
(glad you asked. I'm on a rural PtP LTE connection now. Behind five-hundred layers of "Carrier Grade NAT". Which is how we all will end up on IPv4, with no option to, say, run a webserver on your home router).
> The address space is not wasted, it is just vast. At my previous place, I had a fixed IP, a /64 allocated out of the /32 (I think) that my provider got assigned, out of the, say, /16 assigned to Canada. This way, anyone in the world just needs to know about the /16 to route packets for me to "roughly Canada", the (say) Toronto Internet Exchange just needs to know that 16 bits further down it went to my old provider, etcetera. It limits route tables to really manageable entries and you can still have tons and tons of top level ISPs.
How does this work if you are a multinational organisation? Does that mean you can't use your /64 to cover all your offices in all the countries they are in? Do you need a separate (purchased?) allocation for each different country you operate in? or perhaps even further down, each different city you are in if the blocks are geographically assigned?
> You just subdivide your /64 by region.
Sorry, but I don't understand.
You said the /64 was (ultimately) allocated to Canada.
So how can I subdivide that into an address (subnet, say a /112) in South Africa, or Singapore, or Mongolia if the inbuilt routing says that the /64 is in Canada?
"If the minimum subnet size is 2^64 , and the complaint is "the routers will fill up if we have millions of routes". how exactly are switches going to cope if you put millions quintillions of hosts on one subnet?"
I'm afraid this merely betrays your lack of understanding.
The large address space allocations reduce the number of routes required by allowing things to be properly routed by subnet. This was how IPv4 worked originally, but it ran out of address space for that scheme decades ago.
Here's an IPV4 example for simplicity. Say you have the following ip addresses:
134.240.73.12
134.240.73.89
134.240.56.87
134.116.76.23
Under the present overcrowded IPv4 scheme, a router might well need separate routing table entries to reach all those addresses.
Under the original scheme, it would have required a single entry to reach the gateway for the 134.*.*.* subnet.
The gateway for the 134.*.*.* subnet would then have required 2 entries for the gateways for 134.240.*.* and 134.116.*.*
The gateway for the 134.240.*.* subnet would then have required 2 entries for the gateways for 134.240.73.* and 134.116.56.*
The huge address space of IPv6 allows a return to a similar addressing scheme.
Thank you for bringing up this topic. The address of a terminal is almost an obscure topic when it works. But, it is actually the fundamental issue for the Internet. In an ideal world of communications, the principle that you described is true. For example, the old fashioned telephony system, PSTN (Public Switched Telephone Network) does exactly this way. Although not always explicit, a phone number in most countries can be parsed into, Country, Area, City and subscriber code/ number parts. Each is associated with a progressively narrower geographical area, facilitating the efficient switching (equivalent to routing in the Internet) function. However, this is only possible because the phone numbers are traditionally assigned according to the physical locations of the subscribers as they registered with the Telco. To put it simply, this is why emergency locating capabilities such as 911-Service in US can locate a caller even before the call is answered.
In the Internet, each ISP, being allocated a block of IPv4 addresses, assigns addresses to individuals who may be anywhere in the world. Thus, the GeoLocation characteristics of an identification tag is lost. Although IPv6 has tremendously more addresses than IPv4, they seem still carrying on the same practice, as far as I could tell. This is why each ISP now owns multiple of ASNs (Autonomous System Numbers). Each ASN potentially could have IP addresses that are used anywhere in the world. This is, I believe, the root cause to cyber security vulnerabilities, because fundamentally there is no correlation of an IP packet to its physical origination nor destination locality, by just looking at the addresses in the header. This is why it has been so hard to locate the perpetrator of a DoS (Denial of Service) attack, let alone the dDoS (distributed DoS). Allow me to share with you some current work that attempts to deal with these issues.
A few years ago, we accidentally ventured into studying the IPv4 address pool exhaustion challenge, perhaps due to the curiosity from our telephony background. We now have submitted a proposal, called EzIP (phonetic for Easy IPv4) to IETF:
https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03
EzIP will not only resolve IPv4 address shortage issues, but also largely mitigate cyber security vulnerabilities, plus open up new possibilities for the Internet. These should relieve the urgency to move onto the IPv6. Originally, our efforts were inspired by two regularly updated worldwide statistics:
https://ams-ix.net/technical/statistics/sflow-stats/ether-type
https://stats.labs.apnic.net/ipv6
So, we thought that the initial EzIP targets would be emerging regions and rural areas of developed countries where assignable IPv4 addresses are in short supply. A recent article about the Internet activities provided a surprising new perspective:
https://dyn.com/blog/ipv6-adoption-still-lags-in-federal-agencies/
It concluded that the IPv6 adoption even at US Federal Agencies was moving at "a glacial pace". This seems to imply that the entire market for alternatives to the IPv6 approach, such as the EzIP, is now open. The general public should be equally informed of this kind of choices, instead of being led by the existing industrial interests that have been in deployment for nearly a decade. Hopefully, these provide you some updated references to review the subject.
For a brief summary and pardon me for being blunt, if IETF engineers had made the Internet a robust facility without continued "surprises" to the mass, either through IPv4 or IPv6, the ITU consisting of governments of countries representing the citizens / subscribers has no need to get involved. The current ITU participation in the "political fight" is a good sign for the sake of the consuming public's rights.
Feedback and comments are very much appreciated.
Abe (2018-06-24 18:42)
Not sure about that specific episode (or potentially conductive parts in obscure phone models), but the plain old telephone network does already send you nearly mains* voltage every time it makes your phone ring (try holding the bare wires in your hand when it rings - you won't be doing it twice unless you like getting shocked)...
* Yes I do know it's only a similar magnitude** not actually a closely near value.
** No idea what it amounts to in practice these days considering all the modern "spoof-a-POTS" kit converting fibre into a "landline" right outside your door - some of it apparently can't even make TWO phones on the same line both ring...
Well actually, they thought about coexistence since before the design was even chosen: RFC1671. IPv4 and IPv6 coexist perfectly. The underlying problem is that IPv4 (designed in the late 1970's) didn't provide any features to assist a version upgrade, except by including a version number. That makes interworking between IPv4 and IPv6 fundamentally hard. All that an IPv4-only device can do is barf when it receives an IPv6 packet. Please address all complaints to Bob Kahn and Vint Cerf.
All that an IPv4-only device can do is barf when it receives an IPv6 packet.
Which is the problem. It would have been nice if the packet at least looked enough like an IPv4 one that an IPv4 device could have said something like "This is a weird packet, I'll pass it to weirdpacket.ietf.com and it can figure out where to send it".
There is a reason for lack of IPv6 adoption. The ISP of the world don't bother with setting up IPv6 service because they claim there is no need for it. This is utter and total bullshit. This also goes for many ISP in Europe. I complained about lack of IPv6 with my ISP in Denmark (Stofa) and they told me that there was no need for it. Even if it is clear that IPv6 is a lot better in dealing with fast internet connection that they are selling (above 50Mbps speeds).
When I have used IPv6 it is clear that websites like YouTube are considerably faster to load videos than when I use IPv4 only (that is 99% of all time so far). There is also a speed element in this that nobody doesn't seems to be consider.
Hm... faster by design? Or a separate stack which is practically empty all of the time?
The "stack" is conceptional only – you're still moving electrons, photons or radio waves through the same propagator, with the same constraints.
It is certainly possible that a pure IPv6 setup could be faster due to better routing, but I suspect anecdotals comparisons are likely to have other causes.
Many ISPs provide underpowered routers to their customers that struggle to do NAT at full speed on their fastest services. Ipv6 liberates them from that burden. I personally witnessed a significant performance increase when my 1GBit line was IPv6 enabled.
I complained about lack of IPv6 with my ISP in Denmark (Stofa) and they told me that there was no need for it.
So change ISPs to one with a clue. My ISP (Zen) allocated my an IPv6 block with no complaint following a single email to them.
Now all I have to do is have (another) attempt to make the damn thing work..
(Each of the disparate layers can see the next - so the firewall can see the inside interface of the router, but not the outside world. The inside interface of the firewall can see the outside interface of the firewall but not the router.. etc etc for each of the layers.)
There are not 2^23 *servers* in the world, and very unlikely to ever be. And the new TLS means that we can even support multiple servers on the same IP.
The world has worked around the IPv4 restriction. Get over it. And NAT ain't going anywhere, even with IPv6.
And a few billion routes is nothing in a modern router. If we don't fill all that memory up with routes it might get filled up with something far worse, like XML.
A hack and a fudge is always better than a kludge.
It's been political from the very beginning.
There was a (technically) perfectly adequate proposal on the table from the IAB based on existing standards that got shot down owing to NIH. That was more than 20 years go. At that point there was a greater diversity of networking technologies and a window of opporunity for them to converge on IPv6: instead, they converged on IPv4.
And a lot of the intervening time has been spent elaborating recommended ways of transitioning, many of which have since been deprecated.
Whatever their internal disagreements, the IP community have a Unix-like disdain of outsiders, so I wouldn't assume automatically that the ITU's ideas are necessarily any more fanciful than have at times emerged from those of the true faith.
Whatever their internal disagreements, the IP community have a Unix-like disdain of outsiders, so I wouldn't assume automatically that the ITU's ideas are necessarily any more fanciful than have at times emerged from those of the true faith.
Obviously you've never had to deal with the ITU at the spec level if you don't understand the IP community's dislike of dealing with the ITU. Not that it's pleasant dealing with spec making at most times, but dealing with the ITU in particular makes no anesthesia dental work look like a holiday in comparison. Calling the ITU more political than technical is the mildest of the complaints that can be made.
So we can trust completely a bunch of loud-mouthed internet trolls who vote according to who can hum the loudest. We should just thank them for the screwed up virus-ridden internet we already have and just let them get on with it. After all it is just the good US guys like Facebook, Google, Amazon etc who really run the show now and they can't be wrong.
At least with the ITU it is easier to see who is screwing us. Having been involved with both I know the same big companies still run the show there anyway, but their control is slightly watered down and there is more conniving and bribery behind the scenes.
"In effect, it would downgrade IPv6 into IPv4+, with the plus simply being more addresses."
Good. I'm not an expert in any way on IPv6, but I know when something has been designed by a committee and IPv6 was. A spec comes in for a greyhound, and out comes a camel. IPv6 is a camel.
If they'd left it to engineers to sort out then we would have simply tacked on a most significant byte to the IP and subnet octets and be fucking done with it.
An engineer that did that would be very clearly out of their depth for the task.
For one thing, an extra byte isn't enough, so you'd have to go through the entire process again in a few decades' time. For another, you can't just tack an extra byte on. You still have to go and add a new record type to DNS (like v6 did), and add a new socket type (like v6 did) and a new socket API to handle the new types (like v6 did), and update RAs/DHCP (like v6 did), and update all the other standards that hard-coded v4 (like v6 did). Everybody would need to update their software to handle the new sockets and DNS types (like they do for v6) and configure their networks to use it (like they do for v6).
Your suggestion omits all of those necessary steps, and if you add them in then you basically end up with something that looks the same as v6 does -- except it's too small and would itself need to be replaced.
Why not 255.255.255.255 just becomes 255.255.255.255.255 that way legacy addresses become 0.255.255.255.255 and that's pretty easy to handle, probably doable in a firmware upgrade, I've spent no more than 30 seconds thinking about that so sorry if I'm oversimplifying it.
I've spent a little more than 30 seconds on it, but i went with 6 octets with the IPv4 space in the top 255.255.IPv4, taking on board some of the usefull refinements from the IPv6 spec
IPv8
a.b.c.d => X.Y.a.b.c.d Decimal
00:00:00:00:00:00 Hex (48bit)
0.0.0.0.0.0 = Unspecified
0.0.0.0.0.1 = Loopback
0.0.0.0.0.192/42 = discard block
0.0.0.0.1.0/40 = APIPA
0::02:00-00F::F = Reserved
010::0-01F::F = IANA
020::0-04F::F = Reserved (IANA Future Use)
050::0-05F::F = APNIC
060::0-08F::F = Reserved (APNIC Future Use)
090::0-09F::F = ARIN
0A0::0-0CF::F = Reserved (ARIN Future Use)
0D0::0-0DF::F = RIPE
0E0::0-10F::F = Reserved (RIPE Future Use)
110::0-11F::F = LACNIC
120::0-14F::F = Reserved (LACNIC Future Use)
150::0-15F::F = AFRINIC
160::0-18F::F = Reserved (AFRINIC Future Use)
190::0-19F::F = Private Address Space
20::0-3F::F = Future Use
40::0-5F::F = Future Use
60::0-7F::F = Future Use
80::0-9F::F = Future Use
A0::0-BF::F = Future Use
C0::0-DF::F = Future Use
E0::0-EF::F = Future Use
F0::0-FF::F = Future Use
FFFE0::0-FFFEF::F = Multicast
FF:FF:0::0-F::F = Ipv4 Migration
F::F = Broadcast
IPv6 address space is stupidly large, IIRC there is enough for 7 addresses for every atom in every person on earth an when you are talking frame headers, they become stupidly large, even with the header optimisations.
From my POV, The Issue with IPv6 adoption is security, no-one wants their internal addresses globally routable and the only reason the core is going to IPv6 is the lack of AS numbers, nothing to do with network addresses. I can see us developing a two tier internet, with an IPv6 core and an IPv4 edge with large orgs/lower tier ISPs doint the v6 to v4 NAT
"
The Issue with IPv6 adoption is security, no-one wants their internal addresses globally routable
"
Why not? That's a matter for the firewall at the border of the LAN to WAN. Which could block any or selected incoming connection requests to any or selected internal LAN addresses. While no longer needing to do any NAT.
"IPv6 address space is stupidly large"
The idea being that having to do it again will be a very long time in the future.
When IPv4 was created., 4 billion addresses was stupidly large space for the few hundred (possibly a few thousand) machines on the 'net and clearly not enough if the net went large (noone was sure how large it'd grow, or if it'd grow at all) - but that didn't matter as it was a hacky kludge only intended to last 4-6 years until the "real" internet protocol was finalised (which would have been IPv5). Original allocations were /8s and it was only when it became clear that IPv4 would have to stick around longer than expected that it downshifted to /16s
What happened to IPv5? It's still around. We know it as IPX (Internet protocol exchange), but it was impossible to route efficiently with it, so nobody bothered adopting it.
In fairness it's actually a perfectly reasonable and obvious question, but in equal fairness it's already been well answered by at least two or three previous posts: routing.
Briefly: you could indeed prepend an extra byte and increase your address space nicely.
But soft! Consider ...
Obviously you'd need to upgrade a colossal swathe of networking soft- and hardware to make it work. At enormous expense. And a factor of 255 isn't much future-proofing: the Internet of Shyte, cars, phones, toasters and wearables, it's all going to gobble vast amounts of address space and, barring global catastrophe, at a non-linear growth rate. You certainly don't want to have to obsolesce all that new soft/hardware again in seven years' time.
So having considered just one prepended extra byte, you'd soon conclude that, since you're gonna have to upgrade a monstrous wodge of stuff, you might as well make the thing seriously future proof and, say, prepend four extra bytes. Really, there are endless reasons to do this, and not one good reason not to. An extant switch that can't handle an eight-byte address couldn't have handled a five-byte one any better.
Upon looking into how that IPv4 system works, though, you're reminded that none of these devices doing the work has a built-in register of the physical location, and how to reach it, of every address on Earth. That would be crazy, for reasons of scale, efficiency and the irritating fact that they change. (They'd spend longer constantly updating their staggeringly vast memories than actually passing traffic.) And those inescapably good reasons become all much more significant still, for tomorrow's almost unimaginably bigger world. You need to maintain a simple, efficient method that helps every device know where to send bytes without it having to stop and thumb through a dozen phone books.
Thus, routing: and the efficiency of sensible hierarchies. Having specified enough bytes for devices from here to Andromeda—which was, we now see, a sensible, inevitable choice—you realise that you can now afford to scatter those devices quite sparsely (which has no disadvantages) and that you can group, sub-group, and sub-sub-group them in ways which allow individual routing systems at almost any level in the routing hierarchy, given an IPv6 address, to know virtually instantly where next to steer a packet. A workable though imperfect analogy would be the STD phone network: seeing an 01623 code at the beginning of a number means you can immediately pass the call along to a "router" in Mansfield, rather than saying "Hmm, 01623123XXX", lemme go see whereabouts in the whole of Britain that might be ... this may take some time".
This is not the most efficient use of the size of IPv6 in terms of sheer numbers of practical addresses, but the beauty is that there are so many potential addresses that it doesn't matter. It is very efficient, though, in ensuring you can quickly, using minimal phone books, get through to the address you want.
The point of this is that taking your initial perfectly reasonable premise, and applying some cautious stepwise logic, you come right back to something that looks like IPv6 anyway. Hopefully it also explains why you absolutely must not 1:1 map legacy IPv4 to IPv6 addresses—because that undermines the absolutely essential principle of the new standard in being able to efficiently direct traffic.
When a political ignoramus at the UN says scornfully "How difficult can it be?" the answer is "The devil is, as always, in the detail."
Indeed, it doesn't matter whether the political imbeciles are talking half-baked crap about IP, backdoor encryption, badgers or jet fighters: the answer is always the same one—"The devil is in the detail."
BGP route space is not an issue, we went passed that ages ago the issue is IPv4 only has space for 16bit or 65535 AS numbers and we are using 61140 advertising 724500 routes (agregated to just under 400k in the core)
we went over the 512k routes a few years back and no-one missed a step TCAM tables on modern routers have space for 2048k entries, which should keep us going for some while yet.
Talking v6 adoption, there are 52k routes and 15320 ASes in the current BGPv6 table and the v6 header has room for 32-bit AS numbers or upto 4294967295 ASes
address hierarchy and rationality is not something new and was / is done in IPv4, problem is organisations move about and spread their addressing globally necessitating extra routes in the global routing tables to state that a particular net is actually in the USA and not part of that larger network in europe anymore.
https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks#List_of_assigned_/8_blocks_to_the_Regional_Internet_Registries
https://en.wikipedia.org/wiki/List_of_countries_by_IPv4_address_allocation
IPv6 uses provider independent addressing to get around route fragmentation caused by large companies splitting their networks globally by moving them into the 2001:678::/29 address space assigning /48's.
https://en.wikipedia.org/wiki/Provider-independent_address_space
moving global companies into their own prefix may cause other problems with some admins or kit automatically trusting everything from 2001:678::/29
Network kit relies on the address info being x bytes into the packet, if you want to backward compatible you need to keep the IP packet header size constant and signal that an alternate or additional address is somewhere else. Just fiddling with the number of octets will just break what is already implemented.
There are largely unused options in the IPv4 header already that could be re purposed to indicate to look for the IPv6 address somewhere else but then that breaks encryption and other mechanisms reliant on the integrity of the packet.
you'd need to assign an IP specific for IPv4 to IPv6, maybe near the multicast range like 224.224.224.224 and then amend the protocol IPv4 field choosing a new value to reflect IPv4 to IPv6 and then in the option field you could then put the real IPv6 address. Routers in the ISP could then NAT IPv4 to IPv6 rewriting the headers. It will likely break any security like VPN's, TLS and provide a nice attack vector that most sane techs would want to steer clear off, but that's the route i would go to transition from 4 to 6 or beyond.
The main problem is that the new addressing scheme needs to be transparent to the old IPv4 kit which often did as much as possible in hardware to be quick and cheap, and also who owns and runs (ISP, IANA, Google, MS, Amazon) the special IPv4 address that DNS suddenly needs to respond with to keep legacy kit happy. Also doing things in software is a lot more cpu expensive than in hardware, which will slow lower powered gear no end and cause resourcing/capacity problems for service providers.
People need to also bear in mind that Layer 3 addressing is mandatory when going from 1 network to another, we still autonomously use MAC addressing at Layer 2 connecting with hosts on the same (v)LAN using arp to obtain the MAC of the machine to forward our info to adding it to the destination Ethernet frame.
" I've spent no more than 30 seconds thinking about that so sorry if I'm oversimplifying it."
You are.
With ipv6 overland on ipv4, you'd have the situation of IPv6 hosts being able to send packets to IPv4 hosts but a very slim chance of IPv4 hosts being able to return them without some kind of translation in the middle.
There has to be a gateway (or gateways) somewhere, which means you may as well just make it dual stack, transition to IPv6 and then discard IPv4
There's more IPv6 traffic now than there was IPv4 a decade ago and the majority of the traffic in/out of my home network is now IPv6. We're pretty much at tipping point and all those valuable IPv4 addresses will be useless eventually.
Its not that simple, many countries mainly third world cannot just cope with that. They are still getting to grips with the internet anyway. If it is a case of just doing that then firdt world countries MUST accept the bill for converting all those third world countries that need it. IF and I say IF the powers that be want to upgrade, then they must make those that want it pay for those that cannot afford it!
"In short: the latest proposal from the UN to get everyone onto the next-generation internet was developed without talking to the people who actually build those networks, and as a result it is a complete mess."
...sounds like the cloud migration project at a place I once worked at. "Infrastructure Free". If a fellow reader see's this, they'll probably work out who wrote this post from that last quote :)
Isn't IPv6 over 20 years old? If it were actually good in everything it had to do wouldn't it be widely adopted by now?
If I had a nickel every time I heard "this is the year IPv6 will really take off" and "this is the year of the Linux desktop" I'd be a billionaire.
Backwards compatibility is *everything* in the technology world, especially if it's something the average Joe uses. I don't care if your solution is supposedly superior, if it's missing backwards compatibility than it's actually inferior despite what you think. Your 4G cell phone still supports 3G and 2G for a reason. Your 4K TV still supports 480i for a reason. You can run almost all Vista apps in Windows 10 for a reason. And in all those examples, there is a consumer-visible benefit of upgrading unlike IPv6.
Things were far different 20 years ago than they are today. Why continue push a 20-year-old solution for a modern problem? So the UN came up with solutions, which the IPv6 advocates/snobs were automatically going to hate for various reasons (mainly pride). But the real message from the UN to IPv6 advocates is that backwards compatibility with IPv4 is essential. Stop providing excuses and start providing solutions.
I read the document. On v6, you are nominally expected to receive a /48, which gives you 16 bits (4 hex characters) to play with for your subnetting. Y.IPv6RefModel is mostly just a suggestion on how to use those 16 bits.
The suggestion boils down to: use the first character for a site ID, the second character for a category ID (DMZ/servers/LAN/IoT/other) and the third and fourth for a subnet number. It then says that if you set the site ID to 0 and make sure the 4th hex character is also 0, the subnet plan only uses 8 bits which makes it small enough to reasonably insert into a v4 address (since it then only needs a /16 rather than a /8).
It's not explained well in the recommendation, but if you use the same subnetting plan for v4 and v6 and are careful to also use the same host IDs for dual stack devices (which involves limiting yourself to only the first 256 addresses of the v6 /64...) then it's possible to define a stateless translation rule between v4 and v6 IPs for those devices. However, the mapping is purely local for the given network and there's no way to tell random people on the internet about the rule, so any translation would have to be done on your own local NAT64 router. There's no arbitrary v4<->v6 tunneling here.
Note that none of this is fundamentally new. You could already do all of it; this is just a recommendation for one way of going about it.
As for my opinion on the recommendation... it's coherent and it looks like it achieves the goals it sets out to achieve, but I'm not convinced the goals make much sense. Most people already have a v4 network with an incompatible addressing plan, so you can only really use this on a greenfield network. But if you have a greenfield network then there are better ways of going about it without paying the costs of this plan.
It's not explained well in the recommendation, but if you use the same subnetting plan for v4 and v6 and are careful to also use the same host IDs for dual stack devices (which involves limiting yourself to only the first 256 addresses of the v6 /64...) then it's possible to define a stateless translation rule between v4 and v6 IPs for those devices.
it'll look stateless to your eyes but it is in no way stateless for a network device. Network devices are optimised to work in hardware where possible and for IPv4 they know the address info starts at bit 96, your mapped IPv6 address will not be at bit 96 and so the IPv4 stack will have to be re written to recognise if its reading an IPv4 or IPv6 packet and look at bit 64 instead. All IPv4 stacks along the path will need rewriting to accommodate the change, and likley new firmware if the hardware can accommodate the change. If your going to do that then you may as well make them all IPv6.
https://en.wikipedia.org/wiki/IPv4#Packet_structure
https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header
you can't force IPv4 to read an IPv6 packet as their structures are completely different.
At best you could design the IPv6 stack to recognise and work with an IPv4 packet but that'll likely just introduce vulnerabilities.
Don't forget this is just layer 3 addressing we are discussing. So long as the host traffic is being sent to can detect and use the appropriate stack for interpreting L3 addressing both addressing schemes can coexist on the L2 Lans & WANS as Ipv4 has done for decades. Its very important to understand and realise that L2 & L3 are distinct and that L3 overlays ontop of L2.
hell will freeze over before government and organisations will take and use the advice of actual engineers who work in said arena...
Lets say for a minute that when IP4 became apparent it would not be fit for use in a few years time that they asked actual network engineers for solutions The people who for years had been maintaining the shire on a piss poor budget... The solution would be a cost effective, simple to implement and workable solution that would be easier to expand on later if need.
but no....
first of all, you have to have meetings with people that the only knowlage of moving packets about are brown ones stuffed with low denomination bank notes. These meetings and brain storming sessions will have to take place in exotic locations and will need at least 6 sessions. Then they will send an obligatory memo to the network engineers outlining the proposed plans, when the network guys tell them what a stupid plan they have, that means they will need a further 6 sessions brainstorming in another exotic location.... Then decide that the network engineers dont know what they are talking about, and the bloke they met in the bar in the hotel they were having the meetings in have a tailor made solution already for them... the company the bloke works for will foot the bill for another 3 long weekend breaks in even more expensive and exotic locations, (including hookers and drugs)... the team then come back from holiday, then tell the network engineers what the plan is and they have the job of implementing some shitty kit that is not going to do what's needed.
My initial idea would be
First 16 bits = country code
Next 16 bits = area code in country
Next 16 bits = ISP within area
If the ISP uses the next 32 bits to identify each of its customers, that leaves each customer with an address space of 48 bits for each device on its internal LAN
48 bits is the length of a MAC address, so why not have each device using its (globally unique) MAC address as the last 6 bytes of its IPV6 address? DHCP would provide the first 10 bytes of the IPV6 address, each device would provide its own last 6 bytes (which could be locally managed if desired). Which would have the possible advantage that the IP address would tell you the manufacturer of the item you are communicating with.
The last thing that the theorists want is a simple plan that anyone can understand!!
(Also there is the unfortunate fact that MAC addresses are not always unique - some network card makers reused MAC addresses despite the rules saying that they must not. An individual manufacturer code (first 24 bits) only leaves 24 bits (16M) for the individual device. A manufacturer is supposed to request an new manufacturer code if it manufactures over 16M devices - however some just recycle the addresses.)
"
There's also the issue that knowing a MAC can lead to a masquerade or other lower-level attack. It's one reason IPV6 had to be altered as it wasn't considered from an adversarial POV.
"
Only by an attacker on the same local sub-net. And anyone with that access would be able to gather all the MAC addresses using a simple packet-sniffer.
Needs only one (decimal) digit for an IP address, statically allocated as follows.
1 - The Register
2 - Facebook
3 - Netflix
4 - Google
5 - Microsoft (just block this one to stop Win10 from slurping)
6 - AliExpress
For intranets:
7 - You printer (replacing 192.168.X.X)
8 - Your boss (replacing 10.X.X.X)
For you:
9 - yourself (for return packages. Carrier-grade NAT is used in case somebody else wants to use the Internet at the same time)
0 - localhost
Nice small routing tables.
The first lesson of economics is scarcity: there is never enough of anything to fully satisfy all those who want it. Why IPv6 want to broke this?.
There are some elite guys: Level 3, Cogent Co, AT&T, IBM and some big telcos worldwide. They have a lot of IP because they came first to the party.
Don't expect IPv6 from those. They still want remain status quo.
"The first lesson of economics is scarcity: there is never enough of anything to fully satisfy all those who want it."
Tell that to the developers of ZFS. As I recall, 128 bits is more than enough to individualize all matter in the known universe. Plus if those words really were true, explain gluts (which HAVE occurred in the past).
Oh, and PS. Finish the quote: "The first lesson of politics is to disregard the first lesson of economics."
You say that like there MUST be a way to detect an infinite loop (yet Alan Turing PROVED it impossible). Like there MUST be a way to cram 13 eggs into an egg carton only built for 12 without breaking anything.
Therein lies your problem. The way IPv4 is set up with some HARD limits. It's basically designed NOT to be expandable so as to be simple (consider the timeframe it was developed--when silicon horsepower was pretty precious--the whole "can you fit everything into a few kB of RAM and a sub-MHz processor" thing). At some point, you can't expand anymore without bringing the whole works down. Trying to bolt something onto IPv4 will just create vulnerabilities that can bring the whole works down.
Our study now indicates that there is practically no more shortage of IPv4 address, let alone going through the trouble to deploy IPv6.
https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03
Since EzIP can multiply each public IPv4 address by 256M (Million) fold to support a sub-Internet without affecting current equipment, this enables over 75% of nations to serve their respective countries starting from just one IPv4 address that is already assigned to that nation from a RIR (Regional Internet Registry). This is in addition to the current Internet services.
Essentially, the CIR (Country-based Internet Registry) model administrating IPv6 addresses proposed by ITU-T a few years ago can now be stealthily implemented under IPv4, even without forming the sixth RIR at all.
With two styles of Internet operation disciplines and conventions operating simultaneously in parallel, consumers will truly have two options to choose from.
Thoughts and comments would be much appreciated.
Abe (2018-08-18 22:52)
Except you'll STILL need edge routers. You can achieve the same thing with NAT64/NAT46 proxies in the same locations you'd have to put EzIP routers. Plus by starting fresh, you simplify the routing problems upstream that can lead to additional latency that stacks up over time. AND your plan relies on the Option field, which isn't trusted that much and can't be assured to propagate.
Hi, Charles 9:
0) Granted, there are many existing approaches that are capable of similar results. But, you seem to be still beating around:
1) "Except you'll STILL need edge routers.": ER is part of the existing Internet architecture. Why should I not using it? EzIP is doing the best an enhancement should be doing, i.e., leaving the ER alone to do what it has been doing. Do you see problems?
2) "... achieve the same thing with NAT64/NAT46 proxies ... ": Anything touches IPv6 makes many people dizzy. Can we look at a solution without any hint of IPv6, if it is possible to get the job done without IPv6?
3) "Plus by starting fresh, you simplify the routing problems upstream that can lead to additional latency that stacks up over time.": You lost me because this sentence reads rather convoluted. Please expand.
4) "... your plan relies on the Option field, which isn't trusted ... ": I heard rumors about this. But, is this part of the original RFC791 or because the current implementations are not "Kosher"? For the latter, we have the time to fix it because the immediate application of EzIP will leave the current Internet totally intact:
EzIP will empower most (75% or more) nations to begin setting up a new Internet facility in the form of sub-Internet(s) from just one (or more) public IPv4 address already assigned to that country by a RIR (Regional Internet Registry). Then, each of the entire sub-Internets will appear as an ordinary IoT to the rest of the Internet. So, while each country is deploying something new to resolve their current IPv4 address shortage induced problems, nothing in the existing Internet needs be changed at all!
5) The configuration outlined above allows simultaneous performance comparisons between two parallel active systems. It is the ideal situation for consumers among other benefits. I believe this is the philosophy that the "Internet promoters" have always been advertising. Now that we have a real one in our plain sight, everyone should be happy.
Your thoughts?
Abe (2018-08-22 18:16)
Dear Colleagues:
0) Here are two pieces of updated information for share:
1) The following is a discussion thread on the "state of IPv6". The findings are quite surprising.
http://www.circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/
2) Then, you may like to have a look at the feasibility demonstration report below about our proposed architecture for expanding IPv4 address pool, addressing ITU's CIR proposal, etc.:
https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf
These should provide some material for furthering the dialog.
Abe (2020-08-30 16:19 EDT)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
