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

IPv6 is the only way forward

ankshilp.in

Post reply on HN
Print view View original

231–240 of 350 posts

Re: IPv6 is the only way forward

#231

Post by kstrauser »

fulafel wrote: post #216
artooro wrote: post #203

I'm surprised how few people are talking about ULAs. For any home network where you don't have a reserved global address space from your ISP, it makes sense to configure a ULA on your router and use it for all internal hosts, and the ISP assigned address is only used for Internet access. This does not require NAT/Npt and you have the best of both worlds.

If you want to have an airgapped network, sure. For most people it doesn't make sense. You'll just get the worst of of both worlds.

It’s pretty sweet. By using ULA addresses for everything, all internal networking keeps working as-is if my ISP allocation changes. Every host can talk to its neighbors using internal addresses, and still connect to remote hosts without NAT breakage.

Re: IPv6 is the only way forward

#232

Post by LoganDark »

orangeboats wrote: post #228
LoganDark wrote: post #225

Earlier quoted context omitted.

> I will raise you the opposite point: why deprive people of their ability to have a globally addressable IP address? I wouldn't. I just don't understand, if the alternative is having no internet access at all, why CG-NAT is so utterly deplorable. > This kind of NAT is NOT hole-punchable. And because you don't control the NAT, you are simply SOL if one day your NAT decides to switch to it. Can you clarify what you me…

>Can you clarify what you mean by hole-punchable? If all else fails, just use TCP, right? Does TCP also not work? I... uh, what? Please... learn more about hole punching before trying to engage in the topic. Hole punching, in the context of NAT, is a technique where you establish peer-to-peer connection between hosts behind a NAT. It does not matter which protocol you use, UDP or TCP or chuckles SCTP. If you want to…

> Please... learn more about hole punching before trying to engage in the topic.

I'm not engaging in the topic of hole punching though? The topic is whether CG-NAT has drawbacks other than lack of port forwarding. As I've said many times, expecting P2P connectivity has never been viable. But you ignore that and keep talking about how hard hole punching is, as if it's indispensable. What makes it so indispensable? Why is it so critical?

> Hole punching, in the context of NAT, is a technique where you establish peer-to-peer connection between hosts behind a NAT.

Good, that confirms I was never talking about that. I even explicitly clarified I was not talking about that (though you may have loaded my comment before that edit.)

> It does not matter which protocol you use, UDP or TCP or chuckles SCTP. If you want to establish P2P connection, you must hole punch.

You don't need to establish P2P connection so I don't see why that's such a problem. Again, it has never been safe to assume P2P connection is possible. Period. It is merely a progressive enhancement.

Re: IPv6 is the only way forward

#233

Post by WorldMaker »

redserk wrote: post #193
MaKey wrote: post #180

Earlier quoted context omitted.

Yeah, it's always the same with IPv6 discussions. The main points being: 1. IPv6 addresses are too long to remember 2. IPv6 doesn't need NAT and people are uncomfortable with their devices having a public address as they see NAT as an additional layer of security

If someone is still using the “remembering IP addresses” argument in 2026 (or at any point in the 21st century), I question their technical competence in configuring a network correctly.

It also seems to be a learning curve thing because IPv6 addresses have their own versions of memorable mnemonics. If you are in a LAN space manually configuring LAN addresses, you just need to remember one of the local address (ULA) prefixes like fc00 and then start numbering your devices as ::1 and incrementing (fc::1, fc::2, fc::3, etc). But also in LAN spaces you could just rely on mDNS (devicename.local), it's gotten quite good in most OSes today.

If you need to remember random WAN IPv6 addresses without being able to use DNS or at least a hosts file you've probably got a bunch of other more pressing problems.

Re: IPv6 is the only way forward

#234

Post by gosub100 »

Can someone pity me enough to explain how to do DNS on ipv6 while using slaac?

All I want to do is give every machine on my network a friendly hostname like storage.lan, timsPhone.lan, etc without having to run BIND (if possible), or dhcpd.

I have heard of zeroconf for ipv4, but the catch is I want this to work across several different platforms like Windows , freebsd, Linux, etc. I also don't want to use static addresses, but I feel like that's asking too much.

Re: IPv6 is the only way forward

#236

Post by illiac786 »

artooro wrote: post #203

I'm surprised how few people are talking about ULAs. For any home network where you don't have a reserved global address space from your ISP, it makes sense to configure a ULA on your router and use it for all internal hosts, and the ISP assigned address is only used for Internet access. This does not require NAT/Npt and you have the best of both worlds.

There are ISPs out there that distribute IPv6 to the WAN intf of the home router without a /64? What’s the point for them?

Re: IPv6 is the only way forward

#237

Post by orangeboats »

LoganDark wrote: post #232
orangeboats wrote: post #228

Earlier quoted context omitted.

>Can you clarify what you mean by hole-punchable? If all else fails, just use TCP, right? Does TCP also not work? I... uh, what? Please... learn more about hole punching before trying to engage in the topic. Hole punching, in the context of NAT, is a technique where you establish peer-to-peer connection between hosts behind a NAT. It does not matter which protocol you use, UDP or TCP or chuckles SCTP. If you want to…

> Please... learn more about hole punching before trying to engage in the topic. I'm not engaging in the topic of hole punching though? The topic is whether CG-NAT has drawbacks other than lack of port forwarding. As I've said many times, expecting P2P connectivity has never been viable. But you ignore that and keep talking about how hard hole punching is, as if it's indispensable. What makes it so indispensable? Why…

>The topic is CG-NAT and port forwarding

You don't mention port forwarding without mentioning about hole punching.

Because what port forwarding is for, if not to ease the establishment of direct connections?

>You don't need to establish P2P connection

If you are seriously suggesting Server-Client Is All You Need (TM), I feel we might as well stop the discussion now. VoIP essentially requires P2P, WebRTC is much better with P2P. BitTorrent etc obviously runs on P2P.

Services that provide relays (for people who can't establish P2P connection) for free, can only do so because they expect most connections to NOT go through the relay, and so they could simply stomach the costs of running one small relay.

Re: IPv6 is the only way forward

#238

Post by illiac786 »

direwolf20 wrote: post #191
gertrunde wrote: post #176

Earlier quoted context omitted.

There's a few things here that are a bit iffy tbh! I can't see why an ISP is dynamically changing the IPv6 addressing for a client, but if that's what is going on, then v6 NPT is your friend (RFC6296 - https://datatracker.ietf.org/doc/html/rfc6296 ). But pfsense's behaviour is a bit iffy too, unless when you say 'public IP', you mean the IPv6 address being used on the pfsense facing the clients? (I'm assuming it's us…

It's a legal requirement in Europe for privacy. A long term static address is a personal identifier.

How could this be a legal requirement and at the same time you can purchase static IPs as a paid option from ISPs, like I did?

Re: IPv6 is the only way forward

#239

Post by commandersaki »

w3ll_w3ll_w3ll wrote: post #11
rectang wrote: post #5

If UTF-8 represents the triumph of a design prioritizing backwards compatibility with an existing standard (ASCII) to facilitate a transition, then IPv6 is the cautionary tale of a design which could have made the transition simpler but did not.

IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols and leads to flawed conclusions.

This recent article begs to differ: https://news.ycombinator.com/item?id=47352236

Re: IPv6 is the only way forward

#240

Post by WorldMaker »

jcgl wrote: post #95
throw0101c wrote: post #74

Earlier quoted context omitted.

> So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version. Like > 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 forma…

I think your summary is really great. One of the better refutations I've seen about the "what about v4 but longer??" question. However, I think people do get tripped up by the paradigm shift from DHCP -> SLAAC. That's not something that is an inevitable consequence of increasing address size. And compared to other details (e.g. the switch to multicasting, NDP, etc.), it's a change that's very visible to all operators…

SLAAC isn't something that is an inevitable consequence of increasing address size, it's something that is a useful advantage of increasing address size. Almost no one had big enough blocks in IPv4 where "just choose a random address and as long as no else seems to be currently claiming it it is yours" was a viable strategy for assigning an address.

There are some nice benefits of SLAAC over DHCP such as modest privacy: if device addresses are randomized they become harder to guess/scan; if there's not a central server with a registration list of every device even more so (the first S, Stateless). That's a great potential win for general consumers and a far better privacy strategy than NAT44 accidental (and somewhat broken) privacy screening. It's at odds with corporate device management strategies where top-down assignment "needs to be the rule" and device privacy is potentially a risk, but that doesn't make SLAAC a bad idea as it just increases the obvious realization that consumer needs and big corporate needs are both very different styles of sub-networks of the internet and they are conflicting a bit. (Also those conflicting interests are why consumer equipment is leading the vanguard to IPv6 and corporate equipment is languishing behind in command-and-control IPv4 enclaves.)

Post reply on HN