Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG <nanog () nanog org>]

> On Nov 19, 2021, at 10:50 , Joe Maimon <jmaimon () jmaimon com> wrote:
>
>
>
> Owen DeLong wrote:
> > > LLA and ULA and whatever random prefix you may wish to use for loopback, whether in IPv6 or even IPv4 have none of 
> > > these qualities.
> > And if we implement the proposal at hand, which as near as I can tell you are supporting, that changes.
> >
> > Having trouble following your desired outcome here. It seems as if you both want 127.0.0.0/8 to retain it’s unique 
> > properties
> > as deterministically loopback only and also want the benefits of repurposing it as GUA.
> >
> > Have cake, Eat cake, please to pick only one.
>
> Let me clear that up then.
>
> I support serious consideration of the idea. My desired outcome is to see ideas like these either adopted or not but 
> based solely on their own merits and especially in their own protocol context. And that folk who have studied the 
> issue and invested their efforts be taken seriously and not be met with undeserved and might I add, unkind, scorn.
>
> (I havent studied the issue or invested the effort, so you may continue to direct your scorn this way)
>
> Its well past time to stop behaving as if we are a bunch of teenagers on a private BBS.
>
> I like the loopback prefix feature of IPv4.
>
> I can easily concede that its too large, especially in this day and age. And that there is a good chance that 
> significant benefit can come from addressing that before IPv4 becomes obsolete.
>
> I question the lack of dedicated loopback feature in IPv6 and I acknowledge that yes, you can accomplish the same 
> with non loopback prefixes by essentially assigning them to loopback, but point out that that does not make them the 
> same thing.

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.
> 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.

> And I discuss IPv6 loopback simply because of the pushback directed in a non-meritorious fashion from folk who 
> apparently believe simultaneously that IPv6 is superior in every way to IPv4 and that any improvements|changes to 
> IPv4 somehow endanger IPv6 imminent dominance.

I have little concern (if any) of the latter. I believe that IPv6 is mostly equivalent to IPv4 in virtually every way 
and vastly superior in exactly one way… It has enough addresses. (and in all the ways that result from that, i.e. 
potential to restore end to end addressing, elimination of NAPT, etc.). I think that IPv6 also offers some features not 
available in IPv4, the benefits of which we haven’t fully explored or realized (MIP6, DHCP-PD, improved zeroconf, RD, 
etc.). Certainly the IPSEC implementation in IPv6 is quite a bit cleaner than it’s back-ported counterpart on IPv4 
which has become such a nightmare in most implementations that the vast majority of VPNs have migrated to some 
cockamamy HTTPS “SSL VPN” thing.

> > > >  having a prefix
> > > > dedicated to that purpose globally vs. allowing each site that cares to choose their own doesn’t seem like the best
> > > > tradeoff.
> > > >
> > > > Owen
> > > But this is how it is to be done in IPv6, so lets get some lack-of-feature parity going with IPv4.
> > I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.
>
>
> Actually I am (somewhat facetiously) suggesting that IPv4 have non-feature parity with IPv6 by taking away its 
> loopback prefix.

Both have a loopback prefix. IPv4: 127.0.0.0/8 and IPv6: ::1/128

Admittedly, there are a lot more addresses available in the IPv4 loopback prefix, but again, I view that as being 
mostly waste as a result of historical ignorance at the time a decision was being made.

> > IMHO, having additional loopbacks be assigned from either LLA or ULA space (or even GUA, really)
> > where that is needed is a superior choice vs. 127.0.0.0/8.
>
> 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”.
If you mean non-routable addresses deployed on the loopback interface, I think LL works fine for that purpose.
If you mean routable addresses deployed on the loopback interface, I think ULA or GUA works fine for that purpose.
If you mean something else, then I’m still not clear what you’re intent is here.

> > For one thing, the alternative addressing schemes (other than LLA) allow for routing of the
> > addresses off the box even though they are configured on loopback interfaces. There are
> > a number of situations where this can be a useful way to ensure that the addresses remain
> > usable regardless of the up/down state of connectivity on any particular non-loopback
> > interface on the box.
> >
> > It’s one of the reasons, for example, that virtually every IBGP speaking router has a GUA
> > or ULA/1918 loopback address which is routed in the IGP and almost all IBGP sessions
> > are terminated on those loopback interfaces.
> >
> > Owen
> And its the fairly common way of implementing anycast services. But that is not what we are addressing on this thread.
>
> 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.

If I thought it would significantly degrade IPv4, I might be all for it, but I doubt it would even be that useful.

Owen