IPv10(tools.ietf.org)
tools.ietf.org
IPv10
https://tools.ietf.org/html/draft-omar-ipv10-06.html
131 comments
Slight correction, you have provided the link to the submission processing status, here's the link to the draft itself:
https://datatracker.ietf.org/doc/draft-omar-ipv10/
https://datatracker.ietf.org/doc/draft-omar-ipv10/
[deleted]
[deleted]
Excerpt :
- 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.
... 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.
Also from the same author: Satellite Internet [0]
[0] https://tools.ietf.org/html/draft-omar-si-00
[0] https://tools.ietf.org/html/draft-omar-si-00
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"
Crank-o'meter goes to eleven!
But yeah, if it's this easy to submit drafts to IETF, how come they haven't drowned in spam already?
But yeah, if it's this easy to submit drafts to IETF, how come they haven't drowned in spam already?
He has a lot of other proposals as well: http://khaledroutingprotocol.blogspot.ca/2017/03/khaled-rout...
Well, the idea is obviously flawed, but I don't think the author meant geostationary orbits.
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.
What.
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...
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'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.
I might be missing something though.
I might be missing something though.
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.
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.
> 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.
Yes, that's why nobody's doing it.
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.
[deleted]
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 :)
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.
The problem with IPv6 or IPv10 is same. Adoption. IPv10 might reduce friction because of compatibility reasons.
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.
[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/
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/
> What is wrong with the current approach?
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...
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...
In other words: "this entire HN submission is spam".
His address is also interesting:
The Road
6th of October City, Giza
Egypt[deleted]
Well, 6th of October City is a place. (https://goo.gl/maps/z141gu8cMYB2)
Not sure I understand why this is necessary...
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?
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?
Because ipv6 was designed with not much thought to migration and interworking with ipv4
And migrating is all cost no benefit. And the problems ipv6 was intended to solve have long since been addressed better by other means (eg NAT).
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).
Some good not-easy-to-screw-up and default security and privacy features at the IP level would be nice to have in a new IP protocol.
https://twitter.com/The_Road_Series/status/86814034617735577...
This doesn't look good.
This doesn't look good.
Wow, is this some kind of joke? This is the guy who created this new protocol? Hopefully, it's as good as dead now.
Look at his other draft proposals - he seems serious but seems to have no idea what's actually involved in designing or specifying a real protocol...
http://khaledroutingprotocol.blogspot.nl/2017/03/khaled-rout...
Link to said protocol with pretty pictures
Link to said protocol with pretty pictures
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.
Wake me when AWS, Azure or GCP have proper IPv6 support.
How do you define "proper IPv6 support"? AWS certainly has considerable support for IPv6 today:
https://aws.amazon.com/blogs/aws/aws-ipv6-update-global-supp...
https://aws.amazon.com/blogs/aws/aws-ipv6-update-global-supp...
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.
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:
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:
[1]1010110 [1]0001111 [0]1101011
^ last byteYour method is essentially how UTF-8 works. I think the problem is implementing that efficiently in hardware, which is needed for routers.
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.
> What's the drawback if we use something like this? Routing troubles? Speed?
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'.
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'.
This is called a VLQ, btw. Variable Length Qunatity: https://en.m.wikipedia.org/wiki/Variable-length_quantity
something like this was used in MIDI protocol
had to double check the date to see if it's not an April 1st. it isn't.
wow.
wow.
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!)
Shit, i've been overlooked entirely...
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.
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).
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 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.
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.
Don't most areas have local loop unbundling, so you're on your ISP's network rather than BT's?
Sorry, just seen this.
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.
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.
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.
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.
> The first version of the Internet Protocol is IPv4.
Version numbers are great!
Version numbers are great!
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.)
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
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.
That's a horrible idea. What if I can't upgrade to 1.2.4?
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
Protocol names should be 128-bit wide to allow for future expansion in available protocols.
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.
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.
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.
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.
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.
Current recommendation is actually for a /56.
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.
Google/Microsoft do this.
Google/Microsoft do this.
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.
That's... cute. But not breaking anything, so, huh. Not bad.
essentially because of X-Forwarded-For
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-...
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-...
That feature isn't as nuts as you think.
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.
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.
The feature isn't nuts, but the rationale seems so.
How could we 'require a customer to just fix their anti-abuse system'?
Why V10. Because 4+6?
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).
[1] https://www.iana.org/assignments/version-numbers/version-num...
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...
Yes:
"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."
"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."
>From here the name of IPv10 arises, as the IP packet can contain (IPv6 + IPv4 /IPv4 + IPv6) addresses in the same layer 3 packet header.
The ASCII Graphics in RFPs are getting more advanced these days
Some previous HN discussion about this happened within the following comment thread: https://news.ycombinator.com/item?id=14419867
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.
Do we really need IPv10?
Do we really need IPv10?
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.
IPv6 enabled in your tcp/ip stack doesn't create latency. You weren't even using IPv6 - ping is IPv4 by default.
Anyone remember IPv7? Yeah, it was a thing:
https://www.rfc-editor.org/rfc/rfc1475.txt
https://www.rfc-editor.org/rfc/rfc1475.txt
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)...
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)...
few cents from me about this /o\ http://blog.donatas.net/blog/2017/09/10/ipv10/
IPv10 = IPv4 + IPv6?
[deleted]
Why not IPv16 and fix the problem for ever?
[deleted]
IPv27, with 3192-bit addresses, for when you're running TCP/IP on quarks.
Will it fix it? This seems like a scaling issue we're going to have to deal with forever.
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.
Obviously not all of these addresses will be used; in practice we aren’t going to run out any time soon.
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.
Current recommendations is end users of ISP's should get a /56
For reference, 2^128 = 340282366920938463463374607431768211456
or
340,282,366,920,938,463,463,374,607,431,768,211,456
or
340,282,366,920,938,463,463,374,607,431,768,211,456
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.
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.
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.
IPv6 has a 2^128 address pool.
edit: theoretically, we'll only ever use a fraction of that, both by design and because that's a huge number
edit: theoretically, we'll only ever use a fraction of that, both by design and because that's a huge number
Well, because there is no equivalent to CIDR with IPv6, what you really need to focus on is the 2^64 networks available. Still a big number.
And yet I still have /127, /126, /120 and /112 IPv6 subnets running on my network.
Just because the IETF says SLAAC or bust doesn't mean it's true.
Just because the IETF says SLAAC or bust doesn't mean it's true.
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 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.
That's what I meant in my edit :)
> fix the problem forever
Situation: 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/
Situation: 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/
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.
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.
If only we didn't have multiple competing transitional mechanisms defined as standards already.
You're suggesting there are networking standards that compete with IPv4/IPv6? What are those standards?
There's like 4 (?) different IPv4/v6 integration systems. None of which worked the last time I fiddled with some of them.
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.
Win some, lose some. In hindsight it was pretty shoehorned in.
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.