IPv6 woes - RFC

Sat Sep 25 09:10:38 UTC 2021

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 at delong.com>
To: borg at uu3.net
Cc: nanog at 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 at 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 at jmaimon.com>
> To: Owen DeLong <owen at delong.com>, Bjrn Mork <bjorn at mork.no>
> Cc: nanog at 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
> 
> 
> 
> 