Seriously? #16
Comments
|
There are 4 drafts. 240/4 has been working for about a decade, 0/8, about 4 years, zeroth, most of the time. Of all the drafts, I am sad that 127/8 caught the most attention. |
|
it will require collaboration to move this work forward. It's important to identify what will break and at least attempt to fix it. |
|
Well, the proposal broke into the news over at NANOG... So @schoen, @loganaden, and @dtaht will get a lot of feedback It's also, as Dave mentioned, disappointing that 127/8 is getting all the energy when 240/4, and a few other spaces are also in play. Enjoy! https://mailman.nanog.org/pipermail/nanog/2021-November/216413.html |
|
IMHO, for now, it would be better to leave the 127/8 chaos behind and just be focused on making the 240/4 block a de facto best practice. |
|
No - the best would be to stop this ridiculous "Unicast Extension Project" and actually learn IPv6... |
|
Something definitely should be done with large block originally unicast IP's used by old companies. I personally worked at some point in the company where /8 was used as private not routable to the internet network. But I agree with Chris - changing the behaviour of networks that were not unicast will bring more harm to Internet infrastructure. |
|
I can tell you why the "bug reporter" thinks that you are "mad": Should this extension be introduced, the adoption would probably have the same speed than the IPv6 adoption: The reasons why a server operator or internet access provider would not support 127/8 are exactly the same reasons why he does not support IPv6. So why should he support 127/8 or 240/4 before he supports IPv6? And operators already supporting IPv6 will definitely not see any reason why they should spend any effort to support 127/8 or 240/4. The internet will be IPv6-only before he will start thinking about supporting 127/8. So your proposal would only make the addresses globally-routable on the paper but in reality they would be more or less unusable because most nodes in the internet would detect them as "invalid". And if you argue: "We can force the operators to accept address range 240/4", then I ask you: "Why not forcing the operators to accept address range 2000::/3?" The effort is the same and the free addresses gained are much more. If you considered this before starting the project, you would have saved a lot of time by not starting the project. |
|
Pretty lot of small ISP's run on old outdated equipment which hasn't got updated for the last 10-15 years. Cisco, Juniper, HP etc won't put any effort into updating those devices. |
|
On Thu, 25 Nov 2021, Dmytro Prokhorenkov wrote:
Pretty lot of small ISP's run on old outdated equipment which hasn't got updated for the last 10-15 years. Cisco, Juniper, HP etc won't put any effort
into updating those devices.
Of course, this was the argument 10-15 years ago too. And if it had been
done then, it would be in much better shape now. So that's only a reason
to do it now, and maybe have something for emergencies 10 years from
now.
It might end up being useless to do, but if not than at least we have
something that might be usuable in the far future. Currently, it is
just wasted with no other plans to clean up the wasted space.
|
|
The only "waste" is the energy you put into a dead horse (IPv4) instead of finally getting that bum up and learning the next-gen protocol (IPv6) where you have a GAZILLION of Addresses without breaking the Internet... |
I'm not sure but I think the "unicast extensions" are based on a wrong assumption: The assumption that there is a high demand for IPv4 addresses. However, the truth is that there is no demand for IPv4 addresses, but there is a demand for addresses that can be used to communicate with most computers in the internet. (And IPv6 addresses do not satisfy this condition today.) And this demand can be satisfied in two different ways:
I doubt that the effort for the first approach (make all computers capable of the new address range) is significantly lower than the second one (make all computers IPv6-capable). However, the 600 million IPv4 addresses gained by the first approach will be gone in a few years: 120 million addresses will not be enough to get rid of CGNAT in the RIPE NCC region! (Assuming that each of the 5 RIRs gets 1/5 of the new addresses.) "Unicast extensions" would only be a temporary solution, not a permanent one. And of course there may be hidden problems: Do you really know that there is no program that ("illegally") performs multicast using one of the "reserved" multicast addresses? So why spend time and money for the first solution if you can have the second solution for the same effort solving the problem permanently? |
|
So there is both no demand for ipv4 and there is a demand for 600M addresses in a few years ?
Demand is huge - the three main clouds are buying all they can.
Sent using a virtual keyboard on a phone
… On Nov 25, 2021, at 16:18, MDJRosenau ***@***.***> wrote:
Of course, this was the argument 10-15 years ago too. And if it had been done then, it would be in much better shape now.
I'm not sure but I think the "unicast extensions" are based on a wrong assumption:
The assumption that there is a high demand for IPv4 addresses.
However, the truth is that there is no demand for IPv4 addresses but there is a demand for addresses that can be used to communicate with most computers in the internet.
And this demand can be satisfied in two different ways:
Ensure that "additional" IPv4 addresses (e.g. 240/4) are supported by nearly all computers (routers, servers, ISPs, clients) in the internet and give these addresses to people requesting for them.
Ensure that IPv6 is supported by nearly all computers in the internet and give IPv6 addresses to these people.
I doubt that the effort for the first approach (make all computers capable of the new address range) is significantly lower than the second one (make all computers IPv6-capable).
However, the 600 million IPv4 addresses gained by the first approach will be gone in a few years: 120 million addresses will not be enough to get rid of CGNAT in the RIPE NCC region! (Assuming that each of the 5 RIRs gets 1/5 of the new addresses.)
"Unicast extensions" would only be a temporary solution, not a permanent one.
And of course there may be hidden problems: Do you really know that there is no program that ("illegally") performs multicast using one of the "reserved" multicast addresses?
So why spend time and money for the first solution if you can have the second solution for the same effort solving the problem permanently?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
Just because some greedy cloud providers buy everything to literally milk the lazy customers (again, because they simply refuse to learn IPv6 or invest in a new software), it doesn't mean that it should be done... IPv6 is better in terms of scaling, security, and flexibility (unlike v4, you can extend v6 with additional headers) which ultimately makes it the future protocol. There's literally no reason to "patch" IPv4 Systems once again to do some features (but in a wrong way) just to emulate things, that other protocols can do WAY better and way more future proof. |
You did not understand what I have written: The cloud provider is mainly interested in having addresses that can be reached from 99% of all clients (e.g. Web Browsers) in the internet. However, neither IPv6 addresses nor addresses from the "unicast extension" ranges satisfy this condition. This means: The cloud operator is not interested in IPv4 addresses in general but he is only interested in IPv4 addresses from the ranges that are already publically routable. You have two possibilities to change this:
I see no reason why the effort for the first possibility should be lower. And while the larger number of addresses is the main advantage of the second possibility, I see absolutely no advantage of the first one. |
|
Sent using a virtual keyboard on a phone
On Nov 25, 2021, at 17:16, MDJRosenau ***@***.***> wrote:
So there is both no demand for ipv4 and there is a demand for 600M addresses in a few years ?
Demand is huge - the three main clouds are buying all they can.
You did not understand what I have written:
The cloud provider is mainly interested in having addresses that can be reached from 99% of all clients (e.g. Web Browsers) in the internet.
Everyone is interested in that.
However, neither IPv6 addresses nor addresses from the "unicast extension" ranges satisfy this condition.
They and others can sit on it for 10 years. The internet won’t be v6only by then.
And while the larger number of addresses is the main advantage of the second possibility, I see absolutely no advantage of the first one.
And like “640kb is enough for everyone”, if you don’t like or need it, that is fine. Just don’t block others who disagree with you.
It’s not your time or money.
|
|
On Nov 25, 2021, at 17:12, Christian Scholz ***@***.***> wrote:
Just because some greedy cloud providers buy everything to literally milk the lazy customers (again, because they simply refuse to learn IPv6 or invest in a new software), it doesn't mean that it should be done...
The market seems to speak yes.
IPv6 is better in terms of scaling, security, and flexibility (unlike v4, you can extend v6 with additional headers) which ultimately makes it the future protocol.
Extension headers are already dead:
RFC 7872, “Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World” highlights IPv6 Extension Headers are effectively unusable since internet providers are dropping IPv6 fragment and failing to support Extension Headers.
So, your v6 extension headers might also need 10 years to get clean. Shall we try to start now with cleaning or have this same discussion ten years from now. It’s the exact analogy to us having rejecting doing this for v4 ten years ago.
There's literally no reason to "patch" IPv4 Systems once again to do some features (but in a wrong way) just to emulate things, that other protocols can do WAY better and way more future proof
Well, RFC 7872 disagrees with you.
Paul
|
|
In fact: Yes. |
|
FUD again (and again). When it comes to IPv4 extensions, being rational becomes a virtue, if not a baseline. |
I already wrote that there is a need for much more than 600M addresses: If we introduced the "unicast extensions" now, the 600M addresses would be allocated within a few years. In 10 years, we would not "sit on addresses" but there would be an address shortage again.
I have already written this multiple times: I know a lot of reasons why ISPs and server operators don't support IPv6. However, I don't know a single reason that does not also apply to the "unicast extensions". ISPs and server operators would introduce the "unicast extensions" with the same speed as they introduce IPv6; and the introduction of IPv6 is 11 years ahead: From the point in time when 50% of all clients can reach an IPv6-only server, it will take another 11 years until 50% of all clients And from the point in time when 95% of all computers support IPv6, first ISPs will think about throwing away their CGNATs (to save money) because most customers would accept IPv6-only, so 11 years later many clients won't support IPv4 at all! |
You have to distinguish between extensions that can be ignored by the routers and extensions that must be observed by all nodes in the internet: If you propose some IPv4 extension that does not require any change in the routers (such as a new IPv4 header option), everybody will tell you: "Why not?" However, this extension will require an update of all routers, servers and clients in the internet; and devices that handle TCP/IP in silicon must be replaced. This is exactly the same effort as switching the complete internet from IPv4 to IPv6-only (not Dual-Stack but IPv6-only)! And I see absolutely no reason why an ISP or a server operator that refuses to introduce IPv6 would not refuse to introduce the "unicast extensions". If you are thinking "rationally", you have to consider if this effort really makes sense although the 600 million addresses would probably not solve the address shortage permanently, while you can have about 1100 billion (1.1 trillion) free address ranges (not: addresses) for exactly the same effort! If you are thinking "rationally", the answer will be: "Definitely not." |
And you think they will support this effort to enable forwarding IPs that are often burned into ASICs and/or hard-coded as martian addresses? |
|
Hi folks, I'm not positive whether this issue is the best place for general discussions of the merits of this project, but there should clearly be some place where people can have that discussion. Several commenters have mentioned the idea that we should do IPv6 instead, or that we should apply our efforts to IPv6 instead, or that there's no reason to expect these proposals to work before IPv6 does. Those are also common things that we've heard in feedback elsewhere. I've tried to address this elsewhere too, but I'll give it a quick try here: I don't view this project as proposing a reason for anyone to refrain from supporting or implementing IPv6. I think the most likely beneficiaries are dual-stack hosting at hosting services. IPv4 addresses have in some cases become a significant, noticeable cost when acquiring hosting services. There is obviously a good reason even for people who are extremely enthusiastic (or optimistic) about IPv6 to continue to want dual-stack support for their sites, which is that without IPv4, a major fraction of the Internet will not be able to access those sites. All of the major Internet companies and brands that fully and properly support IPv6 also continue to make their services available on IPv4 because that's extremely important for their business. If they said that they were going to "support the IPv6 transition" by completely dropping v4 support on their sites, that would be a terrible thing for their accessibility by end users. Speaking for myself, I do not want to encourage or to be seen as encouraging anyone to deploy any new Internet service (residential or hosting) without IPv6 support. However, I don't see IPv4 scarcity as a good thing. The projections that we've seen anticipate IPv4 and IPv6 coexisting for a long time in the future. People may find that regrettable, in the sense that maybe if we had had a more effective IPv6 transition strategy we would be much further along on v6 adoption and v4 would not continue to be as important as it is. Nonetheless, we think it's credible that v4 will continue to be important long enough into the future that the changes we're proposing will likely be relevant and useful at some point. Meanwhile, at the current stage the changes we propose require operating system updates in operating systems that all already support IPv6 correctly and completely out of the box. There is nothing involved in that work that involves postponing or avoiding IPv6 implementation in order to "instead" work on IPv4 unicast extensions. We have patches proposed, and in some cases merged, for operating systems like Linux and FreeBSD, which already support IPv6 completely and on which people use IPv6 reliably every day. The operational part for ISP behavior is more subtle; as a few of the most recent comments have pointed out, if our proposed changes require operators to take some specific action (like replacing or reconfiguring devices), we may not have good reason for optimism that operators that have neglected to take action operationally for IPv6 support will do so for IPv4 addressing extensions, or at least not any time soon. But if we don't start fixing the remaining operating systems, we don't have any chance of getting to that point at all. If we do, we will have an opportunity to assess empirically what these addresses are or aren't good for, and then decide how to use them on that basis. If anyone can find a device whose OS does not support IPv6 fully, and which is still being supported by someone, I will totally endorse having its vendor prioritize every necessary fix to change that over all of our proposals. That's not the case for current devices I've seen: typically, they work great if you connect them to a network with IPv6 support. Their vendors should in no way need to be distracted from IPv6 support by making small maintenance changes to their IPv4 stacks. |
|
I would also especially encourage people who are worried about the difficulties of updating middleboxes and routers to take a look at our lowest address draft and see if they could at least support that one. This draft changes only the semantics of addressing for a local network segment and does not require any behavior changes for distant (non-locally-attached) routers, which have already been implicitly and sometimes explicitly expected to support these addresses under existing standards for decades. We have also already gotten the behavior we specify implemented in Linux and FreeBSD, meaning that if you are a hosting provider, you could get one additional IPv4 address per segment with Linux or FreeBSD servers behind a router, just by the further step of updating your router. |
First of all: Unfortunately, there seems to be no "discussion" page for GitHub projects. Second: If you published some program - such as a text editor - here on GitHub and it turns out that the program only works on 9% of all computers supposedly fulfilling the system requirements, this would not be "discussion" but a real "issue". According to Wikipedia, 91% of all desktop computers use closed-source operating systems. So only 9% of the computers can be patched to use the 224/4 range for unicast. And we are not talking about the routers operated by the ISPs, yet. And if the reporter of the issue sees a reason why the text editor will not work on the other 91% of the computers, it is good practice to write that in the issue description. By comparing difficulties, effort and benefit of your extensions with those of IPv6, I wanted to show why I think that most ISPs will never route an address inside the range 224/4. And I think that the IETF was thinking similarly. You might say: "But a good issue report should contain some proposal how the text editor must be changed to run on 99% instead of 9% of all computers." Once again, looking at IPv6 shows the main requirement that must be fulfilled by your extensions: You have to change the "unicast extensions" in a way that they work without any change at the ISP side. This means: If the ISPs' routers don't support routing 224/4, the "unicast extensions" must not assume that the ISPs will change their routers but the "unicast extensions" have to deal with that. I'm sorry if that did not come out that clearly in my previous comments.
Nobody here is "optimistic about IPv6" - but we are less optimistic about "unicast extensions": The routers at many ISPs detect address ranges 224/3 and 127/8 as as "invalid" in silicon (so no software update is possible). So "a major fraction of the Internet will not be able to access those sites" either. ... and there are much more clients being able to reach an IPv6-only server than clients being able to reach 229.1.2.3!
You didn't understand that the "unicast extensions" would cause exactly the same problem: As long as the ISPs' routers don't route 127/8 nor 224/3 (and this might mean: forever), they would have to use a second IPv4 address (from a "traditional" address range) if their server had a "unicast extension" address. But why use a "unicast extension" address if the server has a "traditional" IPv4 address anyway? This makes no sense. |
That seems to be the crux of this issue. (By the way, although we're interested in multicast addresses—in the 224/4 range—we haven't written a draft to redesignate them. This is complicated because, unlike 240/4, there have been official allocations in 224/4, and they're not all contiguous, either. I'll assume you meant 240/4 and the example should then be, say, 249.1.2.3.) My impression is that it's currently true that more clients can reach an IPv6-only server than can reach 249.1.2.3. However, if the Fuller/Lear/Meyer draft had been adopted in 2008, this might not have been the case today. If our draft is adopted now, this might also not be the case in 2034. As someone said recently (I think on the NANOG list), it would be great if that turns out not to be the case because IPv6 becomes so completely ubiquitous that nobody wants IPv4 addresses anymore in 2034 or 2034. However, that isn't the trend that we're seeing. Even if more clients can reach an IPv6-only server than 249.1.2.3 in 2034, it might still be useful to have 249.1.2.3 available then, because it's conceivable that significantly more clients will be able to reach a dual-stack server with 249.1.2.3 + an IPv6 address in 2034, compared to those that can reach an IPv6-only server at that time. That's because the obstacles to being able to reach 249.1.2.3 and being able to reach an IPv6-only server are not the same obstacles. (I'd agree that they're correlated in some cases, but they're not the same.) |
Maybe. However, I just looked how much address blocks were requested by the APNIC before 2011: They had a need of more than 16 /8 blocks before the ARIN had a need of a single one. Most of the "new" addresses would have been given to Asia and virtually none to the USA. And as far as I know, the cloud operators are US companies.
If the server is only a few "hops" away - maybe. However, if the server is 15 "hops" away, there is a very high chance that one of the 15 routers drops the packet - even if both the client and the server support 240/4. |
I'm not sure that's the most relevant number to use. We can then only patch about 9% of desktops ourselves, but if our proposals are adopted elsewhere, the vendors of those devices will be more willing to patch them. For example, we heard that Microsoft is reluctant to make these changes in advance of their standardization at IETF. Meanwhile, some proprietary systems like Apple's already support 240/4 as unicast; there's not a direct guarantee that open source systems will adopt the changes we propose, or that proprietary ones won't. We do actually have a further patch for Darwin which would make Apple devices support more historically reserved addresses. It's clear that Apple doesn't have a straightforward way for us to officially propose this to become part of the upstream Darwin source and to get an official answer about that proposal, but we can still try to pursue it unofficially with kernel developers at Apple. |
|
A recent APNIC report on IPv4 and IPv6 addressing in the last year mentioned that the Class E address block was (irresponsibly) marked as Reserved for Future Use, and 'if ever there was a “future” for IPv4 then it is now.' But unfortunately these proposals lapsed over the past 15 years. If the problem "has eluded a generally workable solution", then this might provide a solution to work it out. Geoff Huston, 19 Jan 2022 |
I doubt about the word "now": As I have already written, I see no reason why the time needed for the introduction of "class E" would be faster than the introduction of IPv6 - even if IPv6 did not exist and therefore there was no alternative to the introduction of "class E". If "class E" was made publicly routable tomorrow, it would take until 2030 until a client with a "class E" address can reach the same number of servers as an IPv6-only client today. And it would take until 2030 until a server with a "class E" address can be reached by the same number of clients as an IPv6-only server today. So even if "class E" became routable tomorrow, the future of IPv4 was not "now" but in 2030. ... and the existence of IPv6 would even slow down the introduction of "class E": Router operators and ISPs who just bought new devices supporting IPv6 will not see any reason why they should spend any money for buying new devices (supporting "class E") again. |
Are you really this mad or did you just smoke the wrong stuff?
You know that would break the Internet as we know it right?
The text was updated successfully, but these errors were encountered: