If you're getting downvoted and can't work out why, that XKCD is massively overused and shoehorned into conversations that have no bearing on what's being discussed.
The whole '15 competing standards' meme only really makes sense when there are 15 competing standards bodies. In the case of IP addresses, there is only one standards body, the IETF. There is one legacy standard (IPv4), one new standard (IPv6), and the only question is how best to ease the transition between the two. I see no problem if that transition relies on an interim protocol.
Which would suggest there's room for an integration system that does work. In any case, the goal is a transition to IPv6, as long as the integration systems all share that goal there can be interoperability between them.
Genuinely curious - Why? We were considering doing so at one point for PtP links (equiv to a /30 or a /31 if you area really bleeding edge) - but then decided that there wasn't any reason to not just use /64s everywhere.
I take your point though - it certainly is theoretically (and in practice) possible to doing something other than a /64 - I've just never seen it in the wild.
I have heard of one good reason: with a /64, someone sending packets to random addresses within that /64 will fill up the neighbor cache, while with a smaller network like a /126, that can't happen.
You may be underestimating how many IPv6 addresses there are! 2^128 is huge. Like, if we assigned one trillion new addresses every second since the birth of the universe, we’d still have enough left over to do the same in another 800 million parallel universes. Truly astronomical numbers.
Obviously not all of these addresses will be used; in practice we aren’t going to run out any time soon.
While you're right, it is huge. This mistake has been made in computing time and time again. You think you've got adequate scale for your solution but you didn't anticipate X which introduces new growth that out paces your design.
Assuming the internet has been growing exponentially since the beginning and will continue to do so indefinitely.
IPv4 has 32 bits and lasted us 34 years so far. Let's call it 32 years. Address space would need a nice and tidy 1 bit extra per year. That would mean IPv6 would last until around the year 2110.
Of course this assumes we don't assign half of the address space to Apple, Facebook, Google and their friends, or something silly like that, like it was done with IPv4 (with the equivalent "friends" at the time).
I read in one of the IPv6 RFCs (don't recall which one at the moment), that initially only 1/8 of the possible address space will be allocated. If for some reason that space is filled up, there's still another 7/8 which can be allocated with a more conservative policy.
End users should receive /64 subnet and servers should receive /48 subnet. Given that many users might want to run some servers, it's just 65536 times more than IPv4. Good enough, but not future proof enough if you ask me.
"IPv10 allows hosts from two IP versions (IPv4 and IPv6) to be able
to communicate, and this can be accomplished by having an IPv10
packet containing a mixture of IPv4 and IPv6 addresses in the same
IP packet header."
Not only because it is a proposed bridging solution between IPv4 and IPv6, the "version number" of IP is actually somewhat more like an identifier for subprotocols. There is the list [1] of all taken version numbers managed by IANA.
IPv4 is the version 4 because former versions of protocols (0 thru 3) are long obsolete; IPv6 is the version 6 because the version 5 was taken by another experimental protocol; and IPv10 ought to be the version 10 because the versions 6 thru 9 were used for proposed successors to IPv4 (and eventually the protocol of version 6 was chosen). I'm not very sure if other assignments were possible in the current standard process though (e.g. up to IPv14 would be available).
Mildly off-topic, but I've always wondered about having a non-fixed length address scheme: if there are 64 bits in the address, let the first 8 bits (64/8 = 8) be 1 and the 9th bit be 0. This way we encode the length of the address. After that, every bit is available for use (all 64 - 9 = 55 bits).
Suddenly want to increase the domain from 2^55 to something much higher? Use a 15-byte address where the first 15 bits are 1s and the 16th bit is 0. The rest of the (15*8 - 16 = 104) bits are available.
You get the point - we can arbitrarily increase the size without giving up flexibility.
What's the drawback if we use something like this? Routing troubles? Speed?
Alternative method: the addresses can be as many bits as required, but every bit index that's a multiple of 8 must be 1. The last byte is signified by a byte having 0 at index 0. Basically:
Not quite, UTF-8 encodes the length of the sequence in the first byte, instead of marking the end, this makes more sense because it is easier to detect broken input.
1110xxxx 10xxxxxx 0xxxxxxx obviously has a byte missing and is broken, but [1]xxxxxxx [0]xxxxxxx could have any number of bytes missing an would just yield the wrong value.
- That means, if the received IPv10 packet contains an IPv4
address in the destination address field, the router
should use the IPv4 routing table to make a routing
decision, and if the received IPv10 packet contains an IPv6
address in the destination address field, the router should
use the IPv6 routing table to make a routing decision.
- All Internet connected hosts must be IPv10 hosts to be
able to communicate regardless the used IP version,
and the IPv10 deployment process can be accomplished
by ALL technology companies developing OSs for hosts
networking and security devices.
Earlier in the RFC ( reasoning on IPv6 support ) :
... also, not all enterprises
devices support IPv6 and also many people are afraid of the service
outage that can be caused due to this migration.
If migrating to IPv10 requires the migration of the same infrastructure, what's the point of having it?
I'm pondering on this. I think the idea is to allow ipv6-only users to connect to ipv4-only users -- thus making the IPv6 migration "easier" for, e.g., ISPs that are deploying ipv6-only networks (especially on mobile). But the RFC doesn't really mention that anywhere.
The ipv4-only users still need a way to specify an ipv6 address to talk to ipv6-only users. This RFC seems to suggest that they should just send an ipv10 packet. But then they wouldn't be ipv4-only anymore, and might as well adopt ipv6.
I think the idea here is to have to update the end points only, not having to upgrade the expensive infrastructure in between, which was the reason IPv6 was so slow to be adopted in the first place.
The expensive infrastructure needs to be taught about ipv10, unless it doesn't actually look at the packets. Maybe there are some that ignore the protocol version field and could be tricked into treating it like an ipv4 packet, but there's nothing in the RFC to suggest that's the plan.
I don't think that's possible. The routers are the ones that need to decode the IPv10 packet, see if it contains an IPv4 or IPv6 destination and route accordingly. From my reading of the RFC that means all routers, not just the customer appliances. It kinda feels like IPv6 all over again.
> That means, if the received IPv10 packet contains an IPv4 address in the destination address field, the router should use the IPv4 routing table to make a routing decision, and if the received IPv10 packet contains an IPv6 address in the destination address field, the router should use the IPv6 routing table to make a routing decision.
Most consumer routers don't really maintain routing tables (aside form some static mappings for you internal network) so this appears targetted at actual internet/ISP routers.
<sarcasm>
Those big expensive things that we regularly replace and provide with updates.
</sarcasm>
Decoding internet packets at scale is usually done inside hardware so at the very least we'll need new ASICs for this I'm guessing.
> [..] and the IPv10 deployment process can be accomplished by ALL technology companies developing OSs for hosts networking and security devices. [..]
Sometime further down the line this shows up though:
> [..] and it is just a software development process in the NIC cards of all hosts to allow encapsulating both IPv4 and IPv6 in the same IP packet header. [..]
I'm not quite sure what the author is getting at but packet encapsulation isn't cheap, you usually don't want to do that in software for large routers, unless they're outfitted with FPGAs for this purpose and you reprogram those instead. I've also never actually seen a firmware update for my NIC show up so I wonder how they envision that happening. Even if that's the case, you'd then still need to update all hosts, which to me seems far from trivial.
Problem was mandatory multicast support for IPv6 for the last decades, which requires a lot of memory upgrades to the routers, which nobody cares, because they rather invest in other things than memory upgrades to their routers.
Why should they support better TV and Youtube streaming might be their reasoning.
Where did you get this information from? Core internet routers do not really get "memory upgrades" at all (like it's a stick of ram you can replace, it's not), especially for multicast routing requirements.
I have the same understanding here. It allows those who switch to IPv6 easily communicate with IPv4 (backward compatibility?)...a bit confusing though since this is handled at router level.
We had a strange case recently...some of our remote staff were unable to connect to our NY VPN from SC. After tracing we found their ISP started using IPV6. Anyways, after we made changes...within a few hours the isp went back to IPv4.
Edit - 19 years to switch is a long time...old as the modern internet. Don't fix it if it ain't broken :)
Besides, we've already got a solution to maintain IPv4 connectivity from IPv6-only networks anyway, DNS64 and NAT64. There's literally an entire /96 subnet in the IPv6 address space dedicated to this task, 64:ff9b::/96.
I'm lost for words. How does somebody get to the point of submitting a draft to the IETF, seemingly believing this is a new idea in 2017? Surely this must be trolling?
"Each satellite holds routers connected to other routers on other satellites using fiber optic cables"
You'd need 265,000 km (164,600 miles) of fibre to loop around the geostationary arc!
Then it's much more flawed if it's for anything but geostationary orbits. The way it's written it sounds like he doesn't understand that geostationary satellites have to be high up in the equatorial plane as he mentions each satellite having a specific area.
Also, interesting snippet near the end of that draft: "Each satellite is connected to an earth station which is connected to the Internet core network on earth." He thinks there's a single "Internet core network" (http://tvtropes.org/pmwiki/pmwiki.php/Main/InternetIncorpora...)? No wonder he thinks it would be easy to forklift upgrade the whole Internet to his new protocol...
I actually like their conservative approach with version numbers.
For what it's worth, in IPv4 time there were some experiments with a new IP variant, those got the version 5. You won't find these anywhere in today's networks, but just to be sure, the next official version got number 6.
The opposite is what we see in some programs and libraries: First, they publish version 1.2.2. Then version 1.2.3. But ooops, 1.2.3 had an issue. Well, let's just release a new tarball and label it 1.2.3 as well. Hopefully nobody noticed this. How big are the chances that somebody downloaded the broken package during the past 2 hours? (I guess using another number for the fixed release, such as 1.2.4, would have been too expensive. Or so.)
Libraries at least should have mechanisms to release 1.2.4 & yank 1.2.3 from whichever package repos they're on. Package repos generally won't allow pushing an update to a version without version bump
I wait for it to be validated by the client and then apply the patch according to the established controls and protocols if the risk assessment team gives a green light.
For crates.io it works out that if you yank a package no new packages can be published relying on the yanked version, but packages already relying on it can still download it
Hex.pm (for Erlang/Elixir packages) allows you to re-publish the same version multiple times as long as it's within a set window of time after the first upload.
As a side note, I was very confused about IPv6 addresses popping up in my server logs when I knew it only had IPv4 provisioned. Turns out CloudFlare had automatically published AAAA records for my domain and was v6-to-v4 proxying my inbound HTTP/HTTPS traffic. For free! Just another reason to love CloudFlare.
Clearly the IPv6 space doesn't compress 1-1 into the IPv4 space but this gives you way to work with the top 64 bits of the IPv6 address and then feed it into your anti-abuse system. If your abuse system works probabilistically then this isn't too problematic as this becomes just another signal. And IPv4-based systems already deal with multiple people behind the same IP because of NAT.
You have users who can already access a site using IPv4, but want to use IPv6, and you have an anti-abuse system that lacks support, so you decided to invent a new kind of NAT, rather than require the customer to just fix their anti-abuse system, which they'd need to do on other platforms anyway?
The feature isn't nuts, but the rationale seems so.
I am not sure about the base idea, but isn't the ipv10 (i.e. protocol number 10) going to cause problems?
Aren't hosts expected to choose the highest protocol number they understand? So basically this forever kills (protocol) ipv6 and replaces it with ipv6+ipv4, which is never going to fly (because the "underlying" ipv4 is sunsetting and hopefully gone within a decade)...
Efforts to get ipv6 rolled out faster and easier are imho good. Though, not sure if this actually helps.
I am not a fan of using hardware/mac addresses in ip addresses, in my opinion its a big security/privacy issue. Tracking, hardware details leaking etc.
And somehow i think ipv10 will make the migration for some parties even less of a priority or less urge to 'finish' it.
I think if they really want to 'promote' and accelerate IPv6 rollout... Facebook and Instagram should have ipv6 days only. E.g. one day in the week or month, you can only connect with facebook/instagram over ipv6; then you'll see how fast endusers will want to be on ipv6 (and once all endusers are dual stacked.. parties can slowly start disabling ipv4 all together). And then i assume the ipv4 only parties will make a bit of a hurry getting their ipv6 in order.
No, that not. monies are too important for many. But if they would consider such, hypothetical, i think it would be a great motivator for ipv6 adoption.
I guess all it takes to push a draft is hubris. The clear fact it hasn't received editorial feedback from a single native speaker is an indication how popular this is. (not to shame non-native speakers!)
> During the transition of the Internet from IPv4 to IPv6, it is typical to operate in a mixed addressing environment. For such use cases, a special notation has been introduced, which expresses IPv4-mapped and IPv4-compatible IPv6 addresses by writing the least-significant 32 bits of an address in the familiar IPv4 dot-decimal notation, whereas all preceding ones are written in IPv6 format. For example, the IPv4-mapped IPv6 address ::ffff:c000:0280 is written as ::ffff:192.0.2.128, thus expressing clearly the original IPv4 address that was mapped to IPv6.
That needs some sort of gateway to work, but I'm assuming that that is the kind of thing your ISP would do for you.
And if you have to convert each IPv4 only host to an IPv10 host to use it, why not convert it to dual stack IPv4/IPv6 instead?
NAT doesn't solve the issues with IPv4, it merely delayed them. IPv6 is still the future, but everyone from ISP's to switch and router manufacturers have been dragging their feet on a real push to get us off IPv4. Hell, there are still modern switch platforms out there with full Layer 3 IPv4 support but IPv6 is curiously omitted - you've got to buy a bigger switch to get support for modern protocols (or an implementation that isn't totally gimped).
NAT is still ultimately a kludge for security, a stateful firewall is a much better solution and doesn’t interfere with the assumption that an IP address represents a device and not an entire corporate/home network.
I have a better solution to the IPv4 problem. It will just take Google to put "Websites that provide IPv6 traffic routing will be prioritized on search results" in their search ranking rules – Bam! Problem solved. It seems to have worked with SSL.
The web is not Internet, also all website servers would be IPv4/6 compatible but most clients would still use IPv4 to access the website and they largely outnumber servers.
Wow, I never heard about this until now - it's about damned time! Now if Google and MS could step up to the plate we'd have a large chunk of services in a position ready to enable IPv6 support.
Real IPv6 deployment is held up because of the 50-100 biggest ISPs in North America and Europe. Get them to start taking this seriously and everything else falls into line over night.
The IETF barking out other suggestions is just a distraction.
Don't worry, this is just a random submission from someone who also came up with the 'new' idea of accessing the Internet through satellites this year... (Posted above - https://tools.ietf.org/html/draft-omar-si-00)
It's not going to be seriously considered (it doesn't make sense anyway - upgrading to this protocol would be the same effort as upgrading to IPv6 - it's entirely pointless).
I think the funniest part is that fiber optics are irrelevant in space, you'd be better off just pointing a laser at another satellite and just using space as the medium.
The UK is pretty much there on IPV6 - BT (and by extension anyone who uses BT's network, so, everyone except Virgin Cable and Kingston Communications in Hull) now offers native IPV6 - you get delegated a /56 (albeit a dynamic /56 allocation for most).
The tricky part is router support - BT's own equipment supports it for the most part (Only the Smart Hub and Home Hub 5), but third party routers can be difficult - TPLink still only support /64 prefixes on their current firmware, and their firewall doesn't work properly when using their beta firmware that supports /56 prefixes.
So - the infrastructure is there, but support is variable.
Partly - FTTC is run over BT's network all the way through to 27 regional POPs where it is passed over to the providers network, or they can opt to use the BT network instead.
From where I'm standing the big problem is enterprises not moving.
Most big ISPs run IPv6, and many provide IPv6 to their end customers. In the US Google see 35% of connections coming in to them over IPv6.
But convincing the average small-medium enterprise to enable it on their routers (which isn't automatic as is the case with home connections,) is proving difficult.
> But convincing the average small-medium enterprise to enable it on their routers (which isn't automatic as is the case with home connections,) is proving difficult.
We're setting up a new SQL Server cluster, we literally disabled IPv6 in Windows because "we don't use it" - meanwhile I have 6 separate /24's assigned to my team that are a pain in the butt to manage just to ensure I don't run out of addresses. My life would be so much easier if I just had a v6 /64 for dev/test and another /64 for staging and production.
One area where I am not keen to see IPv6 spreading is SMTP traffic. IP reputation while not perfect is still a useful layer of lipstick on the SMTP pig.
One area where I am keen to see IPv6 spreading is IoT. I don't know if we can ever secure those things, but it will certainly make scanning the IP address space for vulnerable devices impractical.
> IP reputation while not perfect is still a useful layer of lipstick on the SMTP pig.
just use the prefix for reputation. You can assume that each user will have received a /48. Yes. There are some ISPs out there handing out /64's or even a /128, so it might be somewhat too broad, but blacklisting a the whole /48 and then white-listing on (rare) demand is probably the way to go.
If you assume the user has a /48 when they really have a /64, you're off by a factor of 65536. For address blocks allocated to business customers, a nontrivial percentage (say 10%) may be operating mail servers. Which means that one misbehaving customer will cause you to block thousands of honest ones. That's a lot of white listing to do.
In contrast I look forward to not having my 20 year old domain (never used for commercial emails and with a volume of around 1 outgoing message per day) blocked because a completely different server that my ISP used has a client who started spamming.
This is guy is something different (not that it would make his ideas worth any less, more on that later).
Some of his recent efforts:
Satellite Internet [0] (kudos whatidonteven) - I don't think he thought this one through. What is wrong with the current approach? Should we really erect wires in outer space?
He is currently kind of harassing the IETF via mailing lists about IPv10, threatening "If the ideas explained on these drafts will be used, discussed or published by the ietf, legal actions will be taken." [1] - not really how the IETF works.
The version number as "ingenious" 4+6 is annoying, IMO. That's not how version numbers work?
His drawing on his his very own routing protocol - KRP - are also something [2]. Although the quality of his drawings has nothing to do with his ideas per se, it seems he rushed it together in an afternoon.
I don't want to say that he is overestimating his own intelligence, rather that he is underestimating the efforts, hard work and intelligence of everyone else working in this field mostly professionally. His proposals can not easily be judged, because they dismiss almost everything that others have done previously. Why should so many smart people have missed these (obvious/simple) solutions? We are where we are for a reason. You need a good chain of arguments to "dismiss" the current state of the art.
He seems to actually be completly unaware that satellite internet exists at all... (Judging from the second and third points of the introduction).
Who knows what's going on though - maybe he's just young and inexperienced? This is exactly the kind of thing I might have done as a 13 year old if I had stumbled on the IETF...
I have GigaBit internet from AT&T. Speeds have been terrible and pings were like 130ms. I disabled IPv6 on my laptop and things improved. I disabled IPv6 on my router and it improved even more.
You’re making a good case for something other than IPv6. And since we’re running out of IPv4 addresses, we will need to switch to something else, eventually.
In case folks haven't been involved in the IETF RFC process before, even though this is hosted on IETF.org this is just a ID (Internet Draft). They can be submitted by literally anyone. The tool to do so is here:
https://datatracker.ietf.org/submit/
Lots of crazy things get submitted, and never looked at again. In order for drafts to stay alive they need to be updated with comments every 6 months. Sometimes they lead to things, and sometimes they don't. Usually some IETF working group has to be interested for a draft to go from a draft to an actual RFC.
Given the lack of comments on the draft, and the fact its not actually attached to an IETF working group, its fairly safe to say that this isn't actually going to become a real protocol anytime soon.
131 comments
[ 3.2 ms ] story [ 224 ms ] threadSituation: There are 14 competing standards
"14?! Ridiculous! We need to develop one universal standard that covers everyone's use cases." "Yeah!"
Situation: There are 15 competing standards
Src: https://xkcd.com/927/
The whole '15 competing standards' meme only really makes sense when there are 15 competing standards bodies. In the case of IP addresses, there is only one standards body, the IETF. There is one legacy standard (IPv4), one new standard (IPv6), and the only question is how best to ease the transition between the two. I see no problem if that transition relies on an interim protocol.
edit: theoretically, we'll only ever use a fraction of that, both by design and because that's a huge number
Just because the IETF says SLAAC or bust doesn't mean it's true.
I take your point though - it certainly is theoretically (and in practice) possible to doing something other than a /64 - I've just never seen it in the wild.
Obviously not all of these addresses will be used; in practice we aren’t going to run out any time soon.
or
340,282,366,920,938,463,463,374,607,431,768,211,456
IPv4 has 32 bits and lasted us 34 years so far. Let's call it 32 years. Address space would need a nice and tidy 1 bit extra per year. That would mean IPv6 would last until around the year 2110.
But will the internet keep growing exponentially until then? How many people will even be alive by then? According to https://en.wikipedia.org/wiki/Projections_of_population_grow..., predictions used by the UN range from 7 to 18 billion people. Let's round it up to 20 billion people. How many IPv6 addresses could we give out to each person? According to https://www.wolframalpha.com/input/?i=2%5E128+%2F+20*10%5E9, 1.7 * 10^28, which is a lot. But okay, we have a lot of computers per person and not all computers are associated with individuals. So what if we do something crazy, like give out IPv6 addresses to the (human) cells in everybody's body? https://www.wolframalpha.com/input/?i=1.7+*+10%5E28+%2F+cell..., that would be about 1.7 * 10^14. What if we give each cell some IPv6 addresses per second (pretending all of our cells live for 80 years)? https://www.wolframalpha.com/input/?i=1.7+*+10%5E14+%2F+(80+...
Here we land on 67 thousand addresses, per second, for each human cell in the bodies of 20 billion people, for the span of 80 years.
That's how many IPv6 addresses we'll need to use before we run out.
We have made this mistake before, but 128 bits really is a lot.
"IPv10 allows hosts from two IP versions (IPv4 and IPv6) to be able to communicate, and this can be accomplished by having an IPv10 packet containing a mixture of IPv4 and IPv6 addresses in the same IP packet header."
IPv4 is the version 4 because former versions of protocols (0 thru 3) are long obsolete; IPv6 is the version 6 because the version 5 was taken by another experimental protocol; and IPv10 ought to be the version 10 because the versions 6 thru 9 were used for proposed successors to IPv4 (and eventually the protocol of version 6 was chosen). I'm not very sure if other assignments were possible in the current standard process though (e.g. up to IPv14 would be available).
[1] https://www.iana.org/assignments/version-numbers/version-num...
Suddenly want to increase the domain from 2^55 to something much higher? Use a 15-byte address where the first 15 bits are 1s and the 16th bit is 0. The rest of the (15*8 - 16 = 104) bits are available.
You get the point - we can arbitrarily increase the size without giving up flexibility.
What's the drawback if we use something like this? Routing troubles? Speed?
Alternative method: the addresses can be as many bits as required, but every bit index that's a multiple of 8 must be 1. The last byte is signified by a byte having 0 at index 0. Basically:
This problem is not one of technical difficulties. There are many protocols that could be designed that are future-proof, efficient, etc.
The issue is entirely social. Everyone needs to use the same protocol(s), so there's a HEAVY emphasis on 'if it ain't broke, don't fix it'.
I might be missing something though.
> That means, if the received IPv10 packet contains an IPv4 address in the destination address field, the router should use the IPv4 routing table to make a routing decision, and if the received IPv10 packet contains an IPv6 address in the destination address field, the router should use the IPv6 routing table to make a routing decision.
Most consumer routers don't really maintain routing tables (aside form some static mappings for you internal network) so this appears targetted at actual internet/ISP routers.
<sarcasm> Those big expensive things that we regularly replace and provide with updates. </sarcasm>
Decoding internet packets at scale is usually done inside hardware so at the very least we'll need new ASICs for this I'm guessing.
> [..] and the IPv10 deployment process can be accomplished by ALL technology companies developing OSs for hosts networking and security devices. [..]
Sometime further down the line this shows up though:
> [..] and it is just a software development process in the NIC cards of all hosts to allow encapsulating both IPv4 and IPv6 in the same IP packet header. [..]
I'm not quite sure what the author is getting at but packet encapsulation isn't cheap, you usually don't want to do that in software for large routers, unless they're outfitted with FPGAs for this purpose and you reprogram those instead. I've also never actually seen a firmware update for my NIC show up so I wonder how they envision that happening. Even if that's the case, you'd then still need to update all hosts, which to me seems far from trivial.
We had a strange case recently...some of our remote staff were unable to connect to our NY VPN from SC. After tracing we found their ISP started using IPV6. Anyways, after we made changes...within a few hours the isp went back to IPv4.
Edit - 19 years to switch is a long time...old as the modern internet. Don't fix it if it ain't broken :)
[0] https://tools.ietf.org/html/draft-omar-si-00
But yeah, if it's this easy to submit drafts to IETF, how come they haven't drowned in spam already?
Also, interesting snippet near the end of that draft: "Each satellite is connected to an earth station which is connected to the Internet core network on earth." He thinks there's a single "Internet core network" (http://tvtropes.org/pmwiki/pmwiki.php/Main/InternetIncorpora...)? No wonder he thinks it would be easy to forklift upgrade the whole Internet to his new protocol...
Version numbers are great!
For what it's worth, in IPv4 time there were some experiments with a new IP variant, those got the version 5. You won't find these anywhere in today's networks, but just to be sure, the next official version got number 6.
The opposite is what we see in some programs and libraries: First, they publish version 1.2.2. Then version 1.2.3. But ooops, 1.2.3 had an issue. Well, let's just release a new tarball and label it 1.2.3 as well. Hopefully nobody noticed this. How big are the chances that somebody downloaded the broken package during the past 2 hours? (I guess using another number for the fixed release, such as 1.2.4, would have been too expensive. Or so.)
wow.
They have an even crazier feature that rewrites IPv6 source addresses as random but unique IPv4 addresses for software that can't deal with that: https://blog.cloudflare.com/eliminating-the-last-reasons-to-...
Clearly the IPv6 space doesn't compress 1-1 into the IPv4 space but this gives you way to work with the top 64 bits of the IPv6 address and then feed it into your anti-abuse system. If your abuse system works probabilistically then this isn't too problematic as this becomes just another signal. And IPv4-based systems already deal with multiple people behind the same IP because of NAT.
The feature isn't nuts, but the rationale seems so.
This doesn't look good.
Link to said protocol with pretty pictures
Aren't hosts expected to choose the highest protocol number they understand? So basically this forever kills (protocol) ipv6 and replaces it with ipv6+ipv4, which is never going to fly (because the "underlying" ipv4 is sunsetting and hopefully gone within a decade)...
I am not a fan of using hardware/mac addresses in ip addresses, in my opinion its a big security/privacy issue. Tracking, hardware details leaking etc.
And somehow i think ipv10 will make the migration for some parties even less of a priority or less urge to 'finish' it. I think if they really want to 'promote' and accelerate IPv6 rollout... Facebook and Instagram should have ipv6 days only. E.g. one day in the week or month, you can only connect with facebook/instagram over ipv6; then you'll see how fast endusers will want to be on ipv6 (and once all endusers are dual stacked.. parties can slowly start disabling ipv4 all together). And then i assume the ipv4 only parties will make a bit of a hurry getting their ipv6 in order.
The IPv6 address space covers the IPv4 address space already: https://en.wikipedia.org/wiki/IPv6_address#Representation
> During the transition of the Internet from IPv4 to IPv6, it is typical to operate in a mixed addressing environment. For such use cases, a special notation has been introduced, which expresses IPv4-mapped and IPv4-compatible IPv6 addresses by writing the least-significant 32 bits of an address in the familiar IPv4 dot-decimal notation, whereas all preceding ones are written in IPv6 format. For example, the IPv4-mapped IPv6 address ::ffff:c000:0280 is written as ::ffff:192.0.2.128, thus expressing clearly the original IPv4 address that was mapped to IPv6.
That needs some sort of gateway to work, but I'm assuming that that is the kind of thing your ISP would do for you.
And if you have to convert each IPv4 only host to an IPv10 host to use it, why not convert it to dual stack IPv4/IPv6 instead?
https://aws.amazon.com/blogs/aws/aws-ipv6-update-global-supp...
The IETF barking out other suggestions is just a distraction.
It's not going to be seriously considered (it doesn't make sense anyway - upgrading to this protocol would be the same effort as upgrading to IPv6 - it's entirely pointless).
The tricky part is router support - BT's own equipment supports it for the most part (Only the Smart Hub and Home Hub 5), but third party routers can be difficult - TPLink still only support /64 prefixes on their current firmware, and their firewall doesn't work properly when using their beta firmware that supports /56 prefixes.
So - the infrastructure is there, but support is variable.
Partly - FTTC is run over BT's network all the way through to 27 regional POPs where it is passed over to the providers network, or they can opt to use the BT network instead.
Most big ISPs run IPv6, and many provide IPv6 to their end customers. In the US Google see 35% of connections coming in to them over IPv6.
But convincing the average small-medium enterprise to enable it on their routers (which isn't automatic as is the case with home connections,) is proving difficult.
We're setting up a new SQL Server cluster, we literally disabled IPv6 in Windows because "we don't use it" - meanwhile I have 6 separate /24's assigned to my team that are a pain in the butt to manage just to ensure I don't run out of addresses. My life would be so much easier if I just had a v6 /64 for dev/test and another /64 for staging and production.
One area where I am keen to see IPv6 spreading is IoT. I don't know if we can ever secure those things, but it will certainly make scanning the IP address space for vulnerable devices impractical.
just use the prefix for reputation. You can assume that each user will have received a /48. Yes. There are some ISPs out there handing out /64's or even a /128, so it might be somewhat too broad, but blacklisting a the whole /48 and then white-listing on (rare) demand is probably the way to go.
Google/Microsoft do this.
Some of his recent efforts:
Satellite Internet [0] (kudos whatidonteven) - I don't think he thought this one through. What is wrong with the current approach? Should we really erect wires in outer space?
He is currently kind of harassing the IETF via mailing lists about IPv10, threatening "If the ideas explained on these drafts will be used, discussed or published by the ietf, legal actions will be taken." [1] - not really how the IETF works.
The version number as "ingenious" 4+6 is annoying, IMO. That's not how version numbers work?
His drawing on his his very own routing protocol - KRP - are also something [2]. Although the quality of his drawings has nothing to do with his ideas per se, it seems he rushed it together in an afternoon.
I don't want to say that he is overestimating his own intelligence, rather that he is underestimating the efforts, hard work and intelligence of everyone else working in this field mostly professionally. His proposals can not easily be judged, because they dismiss almost everything that others have done previously. Why should so many smart people have missed these (obvious/simple) solutions? We are where we are for a reason. You need a good chain of arguments to "dismiss" the current state of the art.
[0] https://tools.ietf.org/html/draft-omar-si-00
[1] http://ietf.10.n7.nabble.com/RE-IPv10-KRP-and-RRP-IDs-Remova...
[2] http://khaledroutingprotocol.blogspot.co.at/
He seems to actually be completly unaware that satellite internet exists at all... (Judging from the second and third points of the introduction).
Who knows what's going on though - maybe he's just young and inexperienced? This is exactly the kind of thing I might have done as a 13 year old if I had stumbled on the IETF...
Do we really need IPv10?
Lots of crazy things get submitted, and never looked at again. In order for drafts to stay alive they need to be updated with comments every 6 months. Sometimes they lead to things, and sometimes they don't. Usually some IETF working group has to be interested for a draft to go from a draft to an actual RFC.
You can see the status of this draft here: https://datatracker.ietf.org/submit/status/89166/
You can find a list of current drafts here: https://www.ietf.org/download/id-abstract.txt
Given the lack of comments on the draft, and the fact its not actually attached to an IETF working group, its fairly safe to say that this isn't actually going to become a real protocol anytime soon.
https://datatracker.ietf.org/doc/draft-omar-ipv10/
https://www.rfc-editor.org/rfc/rfc1475.txt