The world in which IPv6 was a good design (2017) • Hacker News Board

Re: The world in which IPv6 was a good design (2017)

#271

Post by greyface- » Mon, Aug 14, 2023, 11:24 PM UTC

cyberax wrote: post #268

growse wrote: post #263

Earlier quoted context omitted.

> First, a /16 network is 65536 devices, which is pretty big as-is. "big" is a relative term. For some cases, that's a really annoying restriction. > But it's a bad idea. You will have a shared media that can be brought down by erroneous broadcasts or devices. This is a classic story: https://www.computerworld.com/article/2581420/all-systems-do ... IPv6 doesn't have the concept of "broadcast". > ND doesn't solve it.…

> IPv6 doesn't have the concept of "broadcast". Indeed. It has magic fairies delivering multicast packets to the right interfaces. > No, ND uses multicast. How do you think multicast is implemented in Ethernet?

> How do you think multicast is implemented in Ethernet?

Via MLD snooping on switches that support it. Yes, some switches will fall back to broadcast, but only if they're not multicast aware.

Re: The world in which IPv6 was a good design (2017)

#272

Post by remram » Mon, Aug 14, 2023, 11:25 PM UTC

loa_in_ wrote: post #195

remram wrote: post #159

Earlier quoted context omitted.

I can't `ping ::ffff:192.168.0.1` and have it ping my router. There is a range reserved for representing IPv4 addresses, but the stack doesn't translate.

But you can "ping $address" regardless of which IP version it's using. Please, elaborate what are you trying to solve.

I didn't say I couldn't type that in... my point was clear to everybody else who responded.

Re: The world in which IPv6 was a good design (2017)

#273

Post by remram » Mon, Aug 14, 2023, 11:26 PM UTC

Dagger2 wrote: post #235

remram wrote: post #159

Earlier quoted context omitted.

I can't `ping ::ffff:192.168.0.1` and have it ping my router. There is a range reserved for representing IPv4 addresses, but the stack doesn't translate.

It does translate, but it doesn't work for ping because ping bypasses most of the stack by sending raw packets. Try something like `telnet ::ffff:192.168.0.1 80`.

That does work. Interesting, the OS translates this at the socket level.

Re: The world in which IPv6 was a good design (2017)

#274

Post by AtlasBarfed » Mon, Aug 14, 2023, 11:28 PM UTC

AtlasBarfed wrote: post #244

GordonS wrote: post #115

Earlier quoted context omitted.

> As such it is not better enough than IPv4 That's the crux of it. Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.

I think what is first necessary is to force compliance of upgrading of IPV4 stacks to accept some information in the options section of the IP packet. According to wikipedia, many/most routers ignore or block packets that have anything specified there. You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard. I would say: 1) gath…

OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing.

If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP.

... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path.

... that might not work ... or maybe it will?

Re: The world in which IPv6 was a good design (2017)

#275

Post by greyface- » Mon, Aug 14, 2023, 11:31 PM UTC

AtlasBarfed wrote: post #274

AtlasBarfed wrote: post #244

Earlier quoted context omitted.

I think what is first necessary is to force compliance of upgrading of IPV4 stacks to accept some information in the options section of the IP packet. According to wikipedia, many/most routers ignore or block packets that have anything specified there. You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard. I would say: 1) gath…

OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing. If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP. ... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path. ... that mi…

You've reinvented 6to4 and the 192.88.99.1 well-known anycast address.

Re: The world in which IPv6 was a good design (2017)

#276

Post by AtlasBarfed » Tue, Aug 15, 2023, 2:30 AM UTC

greyface- wrote: post #275

AtlasBarfed wrote: post #274

Earlier quoted context omitted.

OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing. If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP. ... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path. ... that mi…

You've reinvented 6to4 and the 192.88.99.1 well-known anycast address.

So I think the difference here is then is gradual migration of the same IP stacks / infrastructure, and not introducing an entirely new "separate" stack.

My only experience with IPv6 was converting an IPV4 distributed database to IPV6. It wasn't... fun. Looking up separate flags and settings, weird errors (thank the gods for stack overflow), frustration.

Nowhere was it suggested, demonstrated, or detailed such a backwards compatibility / migration strategy.

Re: The world in which IPv6 was a good design (2017)

#277

Post by brian_cunnie » Tue, Aug 15, 2023, 2:38 AM UTC

Helmut10001 wrote: post #77

About a year ago I started the IPv6 migration for my home network (2 Remote sites, connected via IPSEC, with 10 VLANs (subnets) and about 70 devices, 10 people). - I started on one side of the IPSEC, where I have an OPNsense - there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced). - my ISP only hands out /64-Prefixes, and these are also dynamic…

> there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced)

That's a bummer. I've been using FreeBSD + pf at home for years now, and it's been smooth sailing.

> my ISP only hands out /64-Prefixes, and these are also dynamic, which makes configuration more difficult

Comcast/Xfinity hands out a /60, which means I get 16 x /64 subnets. And they haven't changed my subnets in at least four years. Pro-tip: when you change firewall hardware, keep the same MAC addr to keep the same IPv4, keep the same DHCP Unique Identifier (DUID) (/var/db/dhcp6c_duid on FreeBSD) to keep the same IPv6 subnets.

Re: The world in which IPv6 was a good design (2017)

#278

Post by brian_cunnie » Tue, Aug 15, 2023, 2:56 AM UTC

I must admit I'm at a loss about this IPv6 hate. I love IPv6.

I love that (almost) every IPv6 subnet is a /64. Just this morning I assumed an IPv4 subnet was a /24, only to discover it was a /20, causing me to spend a couple of minutes re-working.

I love that (almost) every IPv6 is a /64 because you'll never have to widen a subnet because you started of with a /24, but then after your office grew to 200 people you had to switch to a /20. And no matter how automated you are, there are always some important devices that have static IPs and that you have to reconfigure manually.

I love that every IPv6 client gets a routable IP. This means NAT isn't necessary. NAT is a clever hack, but we've grown so accustomed to it that we've become blind to its failings. I've had to trace packets coming out of a corporate NAT, then into an AWS ELB (Elastic Load Balancer) back into a different NAT. With the IP address remappings, it's awful

IPv4 NAT can also lead to IP address collisions. Your home subnet is 192.168.0.0/24? And so's your work? Good luck VPN'ing in.

I like that IPv6 has an abundance of IPv6 addresses—I don't need to share the ports on my sole IPv4 address to 5 different machines.

Re: The world in which IPv6 was a good design (2017)

#279

Post by Thiez » Tue, Aug 15, 2023, 4:23 AM UTC

WorldMaker wrote: post #255

mort96 wrote: post #89

Earlier quoted context omitted.

I'm worried about the long tail. IPv6 won't actually be useful until more or less everything supports v6; as long as there are enough clients which don't support v6 servers need v4, and as long as there are enough servers which don't support v6 clients need v4. And until we can start disabling v4, v6 gives no advantage and only causes significant added complexity. I'm worried that the time when we can start removing…

Certainly, it is at least a start that all the cloud providers are slowly raising the hourly costs for v4 addresses to better reflect scarcity and other externalities. Those costs rise high enough it will be a pressure on corporate bottom lines (and then in turn IaaS tools and many other SaaS providers).

And yet Azure has comically bad IPv6 support, so you can't even move (partially) away from IPv4 even if you wanted to. Besides, the cost of a v4 address is peanuts compared to the other cloud costs.

Re: The world in which IPv6 was a good design (2017)

#280

Post by throwaway154 » Tue, Aug 15, 2023, 4:24 AM UTC

cyberax wrote: post #174

throwaway154 wrote: post #146

Earlier quoted context omitted.

16 bits is fine if thinking about discrete devices in the home. But what about thinking about the next step, neurons in the home. 65k's on the low side for home neuron count.

Are you sure you want to expose individual neurons to the Internet?

Think of the unexpected unknowns. The feet of your chairs having light sensors, each tile of a roof having its own ambient vibration monitors, a thermostat on every bookcase shelf, all self organising around the you GooFaceAI determines you to be.