Redploying most of 127/8 as unicast public

Sun Nov 21 04:04:15 UTC 2021

> On Nov 20, 2021, at 19:11 , Joe Maimon <jmaimon at jmaimon.com> wrote:
> 
> 
> 
> Owen DeLong wrote:
>> 
>> I guess I don’t see the need/benefit for a dedicated loopback prefix in excess of one address. I’m not necessary inherently opposed to designating one (which would be all that is required for IPv6 to have one, no software updates would be necessary), but I’d need some additional convincing of its utility to support such a notion.
> 
> Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 parity would require the same, so merely designating a prefix would only be the beginning.
> 
> There may not be a need. But there is clearly some benefit.

Which is? You still haven’t answered that question.

>>> I can understand that sometimes you may explicitly not want to use the loopback prefix for loopback applications. In fact many times. However, you dont really have much options when it comes to IPv6
>> I have not encountered a device where I could not assign additional prefixes to a loopback interface in IPv6, so I’m having trouble understanding your meaning here.
> 
> In IPv6 if you want a loopback prefix you have to pick one yourself or determine which one the system has chosen on its own. Because there is no dedicated loopback prefix other than ::1/128

Well, technically, fe80::/10 is also present and predictable on every loopback interface. It does come with the additional baggage of having to specify a scope id when referencing it, but that’s pretty minor.

>>> Anyone who wants to assign routable IPv4 to loopback is free to do so and there are plenty of IPv4 ranges to choose from.
>>> 
>>> The converse is not true in IPv6.
>> I guess that depends on what you mean by “converse”.
> 
> I mean that in IPv6 you must assign an otherwise non-loopback prefix if you want one.

Again, not really…fe80::/10 is right there waiting for you.

>> If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.
> 
> It works, but it is non deterministic and system dependent.

Nope… It’s every bit as deterministic as 127.0.0.0/8.

If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you try it on something other than linux, it probably doesn’t work.
That’s also true of 127.*.*.*.

>> If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.
> 
> And IPv4 has that too.

Right, so we have parity or better in the case of IPv6.

In IPv4, you have 16.7 Million addresses reserved for this purpose. In IPv6, it’s considerably more if you count all of fe80::/10.

(somewhere north of 340,000,000,000,000,000,000,000,000,000,000,000 addresses IIRC)

You can also get away with IPv6 loopback behavior on a dual stack system by using ::ffff:7fxx:xxxx as well.

>>> I actually think that IPv6 evangelicals should welcome any all ideas like this, especially if they believe it will further degrade the overall state of IPv4, because that should only serve as stronger impetus for IPv6 deployment. That mode of thought has been commonly expressed here and other places before.
>> I don’t think the current proposals being discussed will improve or degrade IPv4. I think they will distract implementors that choose to implement them from useful work for a while and end in neither benefit nor detriment beyond the detriment that comes from wasting effort.
> 
> There seems to be some weird mental representation of how standards affect the real world. Standards do not demand or direct or control in any way what individuals do based upon their own assessment of their needs, available resources and resulting benefits.

Maybe, maybe not. They certainly influence some of those choices in a variety of ways.

> You are neither responsible or in control of how people choose to expend their implementing resources. Nor should you.

Agreed. But I have every right to express my desires and displeasures with widespread plans to encourage what I perceive as misuse and that’s exactly what’s happening here.

My right to attempt to discourage it by opposing proposed standards is exactly equal to your right to encourage it by promoting them.

> What standards do is increase the potential benefits of conforming to certain behavior.

No, what standards do is encourage people to implement things in compatible ways in hopes that doing so is beneficial. A proposed standard that doesn’t provide an apparent clear benefit, therefore doesn’t merit adoption.

> So what you are really saying is that standardizing something that others may then choose to recognize as a worthwhile expenditure of their resources is something you would like to prevent on the assumption that those efforts would have otherwise gone into IPv6 advancement.

I’m really saying what I said. That IMHO, there’s no benefit to the internet overall if this proposed change is accepted and/or implemented and I see no benefit to standardizing it. As such, I remain opposed to doing so.

Whether or not the effort that would be wasted implementing it would go to IPv6 or to some other more useful pursuit is not a concern I factor into my opinion in this case.

> You dont have the immediate moral high ground on that one.

I’m really not concerned about where your misinterpretations of my statements land me in your opinion of the moral high ground, but thanks for playing.

> You dont have the long term moral high ground on that one because such thinking isnt new and we know its wishful at best.

Same response.

> You dont have the logical high ground on that one because you are assuming facts not in evidence, namely that

Same response.

> - Resources are being feverishly expended deploying IPv6 (as if)

Some are. More certainly would be beneficial.

> - Those same resources will be the ones redirected to implement ideas such as these

I have made no such assumption. I have made the assumption that since this is a complete waste of effort, whatever else those resources could be used for would likely be more useful.
I believe there to be sufficient evidence to support that assumption, though I understand you don’t agree with the assertion it is based upon.

> - That those efforts are in anyways comparable in scope to work being done on IPv6 (which is supposed to be done already)

I’ve made no such assumption, nor do I consider the relative scope to be in any way relevant.

> - That any such diversion of activity will actually have any real world affect on the state of IPv6

Again, have not made any such assumption here, either. It’s not relevant. The only thing I consider relevant is that any resources expended on a complete waste of time could be better
expended elsewhere.

>> If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.
>> 
>> Owen
>> 
> 
> Reclaiming 127/8 while assigning a /64 for loopback in IPv6 would create a clear (but narrow) case where IPv6 would be superior to IPv4, irrelevant of overall network state.

Why do you need another /64 when you already have a /10?

> Objectors to the proposal based upon their real world use of far larger than v4 /16 for loopback applications could implement on IPv6 with even more space, and in the exact same addressing context.

They can already effectively do that today.

> Which GUA and LL are not, no matter how readily available and easily assignable and otherwise equivalent they are in every way but the one. They are not loopback designated by standard (and system implementation).

And this matters why?

Owen