Redploying most of 127/8 as unicast public

Joe Maimon jmaimon at jmaimon.com
Fri Nov 19 18:50:44 UTC 2021



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

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


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

Best,

Joe



More information about the NANOG mailing list