EEVblog Electronics Community Forum

Products => Computers => Networking & Wireless => Topic started by: mansaxel on November 19, 2021, 08:51:24 am

Title: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: mansaxel on November 19, 2021, 08:51:24 am
The attempts of people to extend the pain are reaching silly levels:

https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html (https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html)

To enforce what amounts to a IP routing conventions flag day to gain one /8 less one /16 must be the very definition of "diminishing returns".  Of course; if you hold some v4 space you'll be tempted to extend the commercial life of it before the price drops; which it will when v6 adaptation is large enough.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: ejeffrey on December 28, 2021, 03:35:00 am
It doesn't require a flag day as that expression is normally used.  A flag day is when you are making a mutually incompatible change that everyone has to do at once or lose direct compatibility.

If this draft is approved, routers and network stacks could be updated and any threshold could be set for adoption before assigning any of those addresses.

I still don't expect it to be particularly successful given the difficulty of releasing and assigning the 240.0.0.0/4 former class E address block which is much larger and less used.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: mansaxel on December 28, 2021, 09:12:54 am
It doesn't require a flag day as that expression is normally used.  A flag day is when you are making a mutually incompatible change that everyone has to do at once or lose direct compatibility.

If this draft is approved, routers and network stacks could be updated and any threshold could be set for adoption before assigning any of those addresses.

I still don't expect it to be particularly successful given the difficulty of releasing and assigning the 240.0.0.0/4 former class E address block which is much larger and less used.

This borders on hair splitting, agreed, but since people do not update their network gear or their computers, this change is incompatible with the installed base in a way that'll make it impractical.

The Class E proposals suffer from basically the same, but not as ingrained as the loopback net. Also, a /4 is 16 times larger, so more addresses. Still not enough to accommodate the Internet growth. At the time when there actually was /8's to allocate from, the RIRen would go through one in about three months, using a very conservative allocation model. So, with Class E altered to general usage, you're looking at 4 years, tops.

There IS this new protocol, using 128-bit addresses, that shows some promise, and unfortunately a lot of resistance, likely from people who suffer from one or more of:


I'm saying it works, and we (as in "people who actually understand at least something about data communications") should all work to implement it.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: golden_labels on December 29, 2021, 02:13:31 am
What’s the point of inventing conspiracy theories if there exist trivial and obvious explanation? The deployment of IPv6 is slow. For whatever reason, but certainly not because Illuminati have incentive in leasing/selling IPv4 addresses: in the v4-vs-v6 tug-o-war people in power to introdue v6 are on the opposite side of the rope than the supposed “they”.

Currently less than half of internet users have IPv6 connectivity with many areas seeing close to everyone in need of IPv4. Those, who can use IPv6, are not necessarily having ability to have that properly deployed.(1) While operating systems may nowadays support IPv6, much of software has no ability to work with it. On top of that the security and privacy concerns about removal of NATs persist. While NAT is by no means a security feature and should never be introduced as a pseudo-firewall,(2) the sad reality is it does protect uncountable machines whose owners would otherwise expose gaping holes to the internet.

16.7M addresses may not be much, but those are addresses that are lying around unused. The 127.0.0.0/8 range is in practice used only for debugging/experiments with addresses assigned as needed by humans with no reason to prefer e.g. 127.1.0.10 over 127.0.1.10. And even that is rare: to the point I myself know only a few people who ever did that (myself included).
____
(1) For example I am myself stuck with IPv4, because Liberty Global in Poland enforces use of shoddy modem-routers that are either IPv4-only or IPv6 with barely usable IPv4 shim — and I need IPv4 port forwarding.
(2) And even among IT crowd you will find those, who will swear it is equivalent to firewall — never realizing that is at best a conincidence.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: mansaxel on December 29, 2021, 11:03:32 am
What’s the point of inventing conspiracy theories if there exist trivial and obvious explanation?

The deployment of IPv6 is slow. For whatever reason, but certainly not because Illuminati have incentive in leasing/selling IPv4 addresses: in the v4-vs-v6 tug-o-war people in power to introdue v6 are on the opposite side of the rope than the supposed “they”.

Currently less than half of internet users have IPv6 connectivity with many areas seeing close to everyone in need of IPv4. Those, who can use IPv6, are not necessarily having ability to have that properly deployed.(1) While operating systems may nowadays support IPv6, much of software has no ability to work with it. On top of that the security and privacy concerns about removal of NATs persist. While NAT is by no means a security feature and should never be introduced as a pseudo-firewall,(2) the sad reality is it does protect uncountable machines whose owners would otherwise expose gaping holes to the internet.

The biggest problems are bad decisions made a long time ago, in building provisioning systems that are 32-bit only, and not insisting on v6 compat in things you bought. I've required RFC6540 compliance in everything I've bought and specified the last 15 years, and it helps, because I can trivially enable v6 for it all, even if the reality of applications requires me to run dual-stack.

16.7M addresses may not be much, but those are addresses that are lying around unused. The 127.0.0.0/8 range is in practice used only for debugging/experiments with addresses assigned as needed by humans with no reason to prefer e.g. 127.1.0.10 over 127.0.1.10. And even that is rare: to the point I myself know only a few people who ever did that (myself included).
It is still only 3 months consumption at pre-runout rates -- probably less -- and it costs a routing convention soft flag day. It'll take 6 to 10 years before it is usable. 

The fact in the "conspiracy" discussion is that the 127/8 proposals emanate from a relatively small group of people who since they co-authored the drafts and did other propaganda stunts, likely know each other. I suppose they have reasons to see v4 taper off ever so little slower. Their pension plan, of sorts. And no, this is not my idea. It was widely suggested on Nanog-l that this was the case.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: golden_labels on December 30, 2021, 01:28:02 am
I doubt it makes sense to compare that to the previous exhaustion rate. Unless some safeguards are in place, that range will not be assigned in 3 months, but in 3 days. The point is it will increase the number of addresses in circulation, if happens to be successful.

While that new range is hardly significant in relation to the entire address space, putting it in a different context may make it more sane:
Of course it may all fail. But what’s the deal if it does, considering nothing of value is sacrificed? And no, it doesn’t require the entire internet to switch. Yes, it may be needed for average Joe watching cats on YouTube, but in general — no. As long as the client supports round robin, latency is not an issue and no obstacles on the client side exist(2), multiple A records may be offered. If the address can’t be routed, another one will be used.


(1) I have no estimates on total addresses available for leasing/selling, which would be perfect. Calculations based on the transaction volume depend on the period between transactions. If they go above a few years, it will go towards 1–3%, but going the other way it quickly going towards 50%.
(2) If local systems are not updated, the new addresses may be treated as DNS rebinding.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: ve7xen on December 30, 2021, 02:24:33 am
Yeah, this is pretty ridiculous. The friction behind global repurposing of 127/8 is on the same order as moving to IPv6, IMO. There will be a long tail of devices without support (hardcoded handling of 127/8) and systems lacking updates by oblivious administrators (bogon filters) such that any serious player will probably need to avoid it for 10 years or more. Since you're talking about routing these addresses, that also means your long tail includes consumer routers and such like, so most serious users aren't going to want these addresses as there will be some small % of users that haven't touched their home router in a decade that won't be able to talk to you. Then you've got reluctance from many network operators to prolong the suffering, who are likely to provide some opposition to such a change by not accepting those routes intentionally. It's a lot of the same problems as IPv6 adoption faces.

Proposals for repurposing of (at least part of) 224/4 seem a lot more viable to me, client-side issues are much less likely and fixes on the infrastructure side are less likely to suffer the long tail, though I'm pretty firmly in the 'opposed to prolonging the suffering' camp.

Quote
As long as the client supports round robin, latency is not an issue and no obstacles on the client side exist(2), multiple A records may be offered. If the address can’t be routed, another one will be used.

This isn't a client behaviour you can rely on when faced with multiple response records. getaddrinfo (or worse, gethostbyname) just give you the address information, there's no automatic handling of connection failures, and a great many applications will just try the first entry and give up if it fails. If you want to use multiple A records in a resilient fashion, you need application logic to notice this, understand the multiple responses, and probably cache the behaviour. Again, this is a similar problem IPv6 adoption faces, and clients had to be modified to implement 'happy eyeballs' which is still an application-level feature and not generally provided by the low-level network stack for you.

But if you have a 'normal' address to reply, what is the purpose of responding with the 'special' address anyway? It's not doing anything but making your service less resilient, should it be chosen by a client that can't connect to it, even if there were a widespread fallback mechanism in place.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: golden_labels on December 30, 2021, 03:11:16 am
This isn't a client behaviour you can rely on when faced with multiple response records. getaddrinfo (or worse, gethostbyname) just give you the address information, there's no automatic handling of connection failures, and a great many applications will just try the first entry and give up if it fails. If you want to use multiple A records in a resilient fashion, you need application logic to notice this, understand the multiple responses, and probably cache the behaviour
How can a client not rely on its own behavior if it supports that behavior?

But if you have a 'normal' address to reply, what is the purpose of responding with the 'special' address anyway? It's not doing anything but making your service less resilient, should it be chosen by a client that can't connect to it, even if there were a widespread fallback mechanism in place.
Load balancing for clients that can make use of that.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: Cerebus on December 30, 2021, 03:57:07 am
The attempts of people to extend the pain are reaching silly levels:

https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html (https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html)

To enforce what amounts to a IP routing conventions flag day to gain one /8 less one /16 must be the very definition of "diminishing returns".  Of course; if you hold some v4 space you'll be tempted to extend the commercial life of it before the price drops; which it will when v6 adaptation is large enough.

It's a draft that expires mid year. If there is any sanity left in the world it will be allowed to expire.

Should it come to pass, then anyone taking IPv4 address space in 127/8-(127.0/16) will face reachability hell. If 5% of the global Internet is updated to be aware of the new address space I would be surprised, the costs alone dwarf any gains but of course those are costs are "somebody else's problem" in the eyes of the proposers.

Meantime I shall continue to use the IPv6 /48 that is allocated to my London Victorian terraced house, secure in the knowledge that I could connect up a whole IPv4's worth of hosts on it and still have addresses left. My house would have burned down, but I'd still have address space. I've now been using native IPv6 professionally for 20 years or more, and at home for at least 15. I wonder when the dinosaurs are going to come and join me in enjoying effectively limitless address space?

I'm in the band, playing "Nearer my god to thee".
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: ve7xen on December 30, 2021, 04:03:06 am
How can a client not rely on its own behavior if it supports that behavior?

Huh? I don't follow.

If you operate an Internet service, you often have little control over the client, so you need / want to support the lowest common denominator. If you are a service provider procuring address space to sell to hosting customers doing who knows what (which is a major part of address consumption demand, see cloud providers snapping up /8s whenever they become available), you have no control over either side, and you can't just tell customers 'oops sorry...'. Especially when most major user-facing services are doing cloud deployment these days, having some dynamically assigned IPs randomly not work for some clients would be totally unacceptable to the likes of AWS or Azure. Further, you can't use them as an end-user ISP either, for the converse reason - not every web service or whatever they might want to reach will support them, and even if it's a low percentage, now you need to address the long tail, so it's still going to lead to significant support overhead. It all means they're not useful for a large portion of the demand, and even providers that might be able to address the client-side issues some other way would hesitate to take them. This is just one of several reasons 127/8 would be 'less functional' and undesirable on the market than normal IPs for a long time to come.

Load balancing for clients that can make use of that.

Replying with multiple records is a poor-man's load balancer, but this doesn't really help clients and there are other ways to engineer load balancing on the server side anyway. Use DNS load balancing, anycast, or a frontend load balancing machine. There's not much need for this type of load balancing in modern setups. What it does do is introduce a service outage for clients that don't support this fallback mechanism of yours and happen to choose the unreachable server and even if they do support fallback, causes degradation as the clients detect the unreachable server, which could be severe depending on where the failure is (if you have to wait for a timeout, several seconds at least, possibly on every connection attempt). It's not adding much, if any, value to a service that is already operating and has address space in the 'normal' range it could use. For a new service I guess it would be better than nothing, but you're going to go to the trouble of getting a 'real' address instead, just like hardly anyone would buy an IPv6-only AWS instance today if you could, even if it was a little cheaper.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: golden_labels on December 31, 2021, 05:51:05 am
If you operate an Internet service, you often have little control over the client, so you need / want to support the lowest common denominator. (…)
You do realize, I hope, that websites is not the only thing on the internet? Likely not even a very significant part of all the traffic. Until that is rectified, I will avoid responding to the load balancing paragraph, as what you wrote there may arise from wrong assumptions.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: ve7xen on December 31, 2021, 08:01:12 am
If you operate an Internet service, you often have little control over the client, so you need / want to support the lowest common denominator. (…)
You do realize, I hope, that websites is not the only thing on the internet? Likely not even a very significant part of all the traffic. Until that is rectified, I will avoid responding to the load balancing paragraph, as what you wrote there may arise from wrong assumptions.

|O Clearly I do, since that is basically my argument. Browsers are relatively complex and featureful, reimplement most of the OS services from scratch, have a relatively rapid pace of development and deployment of new features...it's the opposite of the kind of thing I'm talking about. It's practically the only significant place where maybe (long shot) you could actually use such addresses in a reasonable amount of time, but most address consumers don't have the luxury of being web-only, which is pretty much my point. Browsers might even do fallback to multiple A records on failure already, similar to happy eyeballs, I don't actually know - but I do know that the average client application doesn't, because it doesn't come for free with the sockets library. My entire point is that the long tail is a problem that will prevent this proposal from ever gaining real traction.

I maintain my position that if you are an address space holder that already has real address space, there is negative value in adding a new semi-functional IP to your DNS reply set. Whatever your goal might be in doing so, there are better ways to achieve the same result in pretty much any case. It has slightly more use if you aren't actually an address holder, but then the people acquiring the addresses would be hosting companies who won't want to deal with the problems surrounding this. If your argument is that the long tail is the place where this is necessary and worth the trouble, it's not a very good argument and certainly not strong enough to support the major effort it would take to actually do it. And on the flipside, if your only argument is the long tail, you run into the serious meatspace issue of convincing the entire internet this needs to be done.

It's kind of hilarious this made it to the draft stage, to be honest, it's an absurd proposal.
Title: Re: Diminishing returns, or The selling of deck chairs on sinking ocean liners.
Post by: mansaxel on December 31, 2021, 08:24:28 am

It's kind of hilarious this made it to the draft stage, to be honest, it's an absurd proposal.

Anyone can submit a draft. And it, as Cerebus noted, will expire if there's no traction.