Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why IPv6 is so complicated

github.com

Post reply on HN
Print view View original

121–130 of 519 posts

Re: Why IPv6 is so complicated

#121

Post by icedchai »

jjav wrote: post #113
ExoticPearTree wrote: post #37

My first IPv6 implementation was in 2010-2011 (memory a but fuzzy). Carriers supporting BGP over IPv6 were few, websites over IPv6 were also scarce. Fast forward 15 years snd the situation has improved quite dramatically. IPv6 has some quirks that make it harder to digest. - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space - privacy extensions:…

> In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Topic drift, but for younger people who didn't live it, that's how it used to be! For most of the 90s my workstation in the office (at several employers) was directly on the Internet. There were no firewalls, no filtering of any kind. I ran my email server on my desktop worksta…

Same! I even had my home network on a public /24.

Re: Why IPv6 is so complicated

#122

Post by mrsssnake »

wongabu wrote: post #101

There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network. inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover Inb4 no you can't just advertise new…

IPv4 has exact same problem, the NAT is working here because devices does not actually have proper Internet connection, all connections are terminated on NAT and reassembled after.

Actual solution could be extending TCP and UDP or make a new transport layer procotol that handles changing addresses, similar to what QUIC do. But we cannot do it exactly because things like NATs existing, thus QUIC build was build on ossificated UDP. Imagine if instead of IP+port a connection use unique per-connection hash to persist IP addreses changing. No more trying fighting to keep the IP the same.

Re: Why IPv6 is so complicated

#123

Post by 9dev »

threiw wrote: post #102
john01dav wrote: post #89

Earlier quoted context omitted.

This attitude is widespread enough to hold the world back by forcing everyone who interacts with the public Internet to support ipv4 (some technology), "for free". So, either way, we're forcing one of them. So, we might as well lean towards supporting the one that isn't hard capped at 4 billion addresses in a world with at least 2x as many devices. Have you ever tried to deal with NAT punchthrough? That's way more di…

> Have you ever tried to deal with NAT punchthrough? That's way more difficult to fix than having to properly configure your server. Yes I did, and I no longer support that either. For my setups it is local private ipv4 networks all the way now! How tailscale or other VPN deals with that is not my problem! If two nodes are on different networks, they should not be allowed to talk to each other anyway. Seems like secu…

> If two nodes are on different networks, they should not be allowed to talk to each other anyway.

We are so lucky people like you aren't in charge, or we wouldn't have the internet in the first place.

Re: Why IPv6 is so complicated

#124

Post by 9dev »

XorNot wrote: post #117
9dev wrote: post #95

Earlier quoted context omitted.

That’s kind of my point, though. There is no reason at all to remember IP addresses.

I don't care to remember them, but I do want them to be consistent so there's no dependency in DNS. My home network isn't the Internet and isn't large: DNS is a much more complicated system to keep running then just fixed IP addresses in that circumstance. Above a certain scale, that flips but not at the home level.

At the home level, you have a home router that can do mDNS out of the box. All devices are reachable by their hostname.

Re: Why IPv6 is so complicated

#125

Post by SkiFire13 »

rusk wrote: post #38
SkiFire13 wrote: post #14

Earlier quoted context omitted.

> Instead they expected humans to parse hex, which no one does Of all aspects of IPv6 you took the only one that doesn't complicate implementations and can easily be swapped if you wanted.

Wait til you’ve got to copy & paste em, or see em comingled with hw addresses

I'm not disagreeing that's a bad aspect of IPv6, I'm just saying that it's not that big of a issue for its adoption.

Re: Why IPv6 is so complicated

#126

Post by icedchai »

wongabu wrote: post #101

There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network. inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover Inb4 no you can't just advertise new…

The actual solution is network prefix translation. You effectively NAT the primary network when failed over to the secondary. See https://docs.netgate.com/pfsense/en/latest/recipes/multiwan-... for an example.

Re: Why IPv6 is so complicated

#127

Post by bewo001 »

peanut-walrus wrote: post #85

I've always found the most complicated part of IPv6 to be address scopes and source address selection. The fact that one interface can have any number of addresses in different scopes and prefixes complicates things a lot. Another thing that will always trip up new IPv6 network engineers is solicited-node multicast. You know the theory, computers talk to ff02::1 for neighbor discovery and then you hop onto a real net…

An interface can have many ipv4 addresses as well. It's just not that common, so many people believe they'd need vlans to achieve that.

Re: Why IPv6 is so complicated

#128

Post by wongabu »

icedchai wrote: post #126
wongabu wrote: post #101

There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network. inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover Inb4 no you can't just advertise new…

The actual solution is network prefix translation. You effectively NAT the primary network when failed over to the secondary. See https://docs.netgate.com/pfsense/en/latest/recipes/multiwan-... for an example.

That's one ugly hack, which assumes (1) WAN1 has static ipv6 (the typical SME has dynamic DHCPv6 address...) (2) all the devices will behave correctly when running on NPT on failover WAN2. Many devices do not know about NPT which is basically NAT for ipv6, and break on p2p protocols like voice, video, streaming. They'll send the wrong NPT address to the other side, which try to connect back to the WAN1 address, which is down because of failover.

Re: Why IPv6 is so complicated

#129

Post by peanut-walrus »

bewo001 wrote: post #127
peanut-walrus wrote: post #85

I've always found the most complicated part of IPv6 to be address scopes and source address selection. The fact that one interface can have any number of addresses in different scopes and prefixes complicates things a lot. Another thing that will always trip up new IPv6 network engineers is solicited-node multicast. You know the theory, computers talk to ff02::1 for neighbor discovery and then you hop onto a real net…

An interface can have many ipv4 addresses as well. It's just not that common, so many people believe they'd need vlans to achieve that.

Yes. But it's quite an uncommon setup. For IPv6 multiple addresses is the default.

Re: Why IPv6 is so complicated

#130

Post by wongabu »

mrsssnake wrote: post #122
wongabu wrote: post #101

There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network. inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover Inb4 no you can't just advertise new…

IPv4 has exact same problem, the NAT is working here because devices does not actually have proper Internet connection, all connections are terminated on NAT and reassembled after. Actual solution could be extending TCP and UDP or make a new transport layer procotol that handles changing addresses, similar to what QUIC do. But we cannot do it exactly because things like NATs existing, thus QUIC build was build on oss…

Ipv4 does NOT have this problem. The typical setup is always NAT for ipv4 lan, so external address can be changed with minimal disruption.

All ipv4 apps that require hole punching assume they will need to "discover" the external address anyways, for every new p2p connection.

In contrast to the vast majority of ipv6 apps which assume their ipv6 address is identical to external ipv6 address, as this is(was) the main marketing point of ipv6 - directly addressable end points.

Post reply on HN