Diminishing returns, or The selling of deck chairs on sinking ocean liners.  - Page 1
Forum section: electronics / general

author: mansaxel
author_rank: Super Contributor
timestamp: November 19, 2021, 08:51:24 am
content: The attempts of people to extend the pain are reaching silly levels:https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.htmlTo 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.

author: ejeffrey
author_rank: Super Contributor
timestamp: December 28, 2021, 03:35:00 am
content: 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.

author: mansaxel
author_rank: Super Contributor
timestamp: December 28, 2021, 09:12:54 am
content: Quote from: ejeffrey on December 28, 2021, 03:35:00 amThis 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:Don't like changeSuffer from second-system effect and think there are things not done right in the new protocol and want just one more featureHave financial stakes in selling v4 spaceDon't understand the concept of a network where there are no middle boxes that interfere, probably because they've never been exposed to one.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.

author: golden_labels
author_rank: Super Contributor
timestamp: December 29, 2021, 02:13:31 am
content: 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 becauseIlluminatihave 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.

author: mansaxel
author_rank: Super Contributor
timestamp: December 29, 2021, 11:03:32 am
content: Quote from: golden_labels on December 29, 2021, 02:13:31 amThe 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.Quote from: golden_labels on December 29, 2021, 02:13:31 amIt 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.

author: golden_labels
author_rank: Super Contributor
timestamp: December 30, 2021, 01:28:02 am
content: 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:I never seen estimation of subnet transfers exceeding ~500k/yr of /24s. Adding 65k of those is(1)a 10% increase.In absolute values 16M is a number that can easily fit needs of companies in multiple developing countries.The range may be used for failover addresses.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.

author: ve7xen
author_rank: Super Contributor
timestamp: December 30, 2021, 02:24:33 am
content: 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.QuoteThis 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.

author: golden_labels
author_rank: Super Contributor
timestamp: December 30, 2021, 03:11:16 am
content: Quote from: ve7xen on December 30, 2021, 02:24:33 amHow can a client not rely on its own behavior if it supports that behavior?Quote from: ve7xen on December 30, 2021, 02:24:33 amLoad balancing for clients that can make use of that.

author: Cerebus
author_rank: Super Contributor
timestamp: December 30, 2021, 03:57:07 am
content: Quote from: mansaxel on November 19, 2021, 08:51:24 amIt'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".

author: ve7xen
author_rank: Super Contributor
timestamp: December 30, 2021, 04:03:06 am
content: Quote from: golden_labels on December 30, 2021, 03:11:16 amHuh? 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.Quote from: ve7xen on December 30, 2021, 02:24:33 amReplying 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.

author: golden_labels
author_rank: Super Contributor
timestamp: December 31, 2021, 05:51:05 am
content: Quote from: ve7xen on December 30, 2021, 04:03:06 amYou 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.

author: ve7xen
author_rank: Super Contributor
timestamp: December 31, 2021, 08:01:12 am
content: Quote from: golden_labels on December 31, 2021, 05:51:05 amClearly 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.

author: mansaxel
author_rank: Super Contributor
timestamp: December 31, 2021, 08:24:28 am
content: Quote from: ve7xen on December 31, 2021, 08:01:12 amAnyone can submit a draft. And it, as Cerebus noted, will expire if there's no traction.