Mailing List Archive

> On Nov 17, 2021, at 19:40 , Jerry Cloe <jerry@jtcloe.net> wrote:
>
>
>
> Subject: Redploying most of 127/8 as unicast public
> To: nanog <nanog@nanog.org <mailto:nanog@nanog.org>>;
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html <https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html>
>
> I can think of about a dozen /8's that would be better to use. (Hint, they all have DOD in the name.) They haven't been in routing tables for decades and there wouldn't be hardly any technical issues (like there would be with 127/8). The only drawback is I've seen a lot of organizations treat them like rfc1918 space.
>

You are assuming facts not in evidence.

The fact that a prefix isn’t in a routing table you can see does not mean it is not used in a circumstance where
having it appear in routing tables you can see would be harmful or disruptive.

Owen

> On Nov 17, 2021, at 21:33 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Mark Andrews wrote:
>>
>>> On 18 Nov 2021, at 11:58, Joe Maimon <jmaimon@chl.com> wrote:
>>>
>>>
>>>
>>> Mark Andrews wrote:
>>>> It’s a denial of service attack on the IETF process to keep bringing up drafts like this that are never going to be approved. 127/8 is in use. It isn’t free.
>>> There are so many things wrong with this statement that I am not even going to try to enumerate them.
>>>
>>> However suffice it to say that drafts like these are concrete documentation of non-groupthink and essentially you are advocating for self-censorship and loss of historical perspective.
>> I’m advocating for not taking address away that have been allocated for a purpose. No one knows what the impact of doing that will be. Perhaps we should just take back 216.222.144.0/20? You obviously think taking back address that are in use to be a good thing. This is similar to taking back other address that are allocated but not advertised.
>
> I am advocating for serious discussion on the merits, and only the merits, of each individual idea and proposal and to respect those willing to put in the effort even while likely knowing of the undeserved scorn bound to come their way from those who choose not do as I would advocate them doing.
>
> And I think the basic contention is that the vast majority of 127/8 is not in use. Apples to oranges, indeed.

This contention is provably false for some definitions of “in use”.

>> You can script is to the same extent that you can hard code 127/8 addresses. I’ve used ULA addresses but conceptually they are the same. The lo0 interface also has more that 127.0.0.1 IPv4 addresses on it.
>>
>> % ifconfig lo0 inet6
>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
>> options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
>> inet6 ::1 prefixlen 128 .
>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
>> inet6 fd92:7065:b8e:ffff::1 prefixlen 64
>>
> Thats twice now you have suggested that ULA and LLA are an exact substitute for dedicated system loopback prefix.

In what way would the LLA or ULA above be meaningfully different from 127/8 as deployed?

> At the very least, it is semantically not.

How so?

> Doesnt IPv6 deserve its own instead of squatting on IPv4?

I don’t see any “squatting on IPv4” here.

Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread, 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

Can you be more specific about what changes to IPv6 you believe would resolve the issue?

Owen


> On Nov 18, 2021, at 01:43 , borg@uu3.net wrote:
>
> No, you are not alone. This just gets kinda pathetic.
> It also shows how an IPv6 is a failure.
> (No please, leave me alone all you IPv6 zealots).
>
> I think its time to go back to design board and start
> working on IPv8 ;) so we finnaly get rid of IPv4...
>
> ---------- Original message ----------
>
> From: Jay R. Ashworth <jra@baylink.com>
> To: nanog <nanog@nanog.org>
> Subject: Redploying most of 127/8 as unicast public
> Date: Wed, 17 Nov 2021 23:29:49 +0000 (UTC)
>
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me. So many things are just me.
>
> [. Hat tip to Lauren Weinstein, whom I stole it from ]
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth Baylink jra@baylink.com
> Designer The Things I Think RFC 2100
> Ashworth & Associates http://www.bcp38.info
> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

I don’t see the difference between 6 and 7 usable addresses on all the /29s
in the world as actually making a significant impact on the usable lifespan of
IPv4.

Owen


> On Nov 17, 2021, at 19:33 , Dave Taht <dave.taht@gmail.com> wrote:
>
> I am sad to see the most controversial of the proposals (127/16) first
> discussed here.
>
> Try this instead?
>
> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/
>
> in my mind, has the most promise for making the internet better in the
> nearer term.
>
> Could I get y'all to put aside the 127 proposal and read that over, instead?
>
> ...
>
> It's ok, I'll wait...
>
> ...
>
> There were two other proposals concerning 240/4 and 0/8 also worth
> reading for their research detail and attention to history.
>
> The amount of work required to make 240/4 work in most places is now
> very close to zero, having been essentially completed a decade ago.
> 240/4 and 0/8 checking is not present in the SDN codes we tried, and
> we ripped the 0/8 check out of linux 3? 4? years back. Saves a few ns.
>
> All but one iOt stack we tried worked with these, many of those stacks
> still lack, or have poor ipv6 support. esp32 anyone?
>
> Just as ipv6 today is not globally reachable, these address spaces may
> never be globally reachable, but defining a standard for their
> potential sub-uses
> seems like a viable idea.

On Fri, Nov 19, 2021 at 7:00 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread, 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.

I would prefer to discuss the other drafts. However, - and this is not
in the 127 draft, and is an opinion not shared with the other authors
-
I have a specific use case for making 127 "more routable", in that
there is nowadays a twisty maze of microservices, bottled up in a
variety of
kubernetes containers, running on top of vms, on top of a hypervisor,
that are often hooked together via rfc1918 addressing and NAT.

Trying to figure out that particular path, from within one of those
containers, can be a PITA. The concept of 127 being local to a
physical host
(and routed internally, rather than natted), where those twisty maze
of services ideally remains within that host, holds some appeal to me.

>
> Owen
>


--
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

Owen DeLong wrote:
>
>> On Nov 17, 2021, at 21:33 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>
>>
>> And I think the basic contention is that the vast majority of 127/8 is not in use. Apples to oranges, indeed.
> This contention is provably false for some definitions of “in use”.

Determining the extent of this would be part of serious consideration.
>
> In what way would the LLA or ULA above be meaningfully different from 127/8 as deployed?

Because 127/8 is the exact same number on every system and it is routed
the same way on every system and every system can choose to use it how
it and it alone wishes to.

So this make it a deterministic prefix solely in control of the local
system without any external context to ever be taken into consideration,
by convention and standard.

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.

>
>> Doesnt IPv6 deserve its own instead of squatting on IPv4?
> I don’t see any “squatting on IPv4” here.

It means that the only deterministic loopback prefix in IPv6 larger than
a single address is the one IPv6 inherited from IPv4.
>
> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread,

This is not my point, it is the contention of the draft standard and it
is something I would hope is taken into serious consideration and
researched properly/

My point is that to the extent this is true, the value of the space for
other purposes could very well warrant re-purposing.
> 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.

Joe

Owen DeLong via NANOG wrote:
> I don’t see the difference between 6 and 7 usable addresses on all the /29s
> in the world as actually making a significant impact on the usable lifespan of
> IPv4.
>
> Owen
>

This idea gets better each time I think about it. The changes and
support required would typically be only local to customer/vendor and it
can be useful in multiple contexts within a single entity as well.

Or how about this one. I can add VRRP failover to every customer prefix
with zero negative impact to them by addressing the secondary with the
all-zero address. Only I have to upgrade since the customer doesnt use
or refer to that address ever. Now granted, using a FHRP protocol that
didnt require any address at all in the subnet for the non-primary would
give the same result. And maybe maybe maybe ICMP from the secondary
might get dropped by non-updated customer.

How about customers who like to have redundant routers now only require
an update to do it within /30, which within vendor relationship context,
should it be standard long enough, they may very well require, and
should a /29 cost more, the customer may very well prefer.

Getting an extra address out of a /29 and two instead of one out of /30
can be quite useful to each individual user and use of those prefixes.

Collectively, it may or may not extend IPv4 global resources. Probably
not in any measurable way and possibly non existent, although it is
conceivable that /30 would become usable enough that less /29's will be
assigned, and the same for /29 lasting longer before requiring /28.
Probably not much beyond that.

Its about getting more mileage from existing allocations, not really
about making more allocations available.

And all thats needed to be done is to drop this ridiculous .0 for
broadcast compatibility from standards.....why is this even controversial?

Joe

>
> You are proposing a deal involving paper money you have on your person
> to your fellow passengers on the Titanic; that is the essence of your
> proposed bet hedging. Having studied the market for IPv4, it is a no-
> brainer to realise the driving force behind all these schemes. Delaying
> the inevitable is just going to make some people richer, to the detriment
> of others. I see no reason to support that.

That’s because you and I are probably on the wrong side of the benefit/detriment
divide.

No doubt those pushing the proposal(s) think they have a way to be on the
benefit side of said divide.

Owen

> On Nov 19, 2021, at 07:23 , Dave Taht <dave.taht@gmail.com> wrote:
>
> On Fri, Nov 19, 2021 at 7:00 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
>> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread, 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.
>
> I would prefer to discuss the other drafts. However, - and this is not
> in the 127 draft, and is an opinion not shared with the other authors
> -
> I have a specific use case for making 127 "more routable", in that
> there is nowadays a twisty maze of microservices, bottled up in a
> variety of
> kubernetes containers, running on top of vms, on top of a hypervisor,
> that are often hooked together via rfc1918 addressing and NAT.
>
> Trying to figure out that particular path, from within one of those
> containers, can be a PITA. The concept of 127 being local to a
> physical host
> (and routed internally, rather than natted), where those twisty maze
> of services ideally remains within that host, holds some appeal to me.

Couldn’t you do this with 169.254.0.0/16 (or IPv6 GUA or ULA)
just as easily without the need to rewrite virtually every layer of the
stack of miscellaneous software defined networking stuff you just listed?

Owen

> On Nov 19, 2021, at 07:39 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>>
>>> On Nov 17, 2021, at 21:33 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>>
>>>
>>> And I think the basic contention is that the vast majority of 127/8 is not in use. Apples to oranges, indeed.
>> This contention is provably false for some definitions of “in use”.
>
> Determining the extent of this would be part of serious consideration.
>>
>> In what way would the LLA or ULA above be meaningfully different from 127/8 as deployed?
>
> Because 127/8 is the exact same number on every system and it is routed the same way on every system and every system can choose to use it how it and it alone wishes to.

But the proposal seeks to change that nature of 127.0.0.0/8 to make it more like LLA/ULA, so…

> So this make it a deterministic prefix solely in control of the local system without any external context to ever be taken into consideration, by convention and standard.

At the moment, that’s already true. AIUI, the proposal being discussed seeks to convert 127.0.0.0/8 outside of 127.0.0.1 (or at least outside of 127.0.0.0/16) into
routable GUA.

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

>>> Doesnt IPv6 deserve its own instead of squatting on IPv4?
>> I don’t see any “squatting on IPv4” here.
>
> It means that the only deterministic loopback prefix in IPv6 larger than a single address is the one IPv6 inherited from IPv4.

Well… Worst case, it could use ::ffff:7f00:0000::/96

Whether you consider that “squatting on IPv4” or not is left as an exercise to the reader. I do not, though I can understand and
must admit that it is equally legitimate if someone else does.

>> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not particularly widespread,
>
> This is not my point, it is the contention of the draft standard and it is something I would hope is taken into serious consideration and researched properly/
>
> My point is that to the extent this is true, the value of the space for other purposes could very well warrant re-purposing.

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.

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

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.

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

On Fri, Nov 19, 2021 at 8:35 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
> I’m all for IPv6 having better implementations than IPv4 rather than mere feature parity.

Me too, just not in a dystopian Harrison Bergeron sort of way.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/

So see, that was kinda my view, though I hadn't realized there was a kernel
hack advancing the football...

----- Original Message -----
> From: "Owen DeLong" <owen@delong.com>
> To: "William Herrin" <bill@herrin.us>
> Cc: "jra" <jra@baylink.com>, "nanog" <nanog@nanog.org>
> Sent: Friday, November 19, 2021 9:28:01 AM
> Subject: Re: Redploying most of 127/8 as unicast public

> This will break a significant number of existing deployments where people
> have come to depend on a feature in Linux where any address within 127.0.0.0/8
> can be “listened” and operate as a valid loopback address without configuring
> the addresses individually as unicast on the interface.
>
> In fact, this is true of any prefix assigned to the loopback interface, but
> 127.0.0.0/8
> is automatic and difficult to change.
>
> While I’m not sure this implementation in the Linux kernel was such a wonderful
> idea, it is widely deployed and in use in a number of environments.
>
> If we’re still using IPv4 widely enough that GUA space matters, we will have
> far bigger problems than the lack of available GUA for it.
>
> Owen
>
>
>> On Nov 17, 2021, at 16:15 , William Herrin <bill@herrin.us> wrote:
>>
>> On Wed, Nov 17, 2021 at 3:31 PM Jay R. Ashworth <jra@baylink.com> wrote:
>>> This seems like a really bad idea to me; am I really the only one who noticed?
>>>
>>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>>
>> Hi Jay,
>>
>> I think it's a good idea. It won't be usable any time in the next two
>> decades but if we're still using IPv4 in two decades we'll be glad to
>> have anything we can scrounge. Why not ask OS authors to start
>> assigning 127.0.0.1/16 to loopback instead of 127.0.0.1/8?
>>
>> Regards,
>> Bill Herrin
>>
>>
>> --
>> William Herrin
>> bill@herrin.us
> > https://bill.herrin.us/

--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

For what it’s worth, it's also being discussed in a couple of subreddits. Total # of comments is about 500, so far.

https://www.reddit.com/r/sysadmin/comments/qvuyor/new_rfc_to_redefine_loop_back_and_allow_127100_to/ <https://www.reddit.com/r/sysadmin/comments/qvuyor/new_rfc_to_redefine_loop_back_and_allow_127100_to/>
https://www.reddit.com/r/networking/comments/qw0kv0/unicast_use_of_the_formerly_reserved_1278/ <https://www.reddit.com/r/networking/comments/qw0kv0/unicast_use_of_the_formerly_reserved_1278/>

—gregbo

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

Joe Maimon <jmaimon@jmaimon.com> wrote:
> And all thats needed to be done is to drop this ridiculous .0 for
> broadcast compatibility from standards.....why is this even controversial?

Not to put words in his mouth, but that's how original BSD maintainer
Mike Karels seemed to feel when we raised this issue for FreeBSD. He
was like, what? We're wasting an address per subnet for 4.2BSD
compatability? Since 1986? Let's fix that.

John

=?utf-8?B?TcOlbnM=?= Nilsson <mansaxel@besserwisser.org> wrote:
> The only viable future is to convert [to IPv6]. This is not
> group-think, it is simple math.

OK. And in the long run, we are all dead. That is not group-think, it
is simple math. Yet that's not a good argument for deciding not to
improve our lives today. Nor to fail to improve them for tomorrow,
in case we live til then.

John </philosophy>

Fred Baker <fredbaker.ietf@gmail.com> wrote:
> I tend to think that if we can somehow bless a prefix and make be
> global unicast address space, it needs to become Global Unicast
> Address Space.

Yes, I agree. The intention is that with the passage of time, each
prefix becomes more and more reachable, til it's as close to 100% as any
other IP address.

I was just suggesting a side point, that some kinds of IP users may be
able to make earlier use of measurably less-reachable addresses. That
could possibly enable them to get those addresses at lower prices (and
with no guarantees), compared to people who want and expect 100%
reachable IP addresses. Having users making actual early use of them
would also encourage those users to actively work to improve their
reachability, rather than passively waiting til "somebody else" improves
their reachability. (Indeed, some adventurous early adopters might buy
such addresses, actively improve their reachability, then 'flip' them
for higher prices, as some people do with real-estate.) Just pointing
out a side chance for a win-win situation. Most users would wait til
surveys show high reachability.

John

Subject: Re: Redploying most of 127/8 as unicast public Date: Fri, Nov 19, 2021 at 12:26:23PM -0800 Quoting John Gilmore (gnu@toad.com):
> =?utf-8?B?TcOlbnM=?= Nilsson <mansaxel@besserwisser.org> wrote:
> > The only viable future is to convert [to IPv6]. This is not
> > group-think, it is simple math.
>
> OK. And in the long run, we are all dead. That is not group-think, it
> is simple math. Yet that's not a good argument for deciding not to
> improve our lives today. Nor to fail to improve them for tomorrow,
> in case we live til then.

The math is true today. Most people now have more devices than they have
IP addresses. (And reachability should be choice, not shortage
consequence) Increasing the available address space by at most a few
percent at the price of a flag day is not a good return. (unless you
are in a position to profit from the shortage, at which point all these
crutch proposals look irresistible if not from a technical standpoint)
Increasing the address space 79228162514264337593543950336 times at
the price of rolling software upgrades that actually mostly are done
(I haven't bought or commissioned non-v6 gear for 15 years now), even
if there's a lot left to turn on and configure, is a slightly better
proposition.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
MY income is ALL disposable!

Subject: Re: Redploying most of 127/8 as unicast public Date: Fri, Nov 19, 2021 at 09:04:59PM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp):
> Mans Nilsson wrote:
>
> > The essence of an IP address is that it is unique. The larger the network
> > area is that recognizes it as unique, the better it is.
>
> With proper layering, network addresses including IP ones, certainly,
> uniquely identify *hosts*.
>
> However, with proper layering, *applications* only require uniqueness
> of IP+Port, which is enough for the worldwide IPv4 network.
>
> As a result, NAT won the battle against IPv6.
>
> IPv6 addresses are free but useless.

With all due respect, you think about networks. I use and build
networks. And my experience is that IP+port is not enough. We cope,
because a lot of technical debt is amassed in corporate and ISP /
access provider networks that won't change. We don't cope because NAT is
good. Hardly a workday goes past without me thinking "If I could address
this computer uniquely I'd go home earlier and with less grey hair".

We must do better.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
Do you have exactly what I want in a plaid poindexter bar bat??

Mans Nilsson wrote:

>> With proper layering, network addresses including IP ones, certainly,
>> uniquely identify *hosts*.
>>
>> However, with proper layering, *applications* only require uniqueness
>> of IP+Port, which is enough for the worldwide IPv4 network.
>>
>> As a result, NAT won the battle against IPv6.
>>
>> IPv6 addresses are free but useless.
>
> With all due respect, you think about networks. I use and build
> networks. And my experience is that IP+port is not enough.

Certainly, local uniqueness of IP addresses to identify hosts
is required even in private networks behind NAT. But, because
of layering, that's all.

I do have extensive experiences to use and build networks
with proper layering in mind.

> We cope,
> because a lot of technical debt is amassed in corporate and ISP /
> access provider networks that won't change.

Sounds like abstract nonsense.

> We don't cope because NAT is
> good. Hardly a workday goes past without me thinking "If I could address
> this computer uniquely I'd go home earlier and with less grey hair".

The reality is that application servers only need globally unique
and stable IP+Ports.

You can address application servers with them.

> We must do better.

As IPv6 is worse than IPv4 with NAT, feel free to propose a new
network protocol.

Masataka Ohta

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp):

> > We cope,
> > because a lot of technical debt is amassed in corporate and ISP /
> > access provider networks that won't change.
>
> Sounds like abstract nonsense.

No, it is the real reason that we still have v4 around.

> > We don't cope because NAT is
> > good. Hardly a workday goes past without me thinking "If I could address
> > this computer uniquely I'd go home earlier and with less grey hair".
>
> The reality is that application servers only need globally unique
> and stable IP+Ports.
>
> You can address application servers with them.

If, and that is a big IF, they're designed for that. Hint: They're not,
and I'm required to deploy technology compatible with older systems and
systems outside my control. It would be far easier for me if I could
continue with the original assumption -- IP addresses are identifiers.

I know you will immediately state that if I change everything else except
the IP addressing scheme at 32 bits plus 16 bits of port space (which in
and of itself is a change; granted more so in terms of service location),
I will be fine. But I only want to change the addressing layer. The rest
works fine. And is a bigger mess to alter to your idea.

> > We must do better.
>
> As IPv6 is worse than IPv4 with NAT, feel free to propose a new
> network protocol.

In your application, that assertion on worseness might be true. In my,
where I value the E2E principle higher, no, I think it is not.


--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
I used to be a FUNDAMENTALIST, but then I heard about the HIGH
RADIATION LEVELS and bought an ENCYCLOPEDIA!!

On Sat, 20 Nov 2021, 09:21 Måns Nilsson, <mansaxel@besserwisser.org> wrote:

> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20,
> 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (
> mohta@necom830.hpcl.titech.ac.jp):
>
> > > We cope,
> > > because a lot of technical debt is amassed in corporate and ISP /
> > > access provider networks that won't change.
> >
> > Sounds like abstract nonsense.
>
> No, it is the real reason that we still have v4 around.
>

The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6 is
relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some
examples:

***

1. Your power goes out. When it comes back up, your internet connection is
down. You want to log in to the router... Except you can't. You don't know
the address, and you won't have one until your ISP gives you one via DHCP
(or similar).

Sure, you could maybe provide the link-local address on the bottom of the
router, but expecting a user to get http://[fe80:211:aaff:febb:ccdd] right
(and you might even need interface scoping!) is boring to cause user
frustration when an ISP tech support tries to help, and having the provided
CPE using fe80::1 is probably a recipe for disaster.

Likewise, having an mdns broadcast (ssssh, I know) for "gateway" or
"router" is definitely not something standardised.

2. Your IPv6 prefix changes. With some ISPs, it can change every time your
router reboots, and if you're with my ISP, it crash-reboots about once a
week! If your CPE isn't providing your WiFi (range extender, mesh, nerd
etc) then the old prefix is still valid for a while. Yes, there's an RFC to
deal with this, but realistically it's not out there today.

Also, any local services are going to break if they're on static
addresses... I'm not just talking enterprise AD servers etc, it's also CCTV
cameras, raspberry pis, NAS units etc. DHCP registration of addresses in
DNS exists, yes, but it's just not used by most of these devices.

This could easily be fixed by having a well-known (and short/memorable!)
/48 set aside that would have NAT66 (1:1, not port overload) applied at the
router to the delegated prefix received from the ISP, but I'll be shouted
down to hell for even mentioning that idea.

3. IPv6 "port forwarding" isn't really an easy thing -- people are not used
to each machine having a global address. Sure, on many devices you can add
firewall rules to allow traffic in, but it's not like the "port forwarding"
concept people have gotten used to. I genuinely have no idea whether
upnp/nat-pmp has an IPv6 analogue that "just works" which things like
consoles (or apps like syncthing) can take advantage of.

***

IPv4 works. There is no appreciable benefit to the user in enabling IPv6,
but the ISP does it and it just works. The same can't be said of going IPv6
only -- you can easily provide IPv6 only with NAT64 and DNS64 or some
XLAT464 fun when you're dealing with public WiFi, but this is people's
homes and businesses.

Likewise, there's so many devices that are IPv4 only, and aren't getting
retired anytime soon. In fact, there's a lot of devices released in the
last few years that fully support IPv6, but only when it also has an IPv4
address. I believe either the new Xbox and/or PS5 fit into that category.

IPv4 is getting more expensive for ISPs because of addressing costs, but a
5-tuple CGNAT solution capable of saturating a 100Gb/s pipe is under $10k
these days if you're doing it on the cheap. Yes, this is massively
oversimplified.

Not just that, if you have a CPE capable of doing MAP-T (RFC7599 et al)
then your CGNAT doesn't even need to track state, and you can probably do
it in ASIC, especially with a programmable dataplane (P4 etc).

IPv6 only is the goal. IPv4 is going to be with us for at least a decade.
Getting IPv6 up and running on a network requires a lot of effort when that
network is run by the IT PFY, but it will slowly get that wide penetration
desired... Turning off IPv4 for your regular residential and SME ISP
connections is such a PITA fraught with support problems that it is just
not practical outside of very limited conditions.

Certainly, on the content side, you can make all your HTTP services on IPv6
only servers, and have the IPv4 go to a proxy that routes based on Host
header or SNI, but you need some networking knowledge already to understand
what is going on there.

IPv4 isn't going anywhere anytime soon. Enabling IPv6 reduces IPv4 traffic
levels, it does not reduce IPv4 address usage.

Happy for someone to prove me wrong here, but don't use mobile as an
example. That's a very different market... I'm talking about residential
and SOHO internet access here only.

M

Mans Nilsson wrote:

>>> We cope,
>>> because a lot of technical debt is amassed in corporate and ISP /
>>> access provider networks that won't change.
>>
>> Sounds like abstract nonsense.
>
> No, it is the real reason that we still have v4 around.

Even more than 25 years after IPv6 became a proposed standard?

It merely means IPv6 is not deployable with the real reason.

>> The reality is that application servers only need globally unique
>> and stable IP+Ports.
>>
>> You can address application servers with them.
>
> If, and that is a big IF, they're designed for that. Hint: They're not,
> and I'm required to deploy technology compatible with older systems and
> systems outside my control. It would be far easier for me if I could
> continue with the original assumption -- IP addresses are identifiers.

The proper layering, which you insist to ignore, is that IP addresses
are identifiers at the network layer whereas IP+Ports are the
identifiers at above layers.

> I know you will immediately state that if I change everything else except
> the IP addressing scheme at 32 bits plus 16 bits of port space (which in
> and of itself is a change;

It was.

It was the changed made by deploying NAT, which was a lot lot lot
less painful to support IPv6.

> But I only want to change the addressing layer.

There is no such layer as "the addressing layer".

At the transport layer, connections are addressed by network
addresses and port numbers, which means address there in the
Internet is IP+Port.

I really recommend you to understand proper layering.

> In your application, that assertion on worseness might be true. In my,
> where I value the E2E principle higher, no, I think it is not.

So, you are rather a theorist than a practitioner.

However, I'm both of them.

See:

https://datatracker.ietf.org/doc/html/draft-ohta-e2e-nat-00

to understand that properly architected NAT preserves the so
valuable E2E principle.

For example, I confirmed with my implementation that PORT command
of ftp perfectly works over the E2E NAT gateways.

After finding that, I, as a theorist, totally abandoned IPv6.

Masataka Ohta

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 11:16:59AM +0000 Quoting Matthew Walster (matthew@walster.org):

> The "real" reason we have IPv4 around is that it works.

It works in our present context, good enough that the pain of moving
looks bad to many people. This is Ohta-san's argument too.

> 3. IPv6 "port forwarding" isn't really an easy thing -- people are not used
> to each machine having a global address.

This is the problem in a nutshell. After 27 years of destroying the
E2E model on the internet, people do not anymore understand how IP
(regardless of version) was supposed to work; any node to any node.

Why should we burden ourselves with this cumbersome and painful, useless
layer of abstraction that is "port forwarding", when the choice of
universal reachability is around the corner?

If people can set a port forward up, they can click "allow" in a
routing-based firewall interface. Only it is better, because one can
have several parallel services using well-known ports. Sometimes (most
of the time) the protocol spec has no option to change port either,
making port forwarding futile anyway. (the let's have a TXT record bunch
at it again, purposefully ignoring SRV since its inception.)

I guess juggling our pains differently is what we are doing here. What
is unthinkable to one is quite OK to someone else.

(But I am right)
--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
We just joined the civil hair patrol!

During the nation-wide lockdown of 2020, around the world, I took up
live-streaming my DJ sets online, since I couldn't play live. For those
that haven't seen them, you're welcome to my Youtube channel to catch them:

https://yt.djmt.africa/watch

Anyway, what I wanted to say is that I was streaming using an iPhone app
that turns the iPhone and iPad into a digital video capture device.

As per the links below, if this lowly, rather obscure app from an
unknown Canadian iOS developer supports IPv6 as a way to setup a remote
connection between the laptop (encoder) and iPhone/iPad, in order to
make camera adjustments so you don't have to physically walk toward the
device, what is your excuse :-)?

https://ibb.co/C8kbpPc
https://ibb.co/yYPWbvd

Mark.