Live data from Hacker News

The IPv6 Transition

potaroo.net

311–320 of 433 posts

Re: The IPv6 Transition

#311

Earlier quoted context omitted.

I remember those days too. They had nothing to do with computers not being behind a NAT.

They had to do with computers being directly addressable, routable, and reachable by the entire Internet, which was the default prior to widespread deployment of NAT. NAT isn't the best way to do it, but it probably is the single biggest factor in reducing the external reachability of endpoint IPs.

NAT deployment here is only tangential to the real differentiator: the firewall. I mean, you can make a case that NAT is a poor man's firewall but you should know that it's not a substitute for a security model. Zero trust is now the dominant philosophy, and it allows for firewall rules to be derived procedurally.

It's a shame the likes of Microsoft only care about "zero trust" insofar their compliance checkboxes with the the US government. They see it as a chore. Contrary to Google, Cloudflare, et al.

Re: The IPv6 Transition

#312

Earlier quoted context omitted.

The purpose of SLAAC is to make it "easy" for a client to get onto the network without something like a DHCP server tracking addresses. If you set it up, it generally just works.

Previously it worked by putting the MAC address in the last 64 bits.

Yes, that was before privacy extensions. It hasn't been like that (in most implementations) for a very long time.

Re: The IPv6 Transition

#313
post #291

Earlier quoted context omitted.

The biggest design failure of IPv6 is that it was not designed to be backwards-compatible with IPv4. Technologies with established user bases need to evolve with backwards compatibility if they want to take advantage of existing network effects.

This comment shows up like clockwork. How does a device with a 32-bit-sized addressing scheme construct an IP packet to a device with an address in a 128-bit-sized addressing scheme?

It could work like 4 socks requests wrapped in each other like onion. But LAN services wouldn't need to care about long addressing as they don't need to cross network boundary, while letting everything else use new approach, so you could use old stuff without changing anything and there would be no need for new ip6 drivers with new vulnerabilities that are yet to be fixed.

Re: The IPv6 Transition

#314

IPv6 is _still_ not at the feature parity with IPv4! I'm not kidding. For example, Android doesn't support stateful DHCPv6. And DHCPv6 doesn't have the _basic_ feature of DHCPv4: hostnames. You can't easily use it to do a quick survey of your network. Then you have that @#& (^( &!@^ that is ULA. With IPv4 we have a very useful pattern: you create an "internal" network that is stable and predictable. It's routed to th…

You know that dhcpv6 servers like odhcpd (Openwrt) implement hairpin NAT along with IPv6-PD right?

Re: The IPv6 Transition

#315

Earlier quoted context omitted.

Previously it worked by putting the MAC address in the last 64 bits.

Yes, that was before privacy extensions. It hasn't been like that (in most implementations) for a very long time.

And you get no privacy if /64 prefix is a stable identifier of one customer.

Re: The IPv6 Transition

#316

Earlier quoted context omitted.

Yes, that was before privacy extensions. It hasn't been like that (in most implementations) for a very long time.

And you get no privacy if /64 prefix is a stable identifier of one customer.

This doesn't seem like an IPv6-specific issue. For most broadband customers, your external IPv4 address is also generally stable. Mine hasn't changed in years.

Re: The IPv6 Transition

#317

Earlier quoted context omitted.

In reality an IP address costs about $2 a month at market rates.

So? Is your argument that it’s so cheap that everyone should get an IP? That would be mathematically impossible. If more people wanted an IP, the price would just rise. The same percentage of people (less than 1/3) would have one. They would just pay more. It’s like buying land in a city like SF. Demand can change the price, but the supply remains the same.

The argument is that migrating to IPv6 isn't worth anyone's time. (Except for maybe CG-NAT operators.)

Re: The IPv6 Transition

#318

I'm pretty naive about this stuff, but IMO IPv6 is a lot more empowering than v4. You aren't dependent on some owner of v4 addresses for access, you don't need to manage--and aren't forced into--NAT, and you (probably) get to use all of your ports. My conspiracy theories about why v6 hasn't taken off are: people make money off v4 leases, and email spam blacklists become pretty useless in v6. But again, very naive her…

The more likely reality is that we have a lot of v4-only hw in place with lifespan of 20+ years. Those devices won't go away. Heck, I work on embedded, and having a dual-stack system is just a PITA to deal with. If v6 would have been fully retro-compatible this wouldn't have been something to think about, but you can't drop v4 and there's no future in sight where v6 will be the only choice (we'll have dual-stack for…

Totally agree. I'm a little embarrassed by it tbh; to me it feels like a big failure of nerd governance. We should be able to manage this, but I think we're pretty close to having to admit that we can't.

Re: The IPv6 Transition

#319

Earlier quoted context omitted.

> have each service that deserves to be reached over the listen on an address unique to the service It’s already a thing. These unique per-service addresses are called “ports” in IP protocol.

Hosting service A shouldn't mean that every user of service A can also figure out you host C, B and D. Also, the IP protocol does not care about ports at all. Ports are a thing for UDP and TCP.

> Also, the IP protocol does not care about ports at all. Ports are a thing for UDP and TCP.

You're right, they are one level above.

> Hosting service A shouldn't mean that every user of service A can also figure out you host C, B and D.

It how are ports on a single IP address essentially different from multiple IP addresses within a subnet?

Re: The IPv6 Transition

#320
post #235

The premise is completely wrong here. IPv6 is not just an “incremental change” that would have represented an easy uptake. Instead, pretty much every practical detail of existing IPv4 infrastructure, both hardware and software, was broken. Massive swaths of extra management and security tools were rendered useless. It was a massive miscalculation. In the meantime, we figured out how to make things work without the ex…

NAT doesn't ever provide security, only pretending to.

I’ve seen this sentiment repeated over and over in this thread without a single explanation.

Please explain how NAT on IPv4, as used in practice, does not increase security vs connecting machines each directly to a publicly accessible Internet address?

I’m having a hard time understanding how this statement can possible be true.

Post reply on HN