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