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

Tell HN: IPv6-only still pretty much unusable

news.ycombinator.com

Post reply on HN
Print view View original

181–190 of 649 posts

Re: Tell HN: IPv6-only still pretty much unusable

#181

Post by marcosdumay »

spookthesunset wrote: post #81
redox99 wrote: post #32

IPv6 has been one of the biggest failures in the last couple of decades. And I don't mean adoption, I mean the standard itself. If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade. Yes, I understand it would still require some breaking changes, but it would have been a million times easier to upgrade, as it would be a kind of superset of IPv4 (1.2.3.4 can be referred as 0.0.0.0.…

It’s the firewall rules that always creep me out. The nice thing about NAT is open ports on your internal network are hidden to the outside world by default. You have to think about which ports you want the NAT gateway to forward. With IPv6 the entire network is reachable outside by default. Granted I assume you can probably create a default DENY rule for inbound traffic and selectively open ports up as exceptions. R…

> The nice thing about NAT is open ports on your internal network are hidden to the outside world by default.

That is usually not true. NAT punching is a thing for decades now.

Re: Tell HN: IPv6-only still pretty much unusable

#182

Post by zekica »

patrakov wrote: post #149
blablabla123 wrote: post #85

Earlier quoted context omitted.

It provides a lot of improvements actually. Stating the obvious, NAT isn't needed anymore. Also with modern Firewalls rules need to be written only once. At this point I'm just surprised why it's not adopted

> NAT isn't needed anymore. False. The most obvious case is multi-homing (for redundancy, fail-over, and policy-routing reasons) without an AS available and thus without BGP. In other words, a typical case when a user has a fiber connection and LTE as a backup. Then it is the router who should pick the correct source address, according to the link which is up. Another reason is to deal with dynamic addressing from th…

The correct way to do this is to advertise the fiber connection's prefix to devices on LAN as long as that connection is available. When it fails, the router should send RA with zero as the expiry time for that prefix, and include the LTE prefix. This way, all devices will immediately start using the new prefix. You can use ULA in addition so local connections don't fail.

Re: Tell HN: IPv6-only still pretty much unusable

#183

Post by rnhmjoj »

jedberg wrote: post #143
rnhmjoj wrote: post #111

Earlier quoted context omitted.

But IPv4+ is incompatible, so it requires to maintain two network stacks until reasonably everything has moved over to it. You need to duplicate the configuration for DNS, routing, firewalls etc., exactly as for dual stack IPv6. I don't really see a difference.

Imagine I own a company and I already have a bunch of IP4. I upgrade my network equipment to IP4+, and then keep all my routing and firewall configs. Everything just works the same as before. Now I want to access IP4+, so I add a route entry for all the IPs above 255.255.255.255. In fact, if that entry is just "send everything to my upstream" it might already work! Now I want to add some new resources but I'm out of…

If you really wanted you to could keep you old addressing scheme in IPv6 (arbitrary IPv4 addresses can be embedded into IPv6), you can disregard all best IPv6 practices about subnetting and do everything like you did for IPv4, DHCP and all, heck even NAT. The problem is that as soon as you're turning it on you need to maintain two sets of routing and firewall configs, even if they were identical.

Also you need proper support from all those lazy vendors (both hardware and software) that did the absolutely minimal amount of work to advertise their products as IPv6 ready when it fact the support ranges from subpar to practical unusable.

As soon as you make a one bit incompatible change to the protocol routers aren't able to communicate anymore: it's the same situation again. It doesn't matter how similar the two protocols are, they're incompatible.

Re: Tell HN: IPv6-only still pretty much unusable

#184

Post by ddalex »

spiritplumber wrote: post #115
gertrunde wrote: post #108

Earlier quoted context omitted.

No.... Absolutely no... NAT is absolutely not in any way a substitute for an actual firewall, despite the side effect of 'blocking' ports. And how is "You have to think about which ports you want the NAT gateway to forward." any different from thinking about firewall rules? And most consumer CPE devices (i.e. 'router' etc) are perfectly capable of running a firewall, and often do. And any firewall that doesn't drop i…

I use an old Parallax Propeller server as my DMZ, with instructions to log everything and answer "OK" to everything. It's funny what people try to do to it.

Why don't you write a blog post about this? I'm interested to see what will go on

Re: Tell HN: IPv6-only still pretty much unusable

#185

Post by tjoff »

tjohns wrote: post #142
tjoff wrote: post #109

Earlier quoted context omitted.

So I have to manually configure every device to be able to use internet? Every friends phone that wants to connect to my wifi needs manual setup? That is a problem. To which the solution is IPv4?

What? No. You connect a device, and SLAAC (and optionally DHCPv6, on enterprise networks) configures everything. It just works. SLAAC is more than capable of sending DNS settings to devices. There's no manual configuration involved.

My post said to use DHCPv6 and RDNSS. Follow up claimed to use SLAAC instead.

SLAAC does not do DNS. Clear as day?

Re: Tell HN: IPv6-only still pretty much unusable

#186

Post by lazide »

lzaaz wrote: post #163
vel0city wrote: post #152

Earlier quoted context omitted.

Depending on the NAT implementation this can be incredibly naive. Many home routers will send ANY traffic incoming on a port to the NAT'd IP address, even if the sources don't line up. So say Alice is behind a crappy NAT and wants to talk to Bob. Alice's router opens a port on its edge, lets say 1234, and sends traffic to Bob on port 80. Let's say Charles knows Alice's IP address. Charles starts spamming Alice's rout…

That's like saying that a bad firewall implementation leaks like a sieve. This is not what I was talking about.

Any router running a poor NAT implementation (aka most of them) essentially has a built in firewall bypass for the right attacker.

A naive NAT implementation can allow an attacker to bypass the firewall.

Re: Tell HN: IPv6-only still pretty much unusable

#187

Post by throw0101a »

MisterTea wrote: post #84
noipv6 wrote: post #21

Earlier quoted context omitted.

anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes. part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008 part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened). that turned out to not be so effective since so many ppl ignored the realities of legacy ip depleti…

> part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008 Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6? > part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened). Perhaps they didn't listen because dual stack means investing in building another incompatible internet on ipv6 i…

> Why are we stuck with nat in 2022 again? Why did we not map the 32 bits of ipv4 to ipv6?

Oh, you mean like this:

> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[61]

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

* https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5

You still need to upgrade bit of networking kit between the source and destination to understand "IPv4+", and this (lack of) upgrading and enabling is what is hampering deployment.

What makes you think that companies would have been willing to make the effort to deploy "IPv4+" any more than IPv6?

> Because it is a mess. Stop denying that. If ipv6 was designed to be easily deployed via backwards compatibility then we would be using ipv6 already.

Backwards compatibile IPv6 was impossible.

IPv4 has 32 bits of address. Anything after IPv4 needed >32 bits of address. How do you fit in >32b in a data structure that is 32b? You cannot.

So you have to go an replace every bit of networking code out there to change the data structures. You know, like was done to deploy IPv6.

Re: Tell HN: IPv6-only still pretty much unusable

#188

Post by maximaximal »

We are IPv6-only on our institute-internal CPU compute cluster based on slurm. Only the head node has an IPv4 address, so that it can be reached from IPv4 only clients (sadly, there are still quite a lot). All nodes inside the cluster talk over IPv6. And all other computers with IPv6 access use that to communicate to the head node. We are transitioning to IPv6-only for internal services and try to avoid using IPv4 addresses, only going back to it when something needs to be accessed from the outside.

Sadly, our local ISP is still IPv4-only, meaning we cannot even access our IPv6 hosts while at home, so we need to fall-back to IPv4 quite a lot. Also, the Cisco VPN is still IPv4 only (because of lacking resources to add IPv6 support), so not even the VPN helps. We need to jump over some dual-stack host then.

When speaking to the local ISP, they just reply that it's not planned soon, they don't have resources for it, and "they evaluated IPv6 and don't have a reason to support it". Me/us giving them reasons was not enough it seems.

Re: Tell HN: IPv6-only still pretty much unusable

#189

Post by gnfargbl »

CGamesPlay wrote: post #95

To use GitHub on an IPv6-only Hetzner instance, you'll need to use a NAT64 gateway. There's a list of public ones here: https://nat64.xyz/ This can just go into your /etc/hosts: 2a01:4f8:c2c:123f:64::140.82.121.3 github.com www.github.com

Huh, so I can effectively use a NAT64 gateway as an unauthenticated open proxy? Let's try it. First look up the IPv4 for a site that reads back your IP address:

    $ dig +short a icanhazip.com
    104.18.115.97
    104.18.114.97
(Those are Cloudflare IP; icanhazip.com is hosted on CF.) Next, try connecting to the IP-readback site via a NAT64 gateway, but presenting the correct Host header so that Cloudflare knows what to do with the request:

    $ curl -6 -k -H 'Host: icanhazip.com' https://[2001:67c:2960:6464::104.18.115.97]/
    141.98.136.43
OK, it reads back an IPv4...

    $ dig +short -x 141.98.136.43
    de-fra2-nat641.level66.network.
...with a PTR record associated with level66.network, which was the NAT64 gateway we chose.

How does this not see more abuse by bad actors? I guess it probably does, which is why there are so few of these public gateways?

Re: Tell HN: IPv6-only still pretty much unusable

#190

Post by patrakov »

zekica wrote: post #182
patrakov wrote: post #149

Earlier quoted context omitted.

> NAT isn't needed anymore. False. The most obvious case is multi-homing (for redundancy, fail-over, and policy-routing reasons) without an AS available and thus without BGP. In other words, a typical case when a user has a fiber connection and LTE as a backup. Then it is the router who should pick the correct source address, according to the link which is up. Another reason is to deal with dynamic addressing from th…

The correct way to do this is to advertise the fiber connection's prefix to devices on LAN as long as that connection is available. When it fails, the router should send RA with zero as the expiry time for that prefix, and include the LTE prefix. This way, all devices will immediately start using the new prefix. You can use ULA in addition so local connections don't fail.

This can work with the fiber + LTE example, and with the rat example, but does not cover the "modem crash" example. The ADSL modem does not know its old prefix, and thus cannot send zero-expiry-time announcements for it.

Also consider a case where there is an ADSL modem (with the ISP giving out /56 via prefix delegation) and a home lab with virtual machines, that are behind a virtualization host, which grabs a subprefix (let's say a /64, separate from the main home LAN /64 prefix) for its VMs from the modem via DHCPv6. While there is indeed a mechanism for flash renumbering over SLAAC, which may work for devices in the home LAN, there is also a need to invalidate the subprefix delegated for virtual machines via DHCPv6 through the virtualization host. Last time I checked, this is not implemented anywhere.

Post reply on HN