Mailing List Archive

> On Sep 23, 2021, at 18:48 , Brian Johnson <brian.johnson@netgeek.us> wrote:
>
>
>
>> On Sep 23, 2021, at 6:49 PM, Owen DeLong <owen@delong.com> wrote:
>>
>>
>>
>>> On Sep 23, 2021, at 12:50 , Brian Johnson <brian.johnson@netgeek.us> wrote:
>>>
>>> Side question on this thread…
>>>
>>> Is it everyones current expectation that if a provider were to switch to IPv6 and drop IPv4 that the customers would all be just fine with that? I believe that there are several applications used by some of the the loudest customers (typically gamers and network gurus), not to mention some business applications that would break or be sub-optimal at best. I see CGN as the band aid to this issue, not the cure to the problem.
>>
>> Today? no.
>>
>> At some point when a relatively small number of remaining laggards among major content providers move forward? Yes.
>
> So do we just bleed out in the mean time?

Well, you can turn off IPv4 on your network whenever you choose to do so.

Unfortunately, I suspect you’re in the same boat I am there, yes, continuing to bleed until the laggards on the content side get their acts together.

>> Do you really think that those applications/vendors wouldn’t move quickly if a couple of major eyeball providers announced “Effective X date”, we’re going to start offering a $X/month discount to any customer(s) who are willing to stop using IPv4.
>
> I’d be happy to suggest this to my clients, but it’s not a real thing yet. Plus, the average human (even the average CSR at a small regional provider network) has no idea what this means.

Yeah, it doesn’t mean anything there. For it to mean something, it would have to be somebody like Comcast, Cox, etc. and they’d have to put it like 2 years out, but make a big point of it with the content providers.

Another thing they could do if so inclined (the really big eyeball providers) is they could start doing settlement free IPv6-only PNIs for content providers.

>> You an only cover an arterial bleed with a band-aid for so long before it becomes silly, septic even. If you’re wondering how quick that point is coming up, I suggest you check your mirrors.
>
> Triage suggests that you assist in succession of the current bleeding before being concerned about the next time you are cut. I have BGN deployments that have been in place for 4+ years with little customer knowledge. It has allowed clients to avoid the IPv4 market issues, and in some instances, become a source for others to help compensate for the initial CGN expense.

I hear you. I’m not sure there’s a viable alternative, but in my experience, CGN pisses off online gamers something fierce and if you’re an eyeball ISP, I don’t envy you the phone calls that’s going to create, especially as games get more and more network-oriented.

Sony already categorizes NAT into various categories and basically when it detects CGN it can’t easily penetrate or circumvent, it tells you to call your ISP and complain.

> I totally agree with you in spirit, but I am working on the problem of now, not the problem of some point in the future. The cost of CGN is becoming less expensive than IPv4 space acquisition. I wish this weren’t true.

Yeah, but it’s far from zero and that’s more because IPv4 is getting more expensive than because CGN is getting cheaper.

There’s only so far you can go with CGN before the user experience turns universally bad. It turns bad for a lot of customers well before that point.

I don’t envy you.

Owen

>
>>
>> Owen
>>
>>>
>>> Discuss…?
>>>
>>> - Brian
>>>
>>>> On Sep 23, 2021, at 10:46 AM, Owen DeLong via NANOG <nanog@nanog.org> wrote:
>>>>
>>>>> There are real issues with dual-stack, as this thread started out with.
>>>>> I don't think there is a need neither to invent IPv6 problems, nor to
>>>>> promote IPv6 advantages. What we need is a way out of dual-stack-hell.
>>>>
>>>> I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
>>>>
>>>> I think the only way out is through. Unfortunately, the IPv6 resistant forces
>>>> are making that hard for everyone else.
>>>>
>>>> Owen
>>>>
>>>
>>
>

Oh yeah, it would be very funny if this will really happen (new protocol).
Im not happy with IPv6, and it seems many others too.

This is short list how my ideal IPv6 proto looks like:
- 64bit address space
more is not always better
- loopback 0:0:0:1/48
- soft LL 0:0:1-ffff:0/32 (Link Local)
- RFC1918 address space 0:1-ffff:0:0/16
- keep ARPs, ND wasnt great idea after all?
- NAT support (because its everywhere these days)
- IPv6 -> IPv4 interop (oneway)
we can put customers on IPv6, while keeping services dualstack
- correct DHCP support (SLAAC wasnt great idea after all?)
I think its already in IPv6, but was an issue at the begining

If there are some weird requirements from others, put them into layer up.
L3 needs to be simple (KISS concept), so its easy to implement and less
prone to bugs.

And that IPv6 I would love to see and addapt right away :)


---------- Original message ----------

From: Joe Maimon <jmaimon@jmaimon.com>
To: Owen DeLong <owen@delong.com>, Bjrn Mork <bjorn@mork.no>
Cc: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Thu, 23 Sep 2021 16:26:17 -0400



Owen DeLong via NANOG wrote:
> > There are real issues with dual-stack, as this thread started out with.
> > I don't think there is a need neither to invent IPv6 problems, nor to
> > promote IPv6 advantages. What we need is a way out of dual-stack-hell.
> I dont disagree, but a reversion to IPv4-only certainly wont do it.

For everyone who does have enough IPv4 addresses, it does. This is the problem
in a nutshell. If that starts trending, IPv6 is done.

> I think the only way out is through.

I hope not, both for IPv6 sake and for the network users. We dont know how much
longer the goal will take, there is materializing a real possibility we will
never quite reach it, and the potholes on the way are pretty rough.

And as the trip winds on, the landscape is changing, not necessarily for the
better.

One more "any decade now" and another IPv4 replacement/extension might just
happen on the scene and catch on, rendering IPv6 the most wasteful global
technical debacle to date.


> Unfortunately, the IPv6 resistant forces
> are making that hard for everyone else.
>
> Owen

You say that as if it was a surprise, when it should not have been, and you say
that as if something can be done about it, which we should know by now cannot be
the primary focus, since it cannot be done in any timely fashion. If at all.

Its time to throw mud on the wall and see what sticks. Dual stack and wait is an
ongoing failure slouching to disaster.

Joe

On 9/24/21 3:01 AM, borg@uu3.net wrote:
> Oh yeah, it would be very funny if this will really happen (new protocol).
> Im not happy with IPv6, and it seems many others too.

Is your dissatisfaction with the IPv6 protocol itself or is your
dissatisfaction with the deployment / adoption of the IPv6 protocol?

I think that it's a very critical distinction. Much like DoH as a
protocol vs how some companies have chosen to utilize it. Similar to
IBM's computers vs what they were used for in the 1940's.

> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
> more is not always better
> - loopback 0:0:0:1/48
> - soft LL 0:0:1-ffff:0/32 (Link Local)
> - RFC1918 address space 0:1-ffff:0:0/16
> - keep ARPs, ND wasnt great idea after all?
> - NAT support (because its everywhere these days)
> - IPv6 -> IPv4 interop (oneway)
> we can put customers on IPv6, while keeping services dualstack
> - correct DHCP support (SLAAC wasnt great idea after all?)
> I think its already in IPv6, but was an issue at the begining

I'm probably showing my ignorance, but I believe that the IPv6 that we
have today effectively does all of those things. At least
functionality, perhaps with different values.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS concept), so its easy to implement and less
> prone to bugs.

How many of the hurtles to IPv6's deployment have been bugs in layer 3?
It seems to me that most of the problems with IPv6 that I'm aware of are
at other layers, significantly higher in, or on top of, the stack.

> And that IPv6 I would love to see and addapt right away :)

I'm of the opinion that IPv6 has worked quite well dual stack from about
2005-2015. It's only been in the last 5 or so years that I'm starting
to see more problems with IPv6. And all of the problems that I'm seeing
are companies making business level decisions, way above layer 7, that
negatively impact IPv6. Reluctance to run an MX on IPv6 for business
level decisions is definitely not a protocol, much less L3, problem.



--
Grant. . . .
unix || die

Owen DeLong wrote:
>
>> On Sep 23, 2021, at 13:26 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>
>>
>> I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty rough.
> By “the only way out is through” I meant that the only way we can get back to anything resembling mono-stack is, in fact, to complete the transition to IPv6.

The question is how? Waiting for everyone or nearly everyone to dual
stack, the current strategy, is awful. Like pulling gum off a shoe.

>
>> And as the trip winds on, the landscape is changing, not necessarily for the better.
> The IPv4 landscape will continue to get worse and worse. It cannot possibly get better, there just aren’t enough addresses for that.

I was referring to the more general network landscape, the governance
system, the end of p2p, balkanization, etc, all trends and shifts that
become more likely and entrenched the longer IPv6 lags and the scarcer
IPv4 becomes.

>
>> One more "any decade now" and another IPv4 replacement/extension might just happen on the scene and catch on, rendering IPv6 the most wasteful global technical debacle to date.
> If that’s what it takes to move forward with a protocol that has enough addresses, then so be it. I’m not attached to IPv6 particularly, but I recognize that IPv4 can’t keep up. As such, IPv6 is just the best current candidate. If someone offers a better choice, I’m all for it.

Whose to say it would be a proper p2p system? I know you believe
strongly in that and want it fully restored, at least on the protocol level.

>>> Unfortunately, the IPv6 resistant forces
>>> are making that hard for everyone else.
>>>
>>> Owen
>> You say that as if it was a surprise, when it should not have been, and you say that as if something can be done about it, which we should know by now cannot be the primary focus, since it cannot be done in any timely fashion. If at all.
> It’s not a surprise, but it is a tragedy.
>
> There are things that can be done about it, but nobody currently wants to do them.

So lets make the conversation revolve around what can be done to
actually advance IPv6, and what we should know by now is that convincing
or coercing deployment with the current state of affairs does not have
enough horsepower to get IPv6 anywhere far anytime soon.

>
>> Its time to throw mud on the wall and see what sticks. Dual stack and wait is an ongoing failure slouching to disaster.
> IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant among us remain in denial about that.

Who is this "us"? Anybody even discussing IPv6 in a public forum is well
ahead of the curve. Unfortunately. All early adopters. Real Early.
>
> At some point, we are going to have to make a choice about how much longer we want to keep letting them hold us back. It will not be an easy choice, it will not be convenient, and it will not be simple.
>
> The question is how much more pain an dhow much longer will it take before the choice becomes less difficult than the wait?
>
> Owen
>
Exactly what does this choice look like? Turn off IPv4 when its fully
functional? Only the have-nots may make the choice not to deploy IPv4
sometime in the future, and for them, its not going to be a real choice.


Joe

Well, I see IPv6 as double failure really. First, IPv6 itself is too
different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with
bigger address space, likely 64bit). Of course we could not extend IPv4,
so having new protocol is fine. It should just fix problem (do we have other
problems I am not aware of with IPv4?) of address space and thats it.
Im happy with IPv4, after 30+ years of usage we pretty much fixed all
problems we had.

The second failure is adoption. Even if my IPv6 hate is not rational,
adoption of IPv6 is crap. If adoption would be much better, more IPv4
could be used for legacy networks ;) So stuborn guys like me could be happy
too ;)

As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details:
- Loopback on IPv6 is ::1/128
I have setups where I need more addresses there that are local only.
Yeah I know, we can put extra aliases on interfaces etc.. but its extra
work and not w/o problems
- IPv6 Link Local is forced.
I mean, its always on interface, nevermind you assign static IP.
LL is still there and gets in the way (OSPFv3... hell yeah)
- ULA space, well.. its like RFC1918 but there are some issues with it
(or at least was? maybe its fixed) like source IP selection on with
multiple addresses.
- Neighbor Discovery protocol... quite a bit problems it created.
What was wrong w/ good old ARP? I tought we fixed all those problems
already like ARP poisoning via port security.. etc
- NAT is there in IPv6 so no futher comments
- DHCP start to get working on IPv6.. but it still pain sometimes

And biggest problem, interop w/ IPv4 was completly failure.
Currently we have best Internet to migrate to new protocol.
Why? Because how internet become centralized. Eyeball networks
just want to reach content. E2E communication is not that much needed.
We have games and enhusiast, but those can pay extra for public IPv4.
Or get VPN/VPS.

And end comment. I do NOT want to start some kind of flame war here.
Yeah I know, Im biased toward IPv4. If something new popups, I want it
better than previous thingie (a lot) and easier or at least same level of
complications, but IPv6 just solves one thing and brings a lot of
complexity.

The fact is, IPv6 failed. There are probably multiple reasons for it.
Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4
works for me for now.


---------- Original message ----------

From: Grant Taylor via NANOG <nanog@nanog.org>
To: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Fri, 24 Sep 2021 10:17:42 -0600

On 9/24/21 3:01 AM, borg@uu3.net wrote:
> Oh yeah, it would be very funny if this will really happen (new protocol).
> Im not happy with IPv6, and it seems many others too.

Is your dissatisfaction with the IPv6 protocol itself or is your dissatisfaction
with the deployment / adoption of the IPv6 protocol?

I think that it's a very critical distinction. Much like DoH as a protocol vs
how some companies have chosen to utilize it. Similar to IBM's computers vs
what they were used for in the 1940's.

> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
> more is not always better
> - loopback 0:0:0:1/48
> - soft LL 0:0:1-ffff:0/32 (Link Local)
> - RFC1918 address space 0:1-ffff:0:0/16
> - keep ARPs, ND wasnt great idea after all?
> - NAT support (because its everywhere these days)
> - IPv6 -> IPv4 interop (oneway)
> we can put customers on IPv6, while keeping services dualstack
> - correct DHCP support (SLAAC wasnt great idea after all?)
> I think its already in IPv6, but was an issue at the begining

I'm probably showing my ignorance, but I believe that the IPv6 that we have
today effectively does all of those things. At least functionality, perhaps
with different values.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS concept), so its easy to implement and less
> prone to bugs.

How many of the hurtles to IPv6's deployment have been bugs in layer 3? It seems
to me that most of the problems with IPv6 that I'm aware of are at other layers,
significantly higher in, or on top of, the stack.

> And that IPv6 I would love to see and addapt right away :)

I'm of the opinion that IPv6 has worked quite well dual stack from about
2005-2015. It's only been in the last 5 or so years that I'm starting to see
more problems with IPv6. And all of the problems that I'm seeing are companies
making business level decisions, way above layer 7, that negatively impact IPv6.
Reluctance to run an MX on IPv6 for business level decisions is definitely not a
protocol, much less L3, problem.



--
Grant. . . .
unix || die

On 9/24/21 10:53 AM, borg@uu3.net wrote:
> Well, I see IPv6 as double failure really. First, IPv6 itself is too
> different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with
> bigger address space, likely 64bit). Of course we could not extend IPv4,
> so having new protocol is fine. It should just fix problem (do we have other
> problems I am not aware of with IPv4?) of address space and thats it.
> Im happy with IPv4, after 30+ years of usage we pretty much fixed all
> problems we had.
>
But that is what ipv6 delivers -- a 64 bit routing prefix. Am I to take
it that a whopping 16 bytes of extra addressing information breaks the
internet? And all of the second system syndrome stuff was always
separable just like any other IETF protocol. you implement what is
needed and ignore all of the rest -- there is no IETF police after all.

I can understand the sound and fury when people were trying to make this
work on 56kb modems, but with speeds well over 1G it seems sort of archaic.

Mike

On 9/24/21 11:53 AM, borg@uu3.net wrote:
> Well, I see IPv6 as double failure really.

I still feel like you are combining / conflating two distinct issues
into one generalization.

> First, IPv6 itself is too different from IPv4.

Is it? Is it really? Is the delta between IPv4 and IPv6 greater than
the delta between IPv4 and IPX?

If anything, I think the delta between IPv4 and IPv6 is too small.
Small enough that both IPv4 and IPv6 get treated as one protocol and
thus a lot of friction between the multiple personalities therein. I
also think that the grouping of IPv4 and IPv6 as one protocol is part of
the downfall.

More over if you think of IPv4 and IPv6 dual stack as analogous to the
multi-protocol networks of the '90s, and treat them as disparate
protocols that serve similar purposes in (completely) different ways, a
lot of the friction seems to make sense and as such becomes less
friction through understanding and having reasonable expectations for
the disparate protocols.

> What Internet wanted is IPv4+ (aka IPv4 with bigger address space,
> likely 64bit). Of course we could not extend IPv4, so having
> new protocol is fine.

I don't think you truly mean that having a new protocol is fine.
Because if you did, I think you would treat IPv6 as a completely
different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we
effectively do have a new protocol; IPv6.

IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or
"different" in place of "similar".

> It should just fix problem (do we have other problems I am not aware
> of with IPv4?) of address space and thats it. Im happy with IPv4,
> after 30+ years of usage we pretty much fixed all problems we had.

I disagree.

> The second failure is adoption. Even if my IPv6 hate is not rational,
> adoption of IPv6 is crap. If adoption would be much better, more IPv4
> could be used for legacy networks ;) So stuborn guys like me could
> be happy too ;)

I blame the industry, not the IPv6 protocol, for the lackluster adoption
of IPv6.

> As for details, that list is just my dream IPv6 protocol ;)
>
> But lets talk about details:
> - Loopback on IPv6 is ::1/128
> I have setups where I need more addresses there that are local only.
> Yeah I know, we can put extra aliases on interfaces etc.. but its extra
> work and not w/o problems

How does IPv6 differ from IPv4 in this context?

> - IPv6 Link Local is forced.
> I mean, its always on interface, nevermind you assign static IP.
> LL is still there and gets in the way (OSPFv3... hell yeah)

I agree that IPv6 addresses seem to accumulate on interfaces like IoT
devices do on a network. But I don't see a technical problem with this
in and of itself. -- I can't speak to OSPFv3 issues.

> - ULA space, well.. its like RFC1918 but there are some issues with it
> (or at least was? maybe its fixed) like source IP selection on with
> multiple addresses.

I consider this to be implementation issues and not a problem with the
protocol itself.

> - Neighbor Discovery protocol... quite a bit problems it created.

Please elaborate.

> What was wrong w/ good old ARP? I tought we fixed all those problems
> already like ARP poisoning via port security.. etc

The apparent need to ""fix / address / respond to a protocol problem at
a lower layer seems like a problem to me.

> - NAT is there in IPv6 so no futher comments
> - DHCP start to get working on IPv6.. but it still pain sometimes

What problems do you have with DHCP for IPv6? I've been using it for
the better part of a decade without any known problems. What pain are
you experiencing?

> And biggest problem, interop w/ IPv4 was completly failure.

I agree that the interoperability between IPv4 and IPv6 is the tall pole
in the tent. But I also believe that's to be expected when trying to
interoperate disparate protocols.

From ground zero, I would expect that disparate protocols can't
interoperate without external support, some of which requires explicit
configuration.

> Currently we have best Internet to migrate to new protocol.
> Why?

The primary motivation -- as I understand it -- is the lack of unique IP
addresses.

> Because how internet become centralized. Eyeball networks just
> want to reach content. E2E communication is not that much needed.
> We have games and enhusiast, but those can pay extra for public IPv4.
> Or get VPN/VPS.

Now you are talking about two classes of Internet connectivity:

1) First class participation where an endpoint /is/ /on/ the Internet
with a globally routed IP.
2) Second class participation where an endpoint /has/ /access/ /to/ the
Internet via a non-globally routed IP.

There may be some merit to multiple classes of Internet connectivity.
But I think it should be dealt with openly and above board as such.

> And end comment. I do NOT want to start some kind of flame war here.
> Yeah I know, Im biased toward IPv4.

I don't view honest and good spirited discussion of facts and
understanding to be a flame war. In fact, I view such discussions as a
good thing.

> If something new popups, I want it better than previous thingie (a
> lot) and easier or at least same level of complications, but IPv6
> just solves one thing and brings a lot of complexity.
Please elaborate on the complexity that IPv6 brings that IPv4 didn't
also bring with it in the '90s?

Would the things that you are referring to as IPv6 complexities have
been any different if we had started with IPv6 instead of IPv4 in the
'80s & '90s?

In some ways it seems to me that you are alluding to the legacy code /
equipment / understanding / configuration / what have you. This is
something that many have been dealing with for quite a while. The
mainframe's ability to run code from near half a century ago comes to mind.

> The fact is, IPv6 failed.

I concede that IPv6 has faltered. But I don't believe it's failed. I
don't think it's fair to claim that it has.

> There are probably multiple reasons for it. Do we ever move to
> IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.

You are entitled to your own opinion as much as I'm entitled to mine.
But the key thing to keep in mind is that it's /your/ opinion. The
operative word being "your" as in "you". Your views / opinions /
experiences are /yours/. What's more important is that other people's
views / opinions / experiences may be different.



--
Grant. . . .
unix || die

borg@uu3.net wrote:
> Well, I see IPv6 as double failure really. First, IPv6 itself is too
> different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with
> bigger address space, likely 64bit). Of course we could not extend IPv4,
> so having new protocol is fine.
IPv4 was extendable, with header option as one concept that was shot
down in favor of a new protocol.

If it was just an incremental IPv4 upgrade, than we would have been
there already, and you could be using your extended IPv4 addresses to
communicate with any gear over any network gear that had been upgraded
in the past decade or two.

Its just that the internet was supposed to be able deploy a new protocol
in the same or less time. Which didnt happen.

Joe

> On Sep 24, 2021, at 2:01 AM, borg@uu3.net wrote:
>
> Oh yeah, it would be very funny if this will really happen (new protocol).
> Im not happy with IPv6, and it seems many others too.
>
> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
> more is not always better

Perhaps, but the benefits of a 128 bit address space with a convenient
near universal network/host boundary has benefits. What would be the
perceived benefit of 64-bit addressing over 128?

> - loopback 0:0:0:1/48

Why dedicate a /48 to loopback?

> - soft LL 0:0:1-ffff:0/32 (Link Local)

Having trouble understanding that expression… Wouldn’t it overlap loopback, since
0:0::/32 and 0:0:0::/48 would be overlapping prefixes?

> - RFC1918 address space 0:1-ffff:0:0/16

Why repeat this mistake?

> - keep ARPs, ND wasnt great idea after all?

I don’t see a significant difference (pro or con) to ND vs. ARP.

> - NAT support (because its everywhere these days)

That’s a tragedy of IPv4, I don’t see a benefit to inflicting it on a new protocol.

> - IPv6 -> IPv4 interop (oneway)
> we can put customers on IPv6, while keeping services dualstack

That requires the services to be dual stack which is kind of the problem we have
with IPv6 today… Enough services that matter aren’t dual stack.

> - correct DHCP support (SLAAC wasnt great idea after all?)
> I think its already in IPv6, but was an issue at the begining

Depends on your definition of “correct”. I disagree about SLAAC not being a great
idea. It might not fit every need, but it’s certainly a low-overhead highly useful
mechanism in a lot of deployments.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS concept), so its easy to implement and less
> prone to bugs.
>
> And that IPv6 I would love to see and addapt right away :)

Well.. Present your working prototype on at least two different systems. ;-)

Owen

>
>
> ---------- Original message ----------
>
> From: Joe Maimon <jmaimon@jmaimon.com>
> To: Owen DeLong <owen@delong.com>, Bjrn Mork <bjorn@mork.no>
> Cc: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Thu, 23 Sep 2021 16:26:17 -0400
>
>
>
> Owen DeLong via NANOG wrote:
>>> There are real issues with dual-stack, as this thread started out with.
>>> I don't think there is a need neither to invent IPv6 problems, nor to
>>> promote IPv6 advantages. What we need is a way out of dual-stack-hell.
>> I dont disagree, but a reversion to IPv4-only certainly wont do it.
>
> For everyone who does have enough IPv4 addresses, it does. This is the problem
> in a nutshell. If that starts trending, IPv6 is done.
>
>> I think the only way out is through.
>
> I hope not, both for IPv6 sake and for the network users. We dont know how much
> longer the goal will take, there is materializing a real possibility we will
> never quite reach it, and the potholes on the way are pretty rough.
>
> And as the trip winds on, the landscape is changing, not necessarily for the
> better.
>
> One more "any decade now" and another IPv4 replacement/extension might just
> happen on the scene and catch on, rendering IPv6 the most wasteful global
> technical debacle to date.
>
>
>> Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>>
>> Owen
>
> You say that as if it was a surprise, when it should not have been, and you say
> that as if something can be done about it, which we should know by now cannot be
> the primary focus, since it cannot be done in any timely fashion. If at all.
>
> Its time to throw mud on the wall and see what sticks. Dual stack and wait is an
> ongoing failure slouching to disaster.
>
> Joe
>
>
>
>

> On Sep 24, 2021, at 9:56 AM, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>
>
> Owen DeLong wrote:
>>
>>> On Sep 23, 2021, at 13:26 , Joe Maimon <jmaimon@jmaimon.com> wrote:
>>>
>>>
>>> I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty rough.
>> By “the only way out is through” I meant that the only way we can get back to anything resembling mono-stack is, in fact, to complete the transition to IPv6.
>
> The question is how? Waiting for everyone or nearly everyone to dual stack, the current strategy, is awful. Like pulling gum off a shoe.

Agreed, so the question boils down to what can be done to motivate the laggard content providers to get off the dime.

>>> And as the trip winds on, the landscape is changing, not necessarily for the better.
>> The IPv4 landscape will continue to get worse and worse. It cannot possibly get better, there just aren’t enough addresses for that.
>
> I was referring to the more general network landscape, the governance system, the end of p2p, balkanization, etc, all trends and shifts that become more likely and entrenched the longer IPv6 lags and the scarcer IPv4 becomes.
>
>>
>>> One more "any decade now" and another IPv4 replacement/extension might just happen on the scene and catch on, rendering IPv6 the most wasteful global technical debacle to date.
>> If that’s what it takes to move forward with a protocol that has enough addresses, then so be it. I’m not attached to IPv6 particularly, but I recognize that IPv4 can’t keep up. As such, IPv6 is just the best current candidate. If someone offers a better choice, I’m all for it.
>
> Whose to say it would be a proper p2p system? I know you believe strongly in that and want it fully restored, at least on the protocol level.

There are so many potential useful things we could do with a restored e2e system that are simply not proactical today that yes, I consider that vital.

For one thing, I’m really tired of vendor cloud locking just because products need rendezvous hosts with public addresses.

>>>> Unfortunately, the IPv6 resistant forces
>>>> are making that hard for everyone else.
>>>>
>>>> Owen
>>> You say that as if it was a surprise, when it should not have been, and you say that as if something can be done about it, which we should know by now cannot be the primary focus, since it cannot be done in any timely fashion. If at all.
>> It’s not a surprise, but it is a tragedy.
>>
>> There are things that can be done about it, but nobody currently wants to do them.
>
> So lets make the conversation revolve around what can be done to actually advance IPv6, and what we should know by now is that convincing or coercing deployment with the current state of affairs does not have enough horsepower to get IPv6 anywhere far anytime soon.

I’m open to alternatives if you have any to offer.

>>> Its time to throw mud on the wall and see what sticks. Dual stack and wait is an ongoing failure slouching to disaster.
>> IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant among us remain in denial about that.
>
> Who is this "us"? Anybody even discussing IPv6 in a public forum is well ahead of the curve. Unfortunately. All early adopters. Real Early.

Everybody using the internet, but more importantly, the content providers that are resisting IPv6 deployment on their content are probably the biggest problem at this time.

>> At some point, we are going to have to make a choice about how much longer we want to keep letting them hold us back. It will not be an easy choice, it will not be convenient, and it will not be simple.
>>
>> The question is how much more pain an dhow much longer will it take before the choice becomes less difficult than the wait?
>>
>> Owen
>>
> Exactly what does this choice look like? Turn off IPv4 when its fully functional? Only the have-nots may make the choice not to deploy IPv4 sometime in the future, and for them, its not going to be a real choice.

IPv4 hasn’t been fully functional for more than a decade. At some point, the pain of continuing to wait for the laggards will become sufficient that those who have been running dual-stack will simply turn off IPv4 and leave the laggards behind. It might tragically not happen in my lifetime, but it has to happen at some point.

Owen

> On Sep 24, 2021, at 10:53 AM, borg@uu3.net wrote:
>
> Well, I see IPv6 as double failure really. First, IPv6 itself is too
> different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with
> bigger address space, likely 64bit). Of course we could not extend IPv4,
> so having new protocol is fine. It should just fix problem (do we have other
> problems I am not aware of with IPv4?) of address space and thats it.
> Im happy with IPv4, after 30+ years of usage we pretty much fixed all
> problems we had.

Lack of address space is a key problem with IPv4 resolved by IPv6.
Lack of address transparency is another one, but that’s largely a side-effect
of the hacks applied to try and (temporarily cope with the first one). (also
solved by IPv6)
Inability to scale routing by using topology indicators separate from addresses
is a problem inherent in both IPv4 and IPv6. No, I do not consider that the
various hacks that have been applied on this, including LISP, are a solution.
Zeroconf in IPv4 is quite a bit less functional than in IPv6.
PMTU-D is a problem in both protocols, but in some ways, not quite as bad in IPv6.

> As for details, that list is just my dream IPv6 protocol ;)
> But lets talk about details:
> - Loopback on IPv6 is ::1/128
> I have setups where I need more addresses there that are local only.
> Yeah I know, we can put extra aliases on interfaces etc.. but its extra
> work and not w/o problems

I haven’t had a problem assigining additional lo addresses, but whatever.
I think wasting an entire /8 on loopbacks was utterly stupid. Do you have
any situation where you need more than 18 quintillion loopbacks? If not,
then an IPv6 /64 would be fine worst case. (0:0:0:1::/64?)
> - IPv6 Link Local is forced.
> I mean, its always on interface, nevermind you assign static IP.
> LL is still there and gets in the way (OSPFv3... hell yeah)
How is it in the way? It’s quite useful and utilitarian.
OSPFv3 uses LL because it doesn’t want to risk having its traffic forwarded
off-link and this guarantees that it won’t.

> - ULA space, well.. its like RFC1918 but there are some issues with it
> (or at least was? maybe its fixed) like source IP selection on with
> multiple addresses.

Isn’t that an issue in IPv4 if you assign a host a 1918 address and a GUA
on the same interface, too?

Bottom line, if you have GUA, ULA is mostly pointless in most scenarios.
This isn’t a problem unique to IPv6, save for the fact that you don’t
usually have the option of putting GUA where you put RFC-1918 because
if you have GUA, you don’t usually want 1918. So I really don’t see
any difference here other than the fact that IPv6 gives you an additional
choice you don’t generally have in IPv4, but that choice does come with
some additional tradeoffs.

> - Neighbor Discovery protocol... quite a bit problems it created.
> What was wrong w/ good old ARP? I tought we fixed all those problems
> already like ARP poisoning via port security.. etc

What are the problems you’re seeing with ND? In my experience, it mostly
just works.

> - NAT is there in IPv6 so no futher comments

Sadly, this is true. The good news is that hardly anyone uses it and
most people doing IPv6 seem to understand that it’s a really bad idea.

> - DHCP start to get working on IPv6.. but it still pain sometimes

I haven’t seen anything in DHCPv6 that is significantly harder than in
IPv4 other than the need to chase the DUID format that a particular
host uses in order to set up a fixed address.

> And biggest problem, interop w/ IPv4 was completly failure.
> Currently we have best Internet to migrate to new protocol.
> Why? Because how internet become centralized. Eyeball networks
> just want to reach content. E2E communication is not that much needed.
> We have games and enhusiast, but those can pay extra for public IPv4.
> Or get VPN/VPS.

Lots of possibilities were discussed, but it boiled down to the eventual
realization that there is mathematically no way to put a 128 bit
address into a 32 bit field without loss of information.

I bet any solution you can theorize ends up dying due to a variant
of the above issue.

> And end comment. I do NOT want to start some kind of flame war here.
> Yeah I know, Im biased toward IPv4. If something new popups, I want it
> better than previous thingie (a lot) and easier or at least same level of
> complications, but IPv6 just solves one thing and brings a lot of
> complexity.

I have implemented IPv6 in a lot of environments and other than the complexities
around vendors doing a poor job of implementation, I haven’t encountered any
complexity that I couldn’t relate to the same problem in IPv4.

Can you elaborate on these supposed complexities and how they have actually
impacted you in real world scenarios? Perhaps the issues you’ve encountered
can be addressed in a useful way.

> The fact is, IPv6 failed. There are probably multiple reasons for it.
> Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4
> works for me for now.

Many of us have moved to IPv6 and for eyeball sites that have deployed it,
more than 50% of most traffic flows over IPv6.

I think its telling that India is at roughly 97% IPv6 deployment. By the
time internet was developing in India, APNIC was mostly out of addresses.
This coupled with the previous regulatory environment for internet services
in India severely crippled India’s access to iPv4 addresses.

I know of multiple enterprises in the US that are now deploying IPv6 at
least at their edge in order to work with developers in India.

India is a microcosm of what is to come in the developing world.

The US is at roughly 47% IPv6 eyeballs preferred today. There is going
to come a time when we start having IPv6-only eyeballs in the US and
other parts of the world. How painful or problematic that becomes will
depend on a large extent to how content providers react to this
situation over the next few years.

Owen

>
>
> ---------- Original message ----------
>
> From: Grant Taylor via NANOG <nanog@nanog.org>
> To: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Fri, 24 Sep 2021 10:17:42 -0600
>
> On 9/24/21 3:01 AM, borg@uu3.net wrote:
>> Oh yeah, it would be very funny if this will really happen (new protocol).
>> Im not happy with IPv6, and it seems many others too.
>
> Is your dissatisfaction with the IPv6 protocol itself or is your dissatisfaction
> with the deployment / adoption of the IPv6 protocol?
>
> I think that it's a very critical distinction. Much like DoH as a protocol vs
> how some companies have chosen to utilize it. Similar to IBM's computers vs
> what they were used for in the 1940's.
>
>> This is short list how my ideal IPv6 proto looks like:
>> - 64bit address space
>> more is not always better
>> - loopback 0:0:0:1/48
>> - soft LL 0:0:1-ffff:0/32 (Link Local)
>> - RFC1918 address space 0:1-ffff:0:0/16
>> - keep ARPs, ND wasnt great idea after all?
>> - NAT support (because its everywhere these days)
>> - IPv6 -> IPv4 interop (oneway)
>> we can put customers on IPv6, while keeping services dualstack
>> - correct DHCP support (SLAAC wasnt great idea after all?)
>> I think its already in IPv6, but was an issue at the begining
>
> I'm probably showing my ignorance, but I believe that the IPv6 that we have
> today effectively does all of those things. At least functionality, perhaps
> with different values.
>
>> If there are some weird requirements from others, put them into layer up.
>> L3 needs to be simple (KISS concept), so its easy to implement and less
>> prone to bugs.
>
> How many of the hurtles to IPv6's deployment have been bugs in layer 3? It seems
> to me that most of the problems with IPv6 that I'm aware of are at other layers,
> significantly higher in, or on top of, the stack.
>
>> And that IPv6 I would love to see and addapt right away :)
>
> I'm of the opinion that IPv6 has worked quite well dual stack from about
> 2005-2015. It's only been in the last 5 or so years that I'm starting to see
> more problems with IPv6. And all of the problems that I'm seeing are companies
> making business level decisions, way above layer 7, that negatively impact IPv6.
> Reluctance to run an MX on IPv6 for business level decisions is definitely not a
> protocol, much less L3, problem.
>
>
>
> --
> Grant. . . .
> unix || die

Well, I think we should not compare IPX to IPv4 because those protocols
were made to handle completly different networks?

Yeah, IPv6 is new, but its more like revolution instead of evolution.

Well, Industry seems to addapt things quickly when they are good enough.
Better things replace worse. Of course its not always the case, sometimes
things are being forced here.. And thats how I feel about IPv6..

IPv4 Lookback is 127.0.0.1/8
You can use bind IPs within range by applications. Handy
In IPv6 its not the case.

IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
Tables overflows, attacks and DDoS.. Why to repeat history again?

IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some
issues. If this is not the case, im sorry. Its been a while when I last time
played with IPv6...

IPv6 interop: yeah, I agree here.. But people involved with IPv6 should
think about some external IPv4 interop.. Internet was exploding at 1997..
Maybe they had hope that everyone upgrade like in CIDR case. And maybe it
could happen if IPv6 wasnt so alien ;)

As for IPv4 vs IPv6 complexity, again, why repeat history. Biggest IPv4
mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
(Another big mistake was class E reservation...)
Internet was tiny at that time so everyone followed.
Image something like this today? Same about IPv6.. it brings
forced network::endpoint probably due to IoT, sacrificing flexibility.

Again, I dont want to really defend my standpoint here. Its too late for
that. I kinda regret now dropping into discussion...


---------- Original message ----------

From: Grant Taylor via NANOG <nanog@nanog.org>
To: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Fri, 24 Sep 2021 14:26:27 -0600

On 9/24/21 11:53 AM, borg@uu3.net wrote:
> Well, I see IPv6 as double failure really.

I still feel like you are combining / conflating two distinct issues into one
generalization.

> First, IPv6 itself is too different from IPv4.

Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta
between IPv4 and IPX?

If anything, I think the delta between IPv4 and IPv6 is too small. Small enough
that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction
between the multiple personalities therein. I also think that the grouping of
IPv4 and IPv6 as one protocol is part of the downfall.

More over if you think of IPv4 and IPv6 dual stack as analogous to the
multi-protocol networks of the '90s, and treat them as disparate protocols that
serve similar purposes in (completely) different ways, a lot of the friction
seems to make sense and as such becomes less friction through understanding and
having reasonable expectations for the disparate protocols.

> What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely
> 64bit). Of course we could not extend IPv4, so having new protocol is fine.

I don't think you truly mean that having a new protocol is fine. Because if you
did, I think you would treat IPv6 as a completely different protocol from IPv4.
E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol;
IPv6.

IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or
"different" in place of "similar".

> It should just fix problem (do we have other problems I am not aware of with
> IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of
> usage we pretty much fixed all problems we had.

I disagree.

> The second failure is adoption. Even if my IPv6 hate is not rational, adoption
> of IPv6 is crap. If adoption would be much better, more IPv4 could be used for
> legacy networks ;) So stuborn guys like me could be happy too ;)

I blame the industry, not the IPv6 protocol, for the lackluster adoption of
IPv6.

> As for details, that list is just my dream IPv6 protocol ;)
>
> But lets talk about details:
> - Loopback on IPv6 is ::1/128
> I have setups where I need more addresses there that are local only.
> Yeah I know, we can put extra aliases on interfaces etc.. but its extra
> work and not w/o problems

How does IPv6 differ from IPv4 in this context?

> - IPv6 Link Local is forced.
> I mean, its always on interface, nevermind you assign static IP.
> LL is still there and gets in the way (OSPFv3... hell yeah)

I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do
on a network. But I don't see a technical problem with this in and of itself.
-- I can't speak to OSPFv3 issues.

> - ULA space, well.. its like RFC1918 but there are some issues with it
> (or at least was? maybe its fixed) like source IP selection on with
> multiple addresses.

I consider this to be implementation issues and not a problem with the protocol
itself.

> - Neighbor Discovery protocol... quite a bit problems it created.

Please elaborate.

> What was wrong w/ good old ARP? I tought we fixed all those problems
> already like ARP poisoning via port security.. etc

The apparent need to ""fix / address / respond to a protocol problem at a lower
layer seems like a problem to me.

> - NAT is there in IPv6 so no futher comments
> - DHCP start to get working on IPv6.. but it still pain sometimes

What problems do you have with DHCP for IPv6? I've been using it for the better
part of a decade without any known problems. What pain are you experiencing?

> And biggest problem, interop w/ IPv4 was completly failure.

I agree that the interoperability between IPv4 and IPv6 is the tall pole in the
tent. But I also believe that's to be expected when trying to interoperate
disparate protocols.

From ground zero, I would expect that disparate protocols can't interoperate
without external support, some of which requires explicit configuration.

> Currently we have best Internet to migrate to new protocol. Why?

The primary motivation -- as I understand it -- is the lack of unique IP
addresses.

> Because how internet become centralized. Eyeball networks just want to reach
> content. E2E communication is not that much needed. We have games and
> enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.

Now you are talking about two classes of Internet connectivity:

1) First class participation where an endpoint /is/ /on/ the Internet with a
globally routed IP.
2) Second class participation where an endpoint /has/ /access/ /to/ the
Internet via a non-globally routed IP.

There may be some merit to multiple classes of Internet connectivity. But I
think it should be dealt with openly and above board as such.

> And end comment. I do NOT want to start some kind of flame war here. Yeah I
> know, Im biased toward IPv4.

I don't view honest and good spirited discussion of facts and understanding to
be a flame war. In fact, I view such discussions as a good thing.

> If something new popups, I want it better than previous thingie (a lot) and
> easier or at least same level of complications, but IPv6 just solves one thing
> and brings a lot of complexity.
Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring
with it in the '90s?

Would the things that you are referring to as IPv6 complexities have been any
different if we had started with IPv6 instead of IPv4 in the '80s & '90s?

In some ways it seems to me that you are alluding to the legacy code / equipment
/ understanding / configuration / what have you. This is something that many
have been dealing with for quite a while. The mainframe's ability to run code
from near half a century ago comes to mind.

> The fact is, IPv6 failed.

I concede that IPv6 has faltered. But I don't believe it's failed. I don't
think it's fair to claim that it has.

> There are probably multiple reasons for it. Do we ever move to IPv6? I dont
> know.. Do I care for now? Nope, IPv4 works for me for now.

You are entitled to your own opinion as much as I'm entitled to mine. But the
key thing to keep in mind is that it's /your/ opinion. The operative word being
"your" as in "you". Your views / opinions / experiences are /yours/. What's
more important is that other people's views / opinions / experiences may be
different.



--
Grant. . . .
unix || die

Because IPv4 loopback is 127.0.0.1/8 and its usefull?

0:0:1-ffff:0/32 means you generate addreses from
that range and not necessary using /32 prefix..
It just range thats reserved for LL.

Same about RFC1918 aka space.. its a range reserved for local addreses.

The whole rationale is:
- shorter prefix wins (so no overlap?)
- you can use nice short addreses like ::1234 for loopback
or ::1:aaaa for LL or ::1:0:1234 for RFC1918 like

Whole ::1 short format should be used only to cut leading zeros
not "more zeroes whatnever they appear".

ND is new thing and it requires new things to protect it from attacks?

While all the hate towards NAT, after years of using it I see it as cool
thing now. Yeah it breaks E2E, and thats why its place is only at CPE.
The true tragedy is CGN.

Yeah, services make money so they should addapt new protocol, so users
can access those services. In my opinion, due to IPv4 exhaustion, this
is right adoption scheme. You move users to IPv6 and free IPv4 addresses
for more services. It means internet can still grow and noone is really cut
off. Once IPv6 mass is big enough, you can start to fade IPv4 services.

Prototype yeah... if only this would be 1997 again... ;)


---------- Original message ----------

From: Owen DeLong <owen@delong.com>
To: borg@uu3.net
Cc: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Fri, 24 Sep 2021 17:24:29 -0700



> On Sep 24, 2021, at 2:01 AM, borg@uu3.net wrote:
>
> Oh yeah, it would be very funny if this will really happen (new protocol).
> Im not happy with IPv6, and it seems many others too.
>
> This is short list how my ideal IPv6 proto looks like:
> - 64bit address space
> more is not always better

Perhaps, but the benefits of a 128 bit address space with a convenient
near universal network/host boundary has benefits. What would be the
perceived benefit of 64-bit addressing over 128?

> - loopback 0:0:0:1/48

Why dedicate a /48 to loopback?

> - soft LL 0:0:1-ffff:0/32 (Link Local)

Having trouble understanding that expression?? Wouldn??t it overlap loopback, since
0:0::/32 and 0:0:0::/48 would be overlapping prefixes?

> - RFC1918 address space 0:1-ffff:0:0/16

Why repeat this mistake?

> - keep ARPs, ND wasnt great idea after all?

I don??t see a significant difference (pro or con) to ND vs. ARP.

> - NAT support (because its everywhere these days)

That??s a tragedy of IPv4, I don??t see a benefit to inflicting it on a new protocol.

> - IPv6 -> IPv4 interop (oneway)
> we can put customers on IPv6, while keeping services dualstack

That requires the services to be dual stack which is kind of the problem we have
with IPv6 today?? Enough services that matter aren??t dual stack.

> - correct DHCP support (SLAAC wasnt great idea after all?)
> I think its already in IPv6, but was an issue at the begining

Depends on your definition of ??correct??. I disagree about SLAAC not being a great
idea. It might not fit every need, but it??s certainly a low-overhead highly useful
mechanism in a lot of deployments.

> If there are some weird requirements from others, put them into layer up.
> L3 needs to be simple (KISS concept), so its easy to implement and less
> prone to bugs.
>
> And that IPv6 I would love to see and addapt right away :)

Well.. Present your working prototype on at least two different systems. ;-)

Owen

>
>
> ---------- Original message ----------
>
> From: Joe Maimon <jmaimon@jmaimon.com>
> To: Owen DeLong <owen@delong.com>, Bjrn Mork <bjorn@mork.no>
> Cc: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Thu, 23 Sep 2021 16:26:17 -0400
>
>
>
> Owen DeLong via NANOG wrote:
>>> There are real issues with dual-stack, as this thread started out with.
>>> I don't think there is a need neither to invent IPv6 problems, nor to
>>> promote IPv6 advantages. What we need is a way out of dual-stack-hell.
>> I dont disagree, but a reversion to IPv4-only certainly wont do it.
>
> For everyone who does have enough IPv4 addresses, it does. This is the problem
> in a nutshell. If that starts trending, IPv6 is done.
>
>> I think the only way out is through.
>
> I hope not, both for IPv6 sake and for the network users. We dont know how much
> longer the goal will take, there is materializing a real possibility we will
> never quite reach it, and the potholes on the way are pretty rough.
>
> And as the trip winds on, the landscape is changing, not necessarily for the
> better.
>
> One more "any decade now" and another IPv4 replacement/extension might just
> happen on the scene and catch on, rendering IPv6 the most wasteful global
> technical debacle to date.
>
>
>> Unfortunately, the IPv6 resistant forces
>> are making that hard for everyone else.
>>
>> Owen
>
> You say that as if it was a surprise, when it should not have been, and you say
> that as if something can be done about it, which we should know by now cannot be
> the primary focus, since it cannot be done in any timely fashion. If at all.
>
> Its time to throw mud on the wall and see what sticks. Dual stack and wait is an
> ongoing failure slouching to disaster.
>
> Joe
>
>
>
>

On Sat, 25 Sept 2021 at 11:10, <borg@uu3.net> wrote:

> Because IPv4 loopback is 127.0.0.1/8 and its usefull?
>

I am not sure why it is useful but nothing stops you from adding more
loopback addresses:

root@jump2:~# ip addr add ::2/128 dev lo
root@jump2:~# ping6 ::2
PING ::2(::2) 56 data bytes
64 bytes from ::2: icmp_seq=1 ttl=64 time=0.043 ms

While I am not sure what use extra addresses from the 127.0.0.0/8 prefix are
on the loopback, it is quite common for us to add extra global addresses
and then use that with proxy arp. Of course that is only necessary on IPv4
since IPv6 isn't so restrained that we have to save every last address bit
using tricks.


>
> - you can use nice short addreses like ::1234 for loopback
>

root@jump2:~# ip addr add ::1234/128 dev lo
root@jump2:~# ping6 ::1234
PING ::1234(::1234) 56 data bytes
64 bytes from ::1234: icmp_seq=1 ttl=64 time=0.046 ms

:-)


> or ::1:aaaa for LL or ::1:0:1234 for RFC1918 like
>

With IPv6 you can use fe80::1:aaaa for link local and fd00::1:0:1234 for
your RFC1918 like setup. And then you can use 1:1 NAT to transform that to
GUA on the router. Even NAT, if you insist on using it, is better with IPv6.

The confusion here appears to be that auto generated link local prefixes
are long with many hex digits. But compared to the new proposal, which
could have no auto generated link local due to having too few bits, there
is nothing that stops you from manually assigning link local addresses. It
is just that nobody wants to bother with that and you wouldn't either.

Example:

root@jump2:~# ip addr add fe80::1:aaaa/64 dev eth0
root@jump2:~# ping6 fe80::1:aaaa%eth0
PING fe80::1:aaaa%eth0(fe80::1:aaaa) 56 data bytes
64 bytes from fe80::1:aaaa: icmp_seq=1 ttl=64 time=0.033 ms



> ND is new thing and it requires new things to protect it from attacks?
>

I am not aware of any NDP attacks that would be any different if based on
ARP. Those two protocols are practically the same.

Regards,

Baldur

> On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
>
> Well, I think we should not compare IPX to IPv4 because those protocols
> were made to handle completly different networks?
>
> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>
> Well, Industry seems to addapt things quickly when they are good enough.
> Better things replace worse. Of course its not always the case, sometimes
> things are being forced here.. And thats how I feel about IPv6..

Sometimes worse things replace better. NAT, for example was definitely not
an improvement to IPv4. It was a necessary evil intended to be a temporary
fix.

>
> IPv4 Lookback is 127.0.0.1/8
> You can use bind IPs within range by applications. Handy
> In IPv6 its not the case.

You are free to assign any additional IPv6 addresses you like to the loopback
interface and then bind them to applications. Personally, I haven’t found a
particularly good use for this, but it is possible.

It does mean that instead of wasting 1/256th of the entire address space
in every context on loopbacks, you have to assign what you need there,
but you can easily assign a /64 prefix to a loopback interface and have
applications bind within range.

> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
> Tables overflows, attacks and DDoS.. Why to repeat history again?

Table overflows weren’t fixed in IPv4 and have nothing to do with ND vs.
ARP. Table overflows are (not really an issue in my experience) the
result of a larger address space than the memory available for the L2
forwarding table on switches or the ND table on hosts. This isn’t due
to a difference in ND vs. ARP. It is due to the fact that there are no
64-bit networks in IPv4, but they are commonplace in IPv6.

Mostly this has been solved in software by managing table discards more
effectively.

> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some
> issues. If this is not the case, im sorry. Its been a while when I last time
> played with IPv6...

I am using IPv6 and I’m using IPv6 DHCP. I haven’t encountered any significant
problems with it other than some minor inconveniences introduced by the ability
to have different DUID types and vendors doing semi-obnoxious things along that
line.

> IPv6 interop: yeah, I agree here.. But people involved with IPv6 should
> think about some external IPv4 interop.. Internet was exploding at 1997..
> Maybe they had hope that everyone upgrade like in CIDR case. And maybe it
> could happen if IPv6 wasnt so alien ;)

It was thought about… It was considered. It was long pondered. Problem was,
nobody could come up with a way to overcome the fact that you can’t put
128 bits of data in a 32 bit field without loss.

IPv6 really isn’t so alien, so I don’t buy that argument. The software changes
necessary to implement IPv6 were significantly bigger than CIDR and IPv6
affected applications, not just network. There was no way around these
two facts. The IPv6 network stack did get adopted and implemented nearly
as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support
for quite some time now at the network stack level. It is applications and
content providers that are lagging and they never did anything for CIDR.

> As for IPv4 vs IPv6 complexity, again, why repeat history.

What complexity?

> Biggest IPv4
> mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.

No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been
inconvenient in hardware at the time, but it would have made IPv4 much more
scalable and would have allowed it to last significantly longer.

> (Another big mistake was class E reservation...)

Not really. It was a decision that made sense at the time. Class D reservation
made sense originally too. Without it, we wouldn’t have had addresses available
to experiment with or develop multicast.

There was no way to know at the time that decision was made that IPv4 would run
out of addresses before it would find some new thing to experiment with.

> Internet was tiny at that time so everyone followed.

Followed what, exactly?

> Image something like this today? Same about IPv6.. it brings
> forced network::endpoint probably due to IoT, sacrificing flexibility.

I can’t parse this into a meaningful comment. Can you clarify please?
What is “forced network::endpoint” supposed to mean and what does it
have to do with IoT? What flexibility has been sacrificed?

> Again, I dont want to really defend my standpoint here. Its too late for
> that. I kinda regret now dropping into discussion...

OK, so you want to make random comments which are not even necessarily
true and then walk away from the discussion? I have trouble understanding
that perspective.

I’m not trying to bash your position or you. I’m trying to understand your
objections, figure out which ones are legitimate criticism of IPv6, which
ones are legitimate criticism, but not actually IPv6, and which ones
are simply factually incorrect. For the last category, I presume that comes
from your lack of actual IPv6 experience or some other form of ignorance
and I’d like to attempt useful education to address those.

Owen

>
>
> ---------- Original message ----------
>
> From: Grant Taylor via NANOG <nanog@nanog.org>
> To: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Fri, 24 Sep 2021 14:26:27 -0600
>
> On 9/24/21 11:53 AM, borg@uu3.net wrote:
>> Well, I see IPv6 as double failure really.
>
> I still feel like you are combining / conflating two distinct issues into one
> generalization.
>
>> First, IPv6 itself is too different from IPv4.
>
> Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta
> between IPv4 and IPX?
>
> If anything, I think the delta between IPv4 and IPv6 is too small. Small enough
> that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction
> between the multiple personalities therein. I also think that the grouping of
> IPv4 and IPv6 as one protocol is part of the downfall.
>
> More over if you think of IPv4 and IPv6 dual stack as analogous to the
> multi-protocol networks of the '90s, and treat them as disparate protocols that
> serve similar purposes in (completely) different ways, a lot of the friction
> seems to make sense and as such becomes less friction through understanding and
> having reasonable expectations for the disparate protocols.
>
>> What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely
>> 64bit). Of course we could not extend IPv4, so having new protocol is fine.
>
> I don't think you truly mean that having a new protocol is fine. Because if you
> did, I think you would treat IPv6 as a completely different protocol from IPv4.
> E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol;
> IPv6.
>
> IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or
> "different" in place of "similar".
>
>> It should just fix problem (do we have other problems I am not aware of with
>> IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of
>> usage we pretty much fixed all problems we had.
>
> I disagree.
>
>> The second failure is adoption. Even if my IPv6 hate is not rational, adoption
>> of IPv6 is crap. If adoption would be much better, more IPv4 could be used for
>> legacy networks ;) So stuborn guys like me could be happy too ;)
>
> I blame the industry, not the IPv6 protocol, for the lackluster adoption of
> IPv6.
>
>> As for details, that list is just my dream IPv6 protocol ;)
>>
>> But lets talk about details:
>> - Loopback on IPv6 is ::1/128
>> I have setups where I need more addresses there that are local only.
>> Yeah I know, we can put extra aliases on interfaces etc.. but its extra
>> work and not w/o problems
>
> How does IPv6 differ from IPv4 in this context?
>
>> - IPv6 Link Local is forced.
>> I mean, its always on interface, nevermind you assign static IP.
>> LL is still there and gets in the way (OSPFv3... hell yeah)
>
> I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do
> on a network. But I don't see a technical problem with this in and of itself.
> -- I can't speak to OSPFv3 issues.
>
>> - ULA space, well.. its like RFC1918 but there are some issues with it
>> (or at least was? maybe its fixed) like source IP selection on with
>> multiple addresses.
>
> I consider this to be implementation issues and not a problem with the protocol
> itself.
>
>> - Neighbor Discovery protocol... quite a bit problems it created.
>
> Please elaborate.
>
>> What was wrong w/ good old ARP? I tought we fixed all those problems
>> already like ARP poisoning via port security.. etc
>
> The apparent need to ""fix / address / respond to a protocol problem at a lower
> layer seems like a problem to me.
>
>> - NAT is there in IPv6 so no futher comments
>> - DHCP start to get working on IPv6.. but it still pain sometimes
>
> What problems do you have with DHCP for IPv6? I've been using it for the better
> part of a decade without any known problems. What pain are you experiencing?
>
>> And biggest problem, interop w/ IPv4 was completly failure.
>
> I agree that the interoperability between IPv4 and IPv6 is the tall pole in the
> tent. But I also believe that's to be expected when trying to interoperate
> disparate protocols.
>
>> From ground zero, I would expect that disparate protocols can't interoperate
> without external support, some of which requires explicit configuration.
>
>> Currently we have best Internet to migrate to new protocol. Why?
>
> The primary motivation -- as I understand it -- is the lack of unique IP
> addresses.
>
>> Because how internet become centralized. Eyeball networks just want to reach
>> content. E2E communication is not that much needed. We have games and
>> enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
>
> Now you are talking about two classes of Internet connectivity:
>
> 1) First class participation where an endpoint /is/ /on/ the Internet with a
> globally routed IP.
> 2) Second class participation where an endpoint /has/ /access/ /to/ the
> Internet via a non-globally routed IP.
>
> There may be some merit to multiple classes of Internet connectivity. But I
> think it should be dealt with openly and above board as such.
>
>> And end comment. I do NOT want to start some kind of flame war here. Yeah I
>> know, Im biased toward IPv4.
>
> I don't view honest and good spirited discussion of facts and understanding to
> be a flame war. In fact, I view such discussions as a good thing.
>
>> If something new popups, I want it better than previous thingie (a lot) and
>> easier or at least same level of complications, but IPv6 just solves one thing
>> and brings a lot of complexity.
> Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring
> with it in the '90s?
>
> Would the things that you are referring to as IPv6 complexities have been any
> different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
>
> In some ways it seems to me that you are alluding to the legacy code / equipment
> / understanding / configuration / what have you. This is something that many
> have been dealing with for quite a while. The mainframe's ability to run code
> from near half a century ago comes to mind.
>
>> The fact is, IPv6 failed.
>
> I concede that IPv6 has faltered. But I don't believe it's failed. I don't
> think it's fair to claim that it has.
>
>> There are probably multiple reasons for it. Do we ever move to IPv6? I dont
>> know.. Do I care for now? Nope, IPv4 works for me for now.
>
> You are entitled to your own opinion as much as I'm entitled to mine. But the
> key thing to keep in mind is that it's /your/ opinion. The operative word being
> "your" as in "you". Your views / opinions / experiences are /yours/. What's
> more important is that other people's views / opinions / experiences may be
> different.
>
>
>
> --
> Grant. . . .
> unix || die

> On Sep 25, 2021, at 02:10 , borg@uu3.net wrote:
>
> Because IPv4 loopback is 127.0.0.1/8 and its usefull?

How so? Where do you actually use 16.7 million loopback addresses, let
alone 18 Quitillion+ * 65536 (/48)?

>
> 0:0:1-ffff:0/32 means you generate addreses from
> that range and not necessary using /32 prefix..
> It just range thats reserved for LL.

So you want to reserve the range 0:0:1:0..0:0:ffff:0 with all zeros in the last
16 bits as loopback? Why the (effectively discontiguous net mask)?
Why not include 0:0:0:0 in it?

Sorry, not trying to rain on your parade, but trying to understand your thinking here.

> Same about RFC1918 aka space.. its a range reserved for local addreses.

My point was why repeat the RFC-1918 mistake. There’s really no need for
it unless you intend to recreate the NAT problems.

Further, you specified:
0:0:0:1/48 as loopback, that’s the range 0:0:0:0..0:0:0:ffff in your proposed
addressing structure.

0:0:1-ffff:0/16 as RFC-1918, that’s an odd way of notating 0:0:0:0..0:ffff:ffff:ffff
in your proposed addressing structure. As such, your meaning is unclear.

So it’s unclear how you intend to map ranges and netmxasks in your proposal.

> The whole rationale is:
> - shorter prefix wins (so no overlap?)

Usually longest matching prefix wins, but when you’re talking about the distinction
between RFC-1918 and loopback, I think overlap poses a human factors problem
that you haven’t considered.

> - you can use nice short addreses like ::1234 for loopback
> or ::1:aaaa for LL or ::1:0:1234 for RFC1918 like

Not to put too fine a point on it, but ::1 works in IPv6 today. If you want, you
are free to assign anything else you want on the loopback interface, so for
example, you could assign fd:0:0:1::/64 to the loopback interface and use
any address you want from fd:0:0:1::0 through fd:0:0:1:ffff:ffff:ffff:ffff as
loopback addresses. (I don’t see a point in using GUA for loopback as long
as the ULA silliness exists. In fact, this might be the one and only legitimate
use case I can see for ULA.)

For RFC1918, you can make up anything you want within fd::/8 in IPv6
as it exists today. Ideally, you choose a randomized /48 from fd::/8 and
subnet that along /64 boundaries, but I don’t see that as significantly more
complex than what I think you are proposing.

> Whole ::1 short format should be used only to cut leading zeros
> not "more zeroes whatnever they appear".

Why? The current format allows you to put the :: wherever you think
it makes the most sense and as long as there’s only one :: in an
address (which is a requirement), there’s no ambiguity about the
number of 0s replaced.

Yes, it makes textual comparison of addresses messy, but there’s
really no need for that. Far better use textual representations only
for user presentation anyway. Internally, they should always be
stored/handled as a 128-bit unsigned integer value.

So the fact that:

2001:db8:0:1::5
2001:db8::1:0:0:0:5

Are two different ways of representing the same address isn’t
of any concern unless you’re making the mistake of trying to
string wise compare them in their text-representation format.
Both equate to the same uint128_t value.

> ND is new thing and it requires new things to protect it from attacks?

Not so much.

The defined ND attacks aren’t new for ND. They all exist in ARP as well.
What is new is 64-bit wide network segments. If you put a /6 on a switch
in IPv4 and then do an ARP scan, you’ll get the same table overflow
problems as you are talking about with “ND attacks”. The difference is
that in IPv4, /6 networks are extraordinarily rare (if any exist at all) while
it is commonplace in IPv6 to have /64 network segments.

Nonetheless, this isn’t actually inherent in the difference between ND ad
ARP, it is inherent in the difference between network segments limited
to 1024 possible host addresses or less and network segments that have
more than 18 Quintillion possible host addresses.

In fact, if you’re really super-worried about this (which isn’t really a thing
in most environments, TBH), you can create your IPv6 networks as /120s
or /118s or whatever and simply limit the total number of available host
addresses. You have to give up some IPv6 features that don’t exist in
IPv4 anyway, but ND will still work and you won’t have to worry about
table overflows any more than you did in IPv4.

> While all the hate towards NAT, after years of using it I see it as cool
> thing now. Yeah it breaks E2E, and thats why its place is only at CPE.
> The true tragedy is CGN.

So making the average household a second-class citizen on the network
is “cool thing now”? Not in my opinion. There are lots of applications that
should exist today and don’t because we chose to break the E2E model.
Of the applications that do, there is a great deal of added complexity,
fragility, and a loss of privacy due to the use of rendezvous hosts to
overcome the difficulties posed by NAT.

Even in CPE, NAT is still harmful. CGN just makes it clear how harmful
it is at an even larger scale.

> Yeah, services make money so they should addapt new protocol, so users
> can access those services. In my opinion, due to IPv4 exhaustion, this
> is right adoption scheme. You move users to IPv6 and free IPv4 addresses
> for more services. It means internet can still grow and noone is really cut
> off. Once IPv6 mass is big enough, you can start to fade IPv4 services.

Yeah, that’s not really effective. What really needs to happen is moving
content to IPv6 so that new users that are IPv6-only aren’t faced with a
less useful internet. Moving eyeballs to IPv6 while growing content in IPv4-
only land helps no-one. The content providers lose users. The users
lose access to content.

Owen

On Sat, 25 Sept 2021 at 21:26, Owen DeLong via NANOG <nanog@nanog.org>
wrote:

> So the fact that:
>
> 2001:db8:0:1::5
> 2001:db8::1:0:0:0:5
>
> Are two different ways of representing the same address isn’t
> of any concern unless you’re making the mistake of trying to
> string wise compare them in their text-representation format.
> Both equate to the same uint128_t value.


If you adhere to RFC 5952 only the former is to be used (2001:db8:0:1::5).
Also strict RFC 5952 on any output will make a string compare ok because
there is only one way to print any address.

We should remember there are also multiple ways to print IPv4 addresses.
You can zero extend the addresses and on some ancient systems you could
also use the integer value.

You can even encounter IPv4 printed as IPv6 which is not too uncommon. Many
programs internally are IPv6 only and IPv4 is therefore mapped to IPv6. It
appears some people are forgetting this fact when proposing to drop IPv6.

Regards,

Baldur

> On Sep 25, 2021, at 14:20 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
>
>
>
> On Sat, 25 Sept 2021 at 21:26, Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:
> So the fact that:
>
> 2001:db8:0:1::5
> 2001:db8::1:0:0:0:5
>
> Are two different ways of representing the same address isn’t
> of any concern unless you’re making the mistake of trying to
> string wise compare them in their text-representation format.
> Both equate to the same uint128_t value.
>
> If you adhere to RFC 5952 only the former is to be used (2001:db8:0:1::5). Also strict RFC 5952 on any output will make a string compare ok because there is only one way to print any address.

IIRC 5952 only specifies display, it does not control (and even if it purports to, depending users to comply is silly) user input.

> We should remember there are also multiple ways to print IPv4 addresses. You can zero extend the addresses and on some ancient systems you could also use the integer value.

Truth.

> You can even encounter IPv4 printed as IPv6 which is not too uncommon. Many programs internally are IPv6 only and IPv4 is therefore mapped to IPv6. It appears some people are forgetting this fact when proposing to drop IPv6.

Fair point.

I think that ::ffff:1.2.3.4 is fine and I doubt it confuses anyone in IPv4 land much.

Owen

On Sat, 25 Sep 2021 23:20:26 +0200, Baldur Norddahl said:

> We should remember there are also multiple ways to print IPv4 addresses.
> You can zero extend the addresses and on some ancient systems you could
> also use the integer value.

19:17:38 0 [~] ping 2130706433
PING 2130706433 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms
^C
--- 2130706433 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 84ms
rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms

Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.

That's a bit more than just 'some ancient systems' - depending whether
it works on other Android releases, and what IoT systems do, we may have
more systems today that support it than don't support it.

On Sep 25, 2021, at 8:44 PM, Valdis Kl?tnieks <valdis.kletnieks@vt.edu> wrote:
>
> On Sat, 25 Sep 2021 23:20:26 +0200, Baldur Norddahl said:
>
>> We should remember there are also multiple ways to print IPv4 addresses.
>> You can zero extend the addresses and on some ancient systems you could
>> also use the integer value.
>
> 19:17:38 0 [~] ping 2130706433
> PING 2130706433 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms
> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms
> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms
> ^C
> --- 2130706433 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 84ms
> rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms
>
> Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.
>
> That's a bit more than just 'some ancient systems' - depending whether
> it works on other Android releases, and what IoT systems do, we may have
> more systems today that support it than don't support it.

It also works on this 'ancient' macOS Monterey system.

Last login: Sat Sep 25 20:50:00 on ttys000
xz4gb8 ~ % ping 2130706433
PING 2130706433 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.047 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.111 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.103 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.109 ms
^C
--- 2130706433 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.047/0.092/0.111/0.026 ms
xz4gb8 ~ %

Hello,

On Sat, Sep 25, 2021 at 08:44:00PM -0400, Valdis Kl?tnieks wrote:
> 19:17:38 0 [~] ping 2130706433

"ping 017700000001" and "ping 0x7F000001" also fun ones :)

Cheers,
Andy

Once upon a time, Andy Smith <andy@strugglers.net> said:
> On Sat, Sep 25, 2021 at 08:44:00PM -0400, Valdis Kl?tnieks wrote:
> > 19:17:38 0 [~] ping 2130706433
>
> "ping 017700000001" and "ping 0x7F000001" also fun ones :)

More than once, I've had to explain why zero-filling octets, like
127.000.000.001 (which still works) or 008.008.008.008 (which does not),
is broken.

--
Chris Adams <cma@cmadams.net>

On Saturday, September 25, 2021 21:55 Chris Adams <cma@cmadams.net> wrote:

> More than once, I've had to explain why zero-filling octets, like
> 127.000.000.001 (which still works) or 008.008.008.008 (which does not),
> is broken.

Zero filling IPv4 is just evil. How about this party trick?

> % ping -c 1 010.010.010.010
> PING 010.010.010.010 (8.8.8.8): 56 data bytes
> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=27.496 ms
>
> --- 010.010.010.010 ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 27.496/27.496/27.496/0.000 ms
%

Valdis Kl?tnieks wrote on 26/09/2021 01:44:
> 19:17:38 0 [~] ping 2130706433
> PING 2130706433 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms
> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms
> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms
> ^C
> --- 2130706433 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time84ms
> rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms
>
> Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.

this is a good example of "might work but don't depend on it". The fact
that it works at all is a historical curiosity which happened because
the text format for ipv4 addresses was never formally specified, so when
some of the tcp/ip code was originally written for bsd, it accepted
unusual formats in some places, including: integers, octal, hex, binary
and assuming zeros when the address is incompletely specified, among
other things.

The octal representation was a real problem because rfc790 specified
decimal dotted quad notation with leading zeros, leading to a whole bag
of pain for parsers because there is no way of knowing what a leading
zero means in practice, and for 3-digit numbers where each digit is <=
7, there is no a-priori way of determining whether it's octal
representation or decimal.

Nick

Originally, textual IPv4 addresses were maintained centrally
by ISI as a file format of HOSTS.TXT, when there was no DNS
and users are required to download the current most HOSTS.TXT
from ISI through ftp.

At that time, there can be, because of consistent central
management, just one way to represent them, which is described
in rfc810 as:

<address> ::= <octet> "." <octet> "." <octet> "." <octet>
<octet> ::= <0 to 255 decimal>

Obviously, syntax was extended, at least beyond decimal, by a
BSD implementation with language C.

Masataka Ohta