Hello IPv6: a minimal tutorial for IPv4 users | Hacker News Reader

Hello IPv6: a minimal tutorial for IPv4 users

metebalci.com

232 pointsnotmine133792 comments

IMO, IPv6 sucks for home users and labs. Prefix delegation means your routable IP scheme could change underneath you, and firewalling connections using PD addresses is really hard (unpredictable prefixes, privacy extensions change suffixes constantly), though some routers make it easier, like Google Wifi. I think most will end up NATing a single external IPv6 with a private IPv6 network behind it.

I wish IANA and friends would let home users and other smaller entities request global /56 address blocks and force ISPs to peer/announce (nothing crazy, just a default route).

EDIT: end users should be able to request static blocks from their ISPs for free, not IANA.

> I wish IANA and friends would let home users and other smaller entities request global /56 address blocks and force ISPs to peer/announce

You want portable /56s?

You realise that's incredibly expensive for everybody else right? Today's portable /24s are a considerable burden, and you'd like to have far smaller routes assigned for basically your personal convenience. I don't know for sure what it would cost, but certainly thousands of dollars per year each seems like a very modest estimate.

Fair point. Let me request them for free from my ISP then. None of this "pay $20/mo for a static prefix" garbage. IPv6 loses all of its benefits if my entire network is ephemeral and has to rely on prefix delegation propagation.

You agree it's a "fair point" that this would be incredibly expensive, but then you say you want it to be free.

Is it simply that you don't understand why it's incredibly expensive? It means everybody who does network routing has to buy extra hardware to track all this useless noise you've decided ought to be "free", that hardware costs money.

Your ISP choosing to charge you for stuff that doesn't cost them anything is completely separate. I would say "Choose an ISP which isn't shit" but you're probably American and have no such choice. Too bad?

My correction is for static prefixes from an ISPs block, I don't see that as an unreasonable free request. No peering, they just static route that block to the IPv6 address they assign you.

Sure, yes, there's no reason this should be hard for your ISP to arrange. I guess it might be slightly painful for large ISPs say if you're a huge American ISP and customers can just up and move all their gear from San Francisco to New York and expect the IP addresses to stay the same that's kind of annoying to implement and the service for those customers will either suck (a user in New York finds all their data routes via the West Coast) or cost you more.

But in the general case, for a customer who is just using the Internet from the same place as last time, there's no benefit to changing their IP addresses and clearly there's no reason static addressing shouldn't be free, it's just like one database entry for them to do it.

I could imagine them explaining OK, you get static BUT it might change if you move home or something, and that feels pretty acceptable to me.

For what it's worth I get static IPv6 and IPv4 (although of course the IPv4 is a tiny block, only a /27 IIRC whereas I have a /48 of IPv6) but I'm in the UK and with a specialist ISP that cares a lot about this stuff.

> For what it's worth I get static IPv6 and IPv4 (although of course the IPv4 is a tiny block, only a /27 IIRC whereas I have a /48 of IPv6) but I'm in the UK and with a specialist ISP that cares a lot about this stuff.

Even some of the large ISPs can get it right. I used to have fiber optic service from a large telephone company (starts with "C" ends in "EnturyLink") and could use their account management portal to go and get anything up to a /26, complete with setting up reverse DNS, just by clicking a button and agreeing to a relative pittance of money. I think the /26 was $40 per month and the /28 I had was $10 a couple of years ago. They would give me a static IPv6 /48 for nothing, just a click, and delegate the reverse DNS zone to me. A /56 that was supposedly dynamic but never actually changed was given by default.

The problem seems to be which ISPs want to do what. ISPs run by phone companies seem to think of their networks, and the customer networks attached to them, as actual internetworked networks. ISPs run by video companies seem to think of their networks as extensions of distribution systems for linear television channels.

If you move your physical connection, renumbering seems totally reasonable (they need to handle internal routing). Otherwise, I see no reason the assigned address shouldn't be static, other than money extraction and perhaps privacy.

@tialaramex is making their point rather poorly, using the term "expensive" without explaining how, and being a bit aggressive about it.

The more ASes that exist, the more routes need to be propagated. If every household were theoretically assigned a network that they could take with them anywhere, and advertise, a well-connected router would have millions and millions of routes to track and forward.

One of the goals of IPv6 was to make the Internet more hierarchical to avoid this.

I agree with your point. I should be able to get a static PD from my ISP (a /56 or /60 easily) and that should stay the same for all time, given a MAC address. In other words, PD should be stateful.

I have thought about setting up my LAN with "Unique Local Addresses" and doing NAT66 if I can ever manage to get a public IPV6 address from my ISP.

You don't need to do NAT66; just enable ULA. Interfaces can have multiple IPv6 addresses, not just one. So you will get your static local addresses and for outbound traffic, a random globally routed address from the currently assigned prefix would be used.

I know routing table bloat is annoying and it's hard to do tons of routes in an ultra-fast way, but I do want to point out that "millions and millions of routes" translates to "tens and tens of megabytes".

But if you're doing fast hardware routing, that's tens and tens of megabytes of TCAM, not DRAM. It's more akin to CPU cache in terms of latency, capacity and cost.

You can get a $600 Epyc with 128MB of cache. That shouldn't be too much compared to the tier of router we're talking about, right?

That's L3 cache though; they only have 0.5 MB of L2 cache per core.

I'm not really sure how much each of these types of memory cost, but I did find [1] which says "The cost of TCAM is also about 30 times more per bit of storage than SRAM". That suggests a CPU with something more like 0.5-1 GB of L3 cache would be a closer comparison.

[1] https://research.ijcaonline.org/volume115/number7/pxc3902299...

Well, prefix delegation would be fine as long as the ISP guarantees that the delegated prefix will be stable. But they aren't guaranteeing that unless you pay extra for a static v4 (because they're tying v6 assignments to v4 assignments), which is indeed asinine.

That's indeed the original reasoning for building in on-the-fly renumbering to IPv6, but it was supposed to still be a rare event.

But consider: (1) that for ages the route table growth has been slow due to v4 shortage, and router memory has kept getting cheaper on the normal memory cost curve for this plateau phase in history, and (2) Consumer ISPs have been abusing this and making prefixes jump around even on CPE reboots, instead of having them stable for months and years like is the design, and (3) mechanisms to smooth out renumbering haven't been deployed because ISPs have gotten away with doing [2] without any mitigations.

The 'net infra could probably afford to start giving many more people portable blocks, and it would be only fair that ISPs would have to pay a bit for their sins regarding [2], and to this would add incentives to do [3].

regarding (1), the route table growth is actually not slowing. as we run out of IPv4 addresses there is more fragmentation as bigger blocks are split up and sold.

In graphs I saw it slowed somewhat.. but even if you are right, this is still waste of router memory since those same routes could be for much bigger v6 blocks instead of tiny v4 ones.

And also, in absolute terms it's currently tiny, ~ 2 M routes that can be represented in a couple of addrs worth of space each in line card memory when deciding just which interface to forward, and keeping in mind that only core routers that don't outsource transit to other upstream telcos have a need to keep this in memory.

That was my experience as well.

I have three seperate VLANs (Untrusted Devices, Servers, Normal) which is easy with IPv4/NAT/HAProxy.

IPv6 was unpredictable in how I could get more than a /64 subnet (so no VLANs allowed). After guessing at how to get it for a few hours, I was able to get a /56 subnet, and set it up. I even disabled IPv4 (dual stack caused it's own set of issues). IPv6 was much, much slower. I was unable to track down why it was so much slower, so I ended up just doing back to IPv4.

The address size, and pains of the IP scheme changing underneath might hopefully push mDNS and other naming systems to really catch up so that we can stop using IP addresses for things like firewall rules.

I would much rather have a local network naming system that works and use human readable names in all situations where I want to specify firewall rules. It's a shame that this still really isn't an option, the technology is there, it just needs some polish to not require so much tweaking.

Having to do a DNS lookup for each firewall rule is going to suck. Not to mention blackholing traffic when cached DNS replies are out of sync with the actual IP.

I can see that there is a user-space daemon, that watches TTLs in the resolved DNS records and if they change, updates an corresponding ip set in the firewall.

Doesn't have to be DNS, could be any sort of cache on the router that updates when new hosts come online or the prefix changes.

Plus blackholing temporarily due to a stale cache is better than blackholing permanently due to a stale rule pointing to an old IP.

how do client firewalls deal with that?

the don't know the router lost its connection

This is an ISP problem, not an IPv6 problem. With the greatly expanded address space, nothing stops an ISP from allocating each customer a static prefix. To not do so is, in my eyes, just another undignified attempt at rent seeking.

The solution I've come up with here is to use ULA's in addition to the public prefix. If my public prefix changes it can cause a temporary disruption in service availability from outside my home, but on the inside everything uses the ULA prefix for communication so I don't have giant messes during re-addressing. This has also tackled my issues with inter-vlan routing, since my switch does not have the ability to take a prefix delegation but can route static IPv6 subnets just fine.

My big issue remains multi-homing for smaller setups like my homelab and SMB's. When doing NAT (and I could do NPT with my v6 network) all my policy is at the gateway - what traffic goes over what link, etc. I lose all that with IPv6, and I'm still trying to figure out how to deal with it - what used to be simple policies like "my home office uses CenturyLink and only fails over to Sparklight if that's down while everything else does the opposite" now require some way to push down the client or more sophisticated IFTT style setups on the router (if this gateway goes down depreciate the prefix and advertise this one instead).

Are you assigning a public and private IP to everything, or just private and using NAT on the gateway?

Everything gets a public address as well as a ULA one.

For multi-homing, you can also look at it another way: the only thing you have to do to move downstream hosts from one prefix and router to another is different router advertisements.

In theory, you could actually disable router advertisements on the routers themselves, and run a small daemon that just announces the right information.

> In theory, you could actually disable router advertisements on the routers themselves, and run a small daemon that just announces the right information.

I actually investigated the feasibility of something like this - but the way IPv6 RA's work requires they be sent from the link-local address of the router itself, so I'd have to run said daemon on the router itself - at which point I can just write some scripts to modify configuration on event triggers.

Do you use SLAAC or DHCP6 for assigning the ULAs? I'm looking for something that lets me use ipv6 on my home network, and my ISP changes my /64 PD disturbingly often.

I use SLAAC - I actually use my main switch (Juniper EX2300) to advertise those since it can handle routing the inter-vlan traffic on my network, and then my router/firewall handles the public prefixes.

I also haven't found it compelling to implement IPv6 on my small network. If I use v6 addressing for my own nodes, what do I gain? I don't need my internal network to be routeable. And even if I could come up with some use, relying on those addresses being routeable creates a single point of failure at the tunnel gateway.

Alternatively, I could setup a v6 tunnel for my home network and each of my remote nodes that doesn't have native v6, "beyondcorp" style. But I want to have an "internal" network where everything is definitely running over wireguard. But wireguard over v6 just means more bytes on the wire and suboptimal routing, and v6 over wireguard falls under the first point.

Now it's true that if one of my VPS's was v6 only, then I'd start to care about v6 reachability to keep my wireguard mesh a full mesh. But at this time I just don't see the use, and without a use anything I setup for kicks will eventually fall apart like my previous few tests of IPv6 did.

I'd like to disagree on IPv6 sucking and would like to steer this blame towards whoever decided to not be persistent. Firewalls can handle changing prefixes by masking it. Hosts can request certain addresses. Cheap dual-homing is something that IPv6 does not quite do, because that requires NAT66, which is controversial. Also, RIPE tells us to do persistent delegations:

https://www.ripe.net/publications/docs/ripe-690#5-2--why-non...

AFAICT pretty much all home ISPs don't offer persistent delegations. Mine changes with every power outage plus a few other times a year. You can upgrade to their "business plan" and pay 4x as much for 1/2 the bandwidth to get a persistent delegation of a /48, but "Having more than one device on the internet" shouldn't require a business plan these days, and so the choice is NAT66 or having all the issues that that RIPE publication calls out.

The irony for me is that I pretty easily get a static IPv4 block from my ISP (they do it for free for me, but should be $5/month or something).

Trying to get a static IPv6 prefix is not possible. So there is actually LESS availability of static IPv6 for some reason - even through the address space is so massive, the rules around using it are so restrictive you can't get something static.

This ripples into absolutely everything - now doing firewall rules is a total pain. Additionally the machines and devices are constantly changing IP addresses (on IPv6). So the old small business setup model where a DHCP server is setup, some static IPs configured then reservations in DHCP made, then everything works great no matter what happens in DNS or other servers etc is gone, which feeds mgmt dashboards so you can easily do a alerts or period end report - so and so used 5TB, is something wrong with their machine type stuff - get's harder.

I am curious what recommended IPv6 solution is for this classic small biz situations.

Dual WAN, primary ATT, secondary comcast (for failover). Local DHCP server for addressing. Monitoring / reporting by User/IP. VPN terminating at a sonicwall or similar.

1) Without a static IP - what do I give my VPN users? 2) With all the IP address changes, how do I assign IP's to users to get my monitoring tools to play well with everything. 3) With PD, how do I get my failover working well?

NPt - eg: https://docs.netgate.com/pfsense/en/latest/nat/npt.html or NAT66 and friends for outbound. DNS for inbound. Sadly most VPNs don't support SRV or similar. Wireguard perhaps.

It's not pretty 8(

This is the issue.

I wish we could have had (static) PD, then locally define a netmask, and then DHCP or straight static for local devices.

Internally, you'd ignore PD for routing within netmask - so regardless of where WAN link went you'd still be ok locally. But because address space is so big, and PD is so big, these local addresses were also (with PD attached) globally routable.

I'd also love if IPv6 only devices had an EASY way to hit IPv4 (ie, xxx:ipv4 in IPv6 address space, with the border device which could be dual stack translating over to IPv4) as a default transition config. One problem is that IPv6 put so many new concepts in it doesn't map as cleanly as maybe IPv5 might have (just an extension in size of space).

> I'd also love if IPv6 only devices had an EASY way to hit IPv4 (ie, xxx:ipv4 in IPv6 address space, with the border device which could be dual stack translating over to IPv4) as a default transition config.

Doesn't NAT64 do exactly that? It translates `64:ff9b::<32 bit IPv4 address>` -> `IPv4`. I get there's stateful/stateless issues and "default" configs (i.e. DNS64), but sounds like the technology is there.

I think 464XLAT is probably the better solution currently as you can interop with things like websockets etc / SIP? One problem is none of this was default, 464XLAT came out because folks were trying to solve this. That's much different than every router that supports IPv6 auto supports a NAT64 type solution. Other issues are created because of overall protocol differences etc.

>So the old small business setup model where a DHCP server is setup, some static IPs configured then reservations in DHCP made, then everything works great no matter what happens in DNS or other servers etc is gone, which feeds mgmt dashboards so you can easily do a alerts or period end report - so and so used 5TB, is something wrong with their machine type stuff - get's harder.

It's obviously more complex, but could this not be solved by running an internal DNS resolver, assigning every machine a hostname, and having those machines use e.g. ddclient or similar to ensure their IPv6 address is current in the internal DNS table?

I mean I know it's easier to remember that e.g. 192.168.1.4 is your printer, and .5 is the CNC router, etc. but I feel like that's not how IPv4 was intended to be used.

Depending on your DHCP and DNS servers, they might already have this built in. dnsmasq will maintain DNS entries for the DHCP leases it hands out, and can also add AAAA records if it sees a SLAAC message for a MAC address it gave a DHCP lease to. BIND’s servers (dhcpd, named, kea) can be set up so that for each DHCP lease assigned, a DDNS update is sent.

>and having those machines use e.g. ddclient or similar

How does this work on my networked PDU, UPS, speaker, light hub, or even printer for that matter since you mention it [0]? There is vast universe of "machines" that aren't full fat PCs (or if they are under the hood grant zero native flexibility to the operator over any of that). But they all can take a static IP fine and then get managed from there, shoved into VLANs which are also straightforward with IPv4, etc.

I agree with GP that this is a really, really common scenario in SMB. And it means a lot of stuff can stay up and active with quite minimal network infrastructure.

>but I feel like that's not how IPv4 was intended to be used.

First, why not, and what source? People have been using static IPv4 for this sort of thing for as long as I can remember ethernet (mid 90s) at least and probably before I ever did my first networking at all. But second, so what? It's useful, makes sense and has tons of usage. It allows basic networks to get bootstrapped in a super lightweight fashion and its dependable when there are issues at higher stacks. It certainly doesn't scale, but conversely at scale handling more moving parts reliably also is much more feasible so that's ok.

It definitely seems like one of those things that should have been a gimme in a new standard. With the opportunity to have close enough to limitless addresses why did they have to make it more restrictive then the old very limited system?

----

0: Ignoring granted that many of them don't support IPv6 at all, because some already do and that number may eventually be 100% or sufficiently close. And that would probably happen sooner if there was more demand due to IPv6 meeting existing needs.

Also in isolated networks like industry automation or so. You have a couple of devices and static addresses. Very simple.

A couple of years ago I tryed to make my homenetworks complete IPv6, but then I realised, IPv6 is a such pain for me at home with a couple of VLANs and so. Of course just NAT is bad, but it had also it's good points.

Is see no reason why you couldn't do the same with IPv6 - setup dhcp with ULAs and static ips, perhaps with a hosts table or local dns to keep things readable.

> This ripples into absolutely everything - now doing firewall rules is a total pain. Additionally the machines and devices are constantly changing IP addresses (on IPv6).

A dynamic prefix sucks for a number of reasons, but at least for firewall rules you can just match the last 64 bits using a mask. At least, ip6tables can do this.

> Additionally the machines and devices are constantly changing IP addresses

You probably mean the privacy extensions addresses (AKA temporary). Those are complementary to the persistent ones (EUI-64) and shouldn't concern your firewall because they aren't normally used for receiving connections, unless you intend to block outbound traffic.

> I am curious what recommended IPv6 solution is for this classic small biz situations.

For a small business, the recommendation is: get a (static) /48 from your ISP, split it into several /64 subnets, advertise a prefix for each subnet, a DNS server (RDNSS) and let the clients assign their own addresses via SLAAC. There's no need for a DHCPv6 server (in fact some clients don't support it, see Android) or reservations because the addresses are unique and static.

If your ISP is evil and doesn't give you a static prefix, you can advertise a ULA prefix (basically the IPv6 version of RFC 1918) and use that in place of the dynamic one. Clients will use the dynamic prefix for Internet connections and the ULA for local services (printers, NASs, etc.).

That works for one ISP, the issue is with two (a common design for SMB network reliability). Earlier recommendations I read were "get your own public /48 assigned and peer with both, NAT including NPT is not good". But it turns out some (all?) authorities won't do that for SMBs, so we're back to some form of translation, probably on top of ULAs running internally.

Another related issue is the ULA design - they're meant to be randomly generated but it's not enforced, so you just know there'll be a bunch of internal networks with custom duplicate ULAs that will only show up when some businesses merge, so we'll be back to re-ipaddressing subnets.

IPv6 has changed a bit since the first RFCs (privacy extensions etc) so I imagine at some point someone will look at this and make some changes to suit. I wonder if it'll be relaxing ULA recommendations or adding something else entirely.

I'm insanely excited for never having to worry about subnet size again but it just doesn't seem like there's a clear best-practice one-true-way everyone-agrees way forward right now for a whole bunch of popular use-cases.

> At least, ip6tables can do this.

pfSense only got support for PD-aware firewall rules a few months ago[1], and it seems rather limited as such.

[1]: https://redmine.pfsense.org/issues/6626

I have done PD of a /60 from Comcast for three years and my prefix never changed. I can't imagine why it would or should.

Mine is pretty stable but anytime the cable modem gets fried by lightning the new one gets a new prefix. I wish it was tied to my account somehow.

That's because the DHCPv6 client in the modem generates a unique DUID for itself and the new one cannot know the fried modems DUID.

If your cable modem is regularly getting fried by lightning, you can get lightning arrestors inline on the coax connection.

I have one now but I suspect the lightning shall … resist arrest.

What we really need is to decouple IP service from the last-mile cable/DSL/fiber ISP, so they provide a dumb pipe to a nearby PoP where you can choose your IPv4/IPv6 provider.

This system would need to support MTU >= 1500, and enforce geographical locality so it doesn't get banned by Netflix.

> IMO, IPv6 sucks for home users and labs. […] EDIT: end users should be able to request static blocks from their ISPs for free, not IANA.

This is a technical argument for IPv6, because there is no reason to worry about exhaustion and scarcity with it. The issue here is on the business side of things.

As others have mentioned: as a kludge you can assign ULA on your network and then use NPTv6 for when the prefix you're delegated changes in the non-static scenario.

Anyone have any recommendations for a beginner who would also like to learn what's meant by ARP, NDP, ethernet, and basically everything. I've been a developer for decades, and I understand the top level of http[s] well enough, but networking is basically a mystery to me.

Read a CCNA book for the fundamentals and basics.

Computer Networking: A Top-Down Approach is a great text book on this. It is a huge text book but written in a way where you can drop in on the parts of the stack where you need to.

I think a good way to learn networking is to set up your network from scratch: either build a router using a PC with some BSD, GNU/Linux or buy a router supported by OpenWRT.

Start with something simple at first: a basic home network. You need to set up a firewall and NAT rules, a DHCP server, a DNS relay or maybe a recursive server. You'll learn a good deal about how the protocols works and why they work that way just by reading the manual pages and trying to configure the software. Also, read the RFCs, really, most are well written and do a better job at explaining how stuff works than a random tutorial. For more practical skills, you can also make your own cables by buying STP/UTP cables and connectors.

Then try to build an IPv6-only network, this is especially fun if you don't have native IPv6 from your ISP (i.e. set up a 6in4 tunnel). With IPv6 you can try subnets and routing more easily, also configuring NAT64 and talking to old v4 devices from v6 is pretty fun. Finally you can experiment with more exotic stuff like IPSec encryption between your machines, hosting your email or authoritative DNS server, a VPN, etc.

Networking 101

ftp://vert.synchro.net/main/INTERNET/NETWK101.ZIP

A text file. Yes, old. But it works.

EDIT: damn, the file is wrong.

I recommend watching Ben Eater's series on networking. He starts from sending a signal over a basic cable and builds up a networking model from there. https://youtube.com/playlist?list=PLowKtXNTBypH19whXTVoG3oKS...

I've been looking for a summary like this for years. I'm quite comfortable with IPv4, but haven't understood IPv6 well enough to start using it in my home network. Thanks for sharing, going to read this over a few times to make sure I understand everything completely.

Just my experience:

The funny thing about IPv6 is that you see a lot of curmudgeonly rhetoric about it here and elsewhere, but once you dig in a little, it snaps and you think "hey, this really makes sense!" And then you wonder why others are grumbling so much.

The main thing to do is to stop thinking about IPv4. Just put the IPv4 concepts aside and start thinking about it as if IPv6 just showed up on the scene as the L3 protocol.

Forget about crusty concepts like NAT, because NAT was a kludge anyway. Just think about the big address space. Understand that firewalls examine traffic going from one side to the other and that NAT is not part of that equation (people frequently argue that NAT is valuable for network security - nonsense).

Just start fresh with it and resist the urge to hug your old IPv4 teddy bear.

> (people frequently argue that NAT is valuable for network security - nonsense).

Most of the devices on my home network should never be routable from the Internet. Without NAT, they suddenly are, and I have to go out of my way to configure a firewall (either on the device or an intermediary appliance) just to get back to that baseline. That is more configuration to get right and is a worse experience than when they were just impossible routes under NAT. So, I get it, NAT was not "designed" with security as a primary consideration, but when thousands of Grandma's printers are suddenly pwn'd because their 2.6.x kernels wind up answering traffic from the public Internet, it's quite devilish to say "gosh, well, they should never have relied on things continuing to work the way they always have, because it was philosophically never meant to be that way."

It's quite possible I'm missing something (because I haven't bothered to learn much about v6 yet) and consumer routers are smart enough to drop unsolicited traffic to "private" addresses (however that is determined). If that's the case I cede a little.

I don't agree with this argument at all.

If routers can enable NAT by default, they have a stateful firewall by default. The printer won't be on the internet unless you punch a hole in NAT, it won't be on the internet unless you punch a hole in that firewall. You can have that firewall without NAT.

This is true but there is still a difference. How do you know if that protection is working? With NAT, if it's online then basically the only way is if NAT was used.

With a firewall then I have no idea. I guess you have to check on the router, and maybe do some kind of online test? Can't imagine grandma doing that.

I do think a firewall is a cleaner solution but it's definitely true that NAT is way more foolproof.

These arguments are just hogwash, but they just don't seem to go away. Literally every IPv6 topic on Reddit and YCombinator is just filled with people going on and on about NAT being essential for security, despite that being clearly false.

I wonder what can be done to educate people that NAT != Firewall, and that all IPv6 home routers also include a default-deny firewall?

It seems like the concept of NAT=>Secure and also RFC1918=>Secure isjust embedded so deeply in people's consciousness that they assume !NAT=>!Secure.

> NAT being essential for security

That's not what I said at all. Read it again. NAT is a more foolproof kind of security.

> NAT != Firewall

NAT is effectively a pretty good firewall isn't it? How would you access a device behind NAT?

You do it in exactly the same way you would if the NAT wasn't there.

NAT only applies to outbound connections. It does nothing for inbound ones, and thus doesn't provide any firewalling functionality.

It means devices on the internet cannot directly connect to devices in your network. That is a function you would have to use a firewall for without NAT. Therefore NAT does provide some firewall functionality.

If I'm wrong I'd like to know, but you haven't provided any evidence that I'm not!

There's no "directly". It's not like your PC is plugged in to the Telco backbone router, right?

No matter what, the packets have to traverse multiple hops, including the residential router that you've currently got.

It's not like the IPv6 packets magically "hop over" the router and skip it, they're processed the same way, except for one difference: the destination addresses are not altered in the process.

Note that IPv4 is supposed to work the same way. Back in the good old days, you'd get a public routable address even for home connections. Every router in the path to your PC would not modify the destination address.[1]

The RFC1918 address space was formalized in 1996, but I had an Internet connection as far back as 1992, and the "IPv4 Internet as we know it" materialised back in the '82-'83 era, and HTML in 1990.

This means that NAT is a "new thing", a workaround for the problem of address space exhaustion only. It wasn't a solution for security. Firewalls existed before, firewalls existed after, and generally worked the same with or without NAT.

Without NAT, my home Internet is still secure. Inbound connections are blocked by default. If I permit an inbound connection, it takes the same path through the same devices. All of the processing is the same, except for not having a single 32-bit address[2] rewritten in the packet headers.

Having my internal network devices being 1:1 addressable from the outside doesn't mean accessible. The default-deny firewall is in place either way, NAT or no NAT.

PS: If you can afford the USD 40 per public IPv4 address, and your ISP is willing to sell you a /C or whatever, you can totally have the non-NAT "experience" with IPv4 on your home network! It'll work the same as IPv6, with directly addressable devices with public-routable addresses. The firewall in your router will work the same! You'll still be just as protected.

[1] THIS is where the perception that NAT is required for security came from! In the 90s, most endpoints did not have a built in default-deny firewall, especially Windows. Most people dialed into the Internet via a modem and got a public IP on their PC, exposing them to attackers without any firewalls in the way (software or hardware). When people were forced to move to NAT, as a side-effect they also got a firewall on their network for the first time. Now? Every residential Internet router has a firewall, as does every endpoint on top of that.

[2] Okay, the address, the port, TTL, and the checksum.

Network Address Translation (NAT) has the side effect of ignoring incoming connections that do not match an explicit port mapping.

A firewall will block any incoming connections unless explicitly allowed.

Basically the NAT happens to overlap a bit the job of the firewall as a side effect of how it works. In practice NAT and firewall are implemented by the same system. For example look at iptables on Linux.

> Most of the devices on my home network should never be routable from the Internet. Without NAT, they suddenly are [...]

Copy-pasting from a previous discussion a little while ago:

---

IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4.

An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table(s) it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.

The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.

With IPv6 the address/port rewriting is not done.† Only state tables are updated and checked.

New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.‡

There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.

The security comes from the state checking.

[…]

I have a printer with an IPv6 stack. I also have IPv6 addresses from my ISP. Yet somehow my Asus AC-68U prevents the public Internet from reaching my printer.

† It is possible to have private IPv6 addresses using ULA, and then the router/firewall uses NPTv6 to rewrite the prefix (leaving the /64 interface component alone).

‡ Just like with IPv4 (NAT), to allow unsolicited 'new' connections in you have to do do firewall hole punching with (e.g.) UPNP. But by default things are blocked.

---

* https://news.ycombinator.com/item?id=28390634

IPv6 firewall on my Asus:

* https://www.asus.com/us/support/FAQ/1013638/

> The main thing to do is to stop thinking about IPv4. Just put the IPv4 concepts aside and start thinking about it as if IPv6 just showed up on the scene as the L3 protocol.

That's exactly the problem with IPv6 and why its struggle to get traction as a replacement for IPv4. It's the Gnome3 of networking protocols.

> And then you wonder why others are grumbling so much.

The core concepts of IPv6 isn't the hard part. The hard part is fighting issues like why suddenly you can't resolve anything[1], why your Android device isn't resolving this host when IPv6 is enabled on your router[2] or how the hell you're supposed to write firewall rules when your prefix changes and the firewall only supports static IPs[3].

[1]: Router hands out its global IPv6 address as DNS server to clients and router just got a new prefix. Bonus points to pfSense for not having a way to disable this...

[2]: Android refuses to use supplied IPv4 DNS server if it gets an IPv6 address...

[3]: pfSense couldn't until mere months ago: https://redmine.pfsense.org/issues/6626

Me too, this was very good. The only thing missing is how it interoperates with IPv4. Can you represent IPv4 addresses as IPv6 addresses? If so what happens when you communicate with them?

Can someone forward this to Verizon? They can't seem to find the "Enable IPv6" button with their head so far up their...

Ahem, I'm quite frustrated with my provider :). But sanctioned monopolies are a serious drag on moving tech forward. Even if IPv6 isn't a panacea, things need to be more agile than this if we're going to really innovate.

Currently only getting an SSL error.

Hug of death?

Edit: Google cache

http://webcache.googleusercontent.com/search?q=cache:https:/...

This is very digestible, thanks so much for this. I'm going to set up a little test IPv6 network this weekend and play around!

This reminded me to re-check for the first time in a year or so which sites I frequent are now dual-stack IPv4 and IPv6. Surprisingly Hacker News is one of the few that isn't these days...

> In IPv4, multicast addresses are used, there is no concept of broadcast address

I think there's a typo there, and the author meant IPv6, right ?

Amusingly apropos: Visual Studio Code was hanging when opening a remote session on my Raspberry Pi.

Turns out I had added "AddressFamily inet6" to the ssh config for connections from my laptop to the Pi. Once I changed that to "AddressFamily inet", it worked fine.

(2020)

the difficult part with ipv6 is that we can't use it as a url, contrary to ipv4, so what's the use ?

You can use it in a URL. Just put square brackets around it. Like http://[::1]/

So in essence privacy extensions (hiding of internal network) are available, but disabled and unsupported by default.

Another thing are incoming connections - first thing i do with new router is disable UPnP, so clients cannot drill ad-hoc holes into my private network. How to do that with ipv6 network?

That's not correct. Privacy extensions are supported and on by default in Windows, macOS, mobile stuff and on generally in desktop Linux setups. Not sure what the author is running as they claim it's off by default in Ubuntu, as that's contrary to my experience. (Guessing they have a server install as they talk about netplan instead of NetworkManager?)

> So in essence privacy extensions (hiding of internal network) are available, but disabled and unsupported by default

On Ubuntu Server: probably. Why would you want a randomized IP address on a server, anyway? Netplan doesn't seem to be designed for desktop, so I don't think it's a problem in most cases. Perhaps you want to add privacy to a raspberry Pi running a scraper or something, but there aren't many use cases I can think of that require privacy extensions in a headless system.

On user-facing operating systems (Windows, Ubuntu, Manjaro, Android, probably macOS/iOS/ipadOS as well) privacy extensions are enabled by default AFAIK. They're also completely supported. In fact, I can find more posts online about people wanting to _disable_ the feature rather than how to enable it.

> How to do that with ipv6 network?

Any decent router will put a firewall between you and the internet, blocking incoming traffic. Your IP may be publicly routable, but it's not reachable by default in most consumer appliances. You shouldn't need to disable anything.

Many people will confuse NAT with a firewall, but those are two entirely different things! NAT makes devices unreachable by breaking the internet, but there are many NAT loopholes (port knocking, NAT slipstreaming, etc.) that will bypass NAT if you can get a user to install software or even open a website from inside the network. In the IPv4 world the firewall and NAT setup are often combined, leading to a broken firewall in many cases because they automatically add the necessary firewall exceptions to make NAT work.

UPnP generally does two things: it sets up NAT _and_ it adds a firewall exception. Reserving a port on the router's public IP address (NAT) is of little use if you don't accept traffic on that port (firewall), after all. On IPv6 there's no need to bother with NAT, but the firewall exception still needs to be added for a port to be reachable.

Effectively, the difference is that if you have three smart lightbulbs that are all reachable on port 80, you don't need to forward port 80, 81 and 82 to different IP addresses to make them available to the internet; you need to add three firewall rules for port 80 and then just use their real IP addresses instead. That's exactly how IPv4 was always designed to work before the IP address shortage began and NAT became the standard.

For rare exceptions, there are some forms of NAT available on IPv6, but they're only designed in circumstances where your network design is basically flawed (like for those ISPs that hand out a /128 address instead of a /48 or /56 like they're supposed to, forcing routers to do NAT for no good reason).

You're assuming that smart lightbulbs are to be trusted. You can't trust them, neither can you trust most of the software you run in your home network.

Take a simple app crash report on your desktop computer. Assuming i'm using VPN (but even without it, it's an issue)... With NAT, your crash report will contain network adapter address: 192.168.0.x. With ipv6, you're disclosing your /56 (or /64) ip range... disclosing your physical location, your ISP, ...

> ...This post is aimed for home and small office networks. So if you know about ARP, DHCP, and NAT, and if you wonder how these work in IPv6 networks, this post is perfect for you.

Hardly a home user friendly introduction. An acronym soup begins right at the start, where the author describes his network setup.

Not sure if users would feel convinced to adopt IPv6 on their networks without understanding the benefits first.

So you're not the target audience, and you discovered that right at the start, from a clear statement. Sounds like the author succeeded to me.

I agree with this statement. Even for those who know all the IPv4 related acronyms, the author spits out a bunch of new ones without any attempt to explain them. I just closed it, it's not at all readable for small office or home network users.

Reply on news.ycombinator.com