So that's me in a nutshell. I've read various things on IPv6 over the years, and I think I might even have the O'Reilly book laying around somewhere. I understand some of the basics, but I don't really "get" IPv6. I'm still at a bit of a loss on how my local network should be configured, and what services are needed for what.
Though I'm really at a loss as far as network security and firewalls go. I've been setting up firewalls with NAT for 20 years, but I'm still not sure how its all going to work with IPv6. In the mean time, I just disable all IPv6 stuff on the firewall machines, and try not to worry about it.
In the age of constant probes, a simple mistake can compromise our entire network, which sounds... unpleasant.
I suppose I'll just keep putting off learning about IPv6 until we get to the point where I can't order a cloud instance from our provider that comes with an IPv4 address.
The same way: tracking of state.
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 its table 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 address/port rewriting is not done. Only state tables are altered 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 read, looked up in a state table, allowed or not depending on either firewall rule or state presence.
But as soon as you don't try to apply IPv4 conventions to IPv6, it really clicks: - RA packets don't have default gateway - default gateway is always on fe80:: and is the actual host that sent the RA - You can configure hosts via RA not to send packets directly to other hosts with the same prefix (instead sending them through the gateway) by disabling On-Link flag - You can use RA and DHCPv6 over any link, not just Ethernet
In theory, we can reserve `169.254.1.1` as default gateway (and default DNS server) for IPv4, to get rid of DHCP protocol. I'm doing so in my embedded project for network connection via USB, because it makes network configuration static.
a) You use a /64 from the subnet your upstream assigns you, instead of a /24 from RFC1918.
b) You don't use NAT.
c) You run an RA daemon on the router instead of a DHCP server.
Firewalling is exactly the same as in v4 -- you block inbound connections and permit outbound connections by default. A firewall without NAT is no different to a firewall with NAT (since NAT only helps with address space exhaustion and contributes nothing to securing the network).
One advantage of v6 is that you don't receive constant probes. Any v4 address will see a steady stream of them, but that's not true on v6. (v6 is so big that randomly scanning addresses in the hopes that they're assigned to something that will respond is unviable.)
You'll get v6 just fine if you spend some time using it on a real network.
Hopefully you've heard this before, and I'm sorry if I'm beating a dead horse, but NAT is not a firewall. It does render hosts behind the NAT not connectable from the Internet by default, but that's because they're unroutable not a security feature.
I.e. there was a bug a while ago that let people send UPnP requests over WAN to your router, which makes your hosts suddenly routable. NAT won't stop that from happening and your hosts are basically internet-accessible. A firewall configured to only allow outbound connections would have stopped that.
So if you consider NAT a routing feature, it works the same it always did. You configure the firewall to only allow outbound connections, unless you have a specific reason to allow inbound connections. I don't actually know if it's less secure. NAT required kind-of targeted attacks to exploit, but the IP space for v6 is large enough I would expect a dramatic drop in probe traffic. There are 3.4 * 10^38 addresses. It's just too large of a space to casually scan.
- network names have been steadily been getting better with mDNS and related tech
- SSDP (the tech underlying UPNP) already covers IPv6, there's no need to add new one (your bigger possible issue is incomplete implementation on v6 side on CPEs)
- home router/CPE vendors are converging on "standard v6 default firewall" ruleset (it's actually something I encountered in random bought AP/router combos from random electronics store, not something techie-oriented). It establishes basic filtering that resembles what people think they get from NAT, and couples well with UPNP's support for IPv6. This also includes proper handling of ICMPv6
- subnetting is a problem, yes. Especially due to SLAAC vs DHCPv6 issues in some OSes.
It's not all nice, but it's getting there.
Well I'm curious. I can't think of any significant way it is "broken by design", so either this is hyperbole or I'm so used to the brokenness I'm not even thinking about it.
1. Ethernet happens, is designed around bus topology with shared medium and everyone talks by filtering out messages for themselves (with half of the addresses for multicast)
2. Digital works on moving ethernet from bus to star topology, design explicitly disallows connecting stars to each other without L3 router
3. Unfortunately, a non-trivial product range ends up based on LAT - essentially serial port over ethernet - and supposedly because of miscommunication LAT is very... raw-ethernet solution. No way to route it sensibly.
4. Suddenly, there's a need for larger L2 segments, except Ethernet has no way to support them (it finally gained one around starting ~2005 by throwing everything you know about L2 switching out)
5. It's too late to add features to ethernet that would make it work in larger span than single star, and possibility of loops bringing down exists, so do multicast storms (those weren't fixed).
6. The budget doesn't allow to put in a lot of computing power, a z80 gets thrown in. Spanning Tree Protocol gets created in vague hope to mitigate the curse of large L2 ethernet zones. We get stuck with primitive MAC learning 7. Genie is out of the box, and since you can crap out a too-large ethernet network much cheaper than do a proper routed one, the curse continues. Since cheap is the king, you often do not even get STP. Large scale networks fail when interns misconnect cables, multigigabit backbones end up doing 10mbit because STP made an ancient switch in the cleaning closet into root of the tree. Cats and Dogs living together, etc.
8. From around ~2005, proposals to fix it proper show up. Solution? Put routing into ethernet, using IS-IS for routing. On the other side, increasingly crazy centralized "decentralized" SDNs also try to setup L2 forwarding to deal with applications that can't deal with real IP subnetting. Somehow passing ethernet over XMPP over TLS (with BGP involved somewhere) is still better than ethernet's mac-learning.
CISCO had a lot of early customers among universities because dedicated box ran better than random unix workstation pulled out from other duties (or even sharing them) running RIP and the like.
there is a reason evpn exists, and is it to solve this exact issue by making gateways handle all logic normally stretched across to the other side of a l2vpn.
It's how I deployed VM's at scale using BGP from the VM host to the top of rack switch. VM's could route to each other, but no layer 2 connectivity.
It allowed for easy migration of systems between VM hosts too, as the ToR would learn the /128 or /32 and traffic would route to the new VM host.
Larger L2 spans should be done only when required, and preferably with things like TRILL/SPB.
absolutely, but in ipv4, the breakage has the effect of some niche-applications like TV streaming to client-machines breaking whereas in ipv6 it has the effect of the whole network breaking.
The applications broken in v4 are so niche that most people won't notice.
>SSDP (the tech underlying UPNP) already covers IPv6, there's no need to add new one
yes, but it's very badly supported still. I have not seen this work in any home-network yet, be it because of broken OSes, broken applications or broken router software.
>This also includes proper handling of ICMPv6
You're making me hopeful. Back when I was setting things up in 2014, the situation was a minefield of brokenness, sometimes even with UI showing huge warnings about my explicit allow-ICMP-rule I had to add after the default was to block all ICMP.
Except when you’re building these applications. Then it’s infuriating! Maybe more often a feeling of hopelessness than anger.
Multihoming also isn't new and isn't really IPv6-specific. It might be more likely that you'll have multiple IPv6 prefixes but the majority of source address selection rules that you are used to in IPv4 will still apply, and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway.
Subnetting is probably not easier or harder. The address length doesn't change how subnetting or how routing tables work and I am not really convinced that an IPv6 addressing plan should really be any worse or better than an IPv4 addressing plan. The minimum prefix size of /64 for a network segment is about the only extra consideration there, but if anything, it should be simpler than having to manage globally routable address space and private address space separately given that you can now manage address space as a true single hierarchy.
You're right that SLAAC vs DHCP can add a bit of mental overhead, but for most configurations, configuring DHCP and letting RAs be sent automatically in IPv6 is not much different to configuring a default gateway in DHCP on an IPv4 network.
Finally, as for ICMPv6, it has always been bad behaviour to just outright filter ICMP without consideration for what it will break. The stakes are indeed higher than in IPv4, but it seems worth it if we can eliminate two entirely separate protocols in the process and firewall vendors and admins are just going to have to learn that.
I get there are a lot of cognitive factors involved in why people resist IPv6 but it really isn't as alien as most people think and most of the concerns are easily answered.
and some will silently swallow them until you update their firmware. Broadcasts on the other hand are so common (and required for ipv4 to work) that they are rarely broken.
If multicast is treated as broadcast, stuff works "fine", but because of IGMP snooping and additional "intelligence" the switches often employ, unfortunately, the failure modes I have seen tend to be packet loss rather than overeager packet forwarding.
And with multicast packets dropped in a v4 network, some niche applications will stop working, but with multicasts packets dropped in a v6 network, your network will stop working. Period.
> and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway
of course you have. My point isn't that v6 multi-homing is any different from v4 multi-homing. My point is that multi-homing is rare with v4 but very common and required for v6. So what's often not an issue at all on anybodies radar in a v4 network is something everybody has to deal with in a v6 network.
> most of the problems can be trivially solved.
absolutely. But they don't have to be solved by staying with v4 and thus inertia is even harder to overcome than it normally is. That was my point.
Multi-homing (connecting to multiple different networks) isn't required in IPv6 at all. Having multiple different addresses on the same subnet isn't multi-homing, and the link local address of fe80:: isn't a different network. Operating systems won't even use the link local address to establish a connection unless specifically forced to.
A thousand times this (and your other points, great reply thank you) - the ergonomics of using IPv6 at a local scale are atrocious for mere mortals. And you didn't touch on "should I use Stable Privacy or EUI64 for my laptop IP?" and other small cuts and bruises which technologists think everyone should "just know".
All the "but ipv6 is better because... xyz" just don't ring true to me, but I'm not a full time admin.
I still see "Quit remembering addresses - we have DNS!". My consumer equipment all have "192.168.0.1" and "192.168.2.1" type addresses. Relying on my browsers to be able to discover 'cable_modem.dyn' on a local network doesn't work - instructions will just say "go to 192.168.0.1" and put in a password. Good luck trying to get people to go to "[ff00]:0:0" or... whatever the heck you'd have to put in. Having foreign CSRs trying to explain what a square bracket is to people at home trying to set up a new cable modem... way too much headache.
And... there are millions of people that have to do this. There's perhaps tens of thousands of high-level network admins working to route everything through major global networks, but there's hundreds of millions of people that have to deal with and use all the stuff at the end points, and millions of us who serve as defacto "tech support" people for families/friends/neighbors.
No doubt, browsers could let people type fe80::1 and make it work.
It will take a while before people are used to the double colon, etc. But it also took a while before people where comfortable typing IPv4 addresses.
yes. because this has by now been solved by using a non-outdated OS. The defaults have become good enough for this not to be an issue any more, at least in my experience.
Bell, on the other hand, gives a big fat /nothing and doesn't support IPv6. I don't understand how they can roll out 1.5Gbit FTTH but refuse to support IPv6. Their mobile network uses it, of course, so it's truly perplexing.
Meanwhile Teksavvy, who piggybacks over Bell's copper and is also using PPPoE for DSL 'logins', has been giving out IPv6 for a couple of years now.
8 bits of subnetting means you can create up to 256 different subnets.
- Spectrum gave me /64.
- Comcast gives me /128.
Comcast for example right now is giving me a /128 for my router, and a /60 which I have used to set up multiple VLAN's.
Spectrum will give you a /56 in a prefix delegation, and a /128 for the router.
No such issues with v4.
That was my point about subnetting.
The /128 is given to any clients that connect as there is no NAT and the ISP isn't worried if I use a thousand addresses.
A /64 is not enough for that. You can still create your own subnets, but you will be on your own with address assignment
I am not sure why you think multihoming is a bad thing. That is one of the major things that in my experience makes IPv6 LAN configuration a lot more useful and robust than IPv4 with private addressing. It sounds like you misunderstood some basic IPv6 assumptions - configuring an IPv6 LAN is not that much more difficult than an IPv4 one. I would never go back to IPv4 for my LAN.
The vast majority of IP networking end users only care about their LAN. (Home and business networks.)
Making things easier for ISP's is not what they asked for and not what they want.
My current curiosity is why my DDNS service only allows IPv6 or IPv4 records for a single domain. Why can't I have a dynamic IPv4 record for the one IPv4 address I have and then make many dynamic IPv6 records as subdomains?
Multicast is sent to a broadcast address and replicated to all ports. If the switch doesn't do any IGMP snooping, multicast and broadcast are the exact same thing.
> - address discovery is now mostly handled via SLAAC which is different from how it worked via DHCP and also doesn't universally allow setting name servers which then will still require DHCP to actually get a working network (if you run v6 only), so now you have two daemons running when in v4 you only needed one.
SLAAC now has support (and all major operating systems support it) for sending DNS servers down as information in the router advertisement. I do not run a DHCPv6 server on my local network and all my systems get my local DNS information without issues
> - hosts are multi-homed by default and rely heavily on multi-homedness which might invalidate some assumptions you had when configuring hosts.
This was also the case in IPv4, nothing new here.
> - for a network to be meaningfully useable, you need working name resolution because while you can remember v4 addresses and v4 address assignments, this is impossible for v6 addresses
Even in IPv4 no-one tends to remember IP's, we have solutions for that like systems automatically announcing themselves on the local network using mDNS.
> - and in a similar vein: Subnetting is harder because the addresses are much less memorable. If you want to subnet a 10.- v4 network, in many cases, you can do this in very memorable full-byte chunks.
There is no subnetting. Just give the local network a /64.
> - also subnetting: due to many ISPs still doing /64 allocations to their customers
If you are a home users with a single flat network, that is all you need. If you are a power user and need multiple networks, your ISP probably has a way to do a prefix delegation request that is larger.
> Worse, some ISPs only do a /128 assignment (one address)
Name and shame them... the /128 should only be for the external customer gateway, and is not strictly necessary. Most ISP's allow you to ask for an IA_NA for a single address, and an IA_PD for a prefix delegation.
> - v6 relies on ICMP much more heavily but this fact has not propagated to default firewall settings, so in many default "let me turn on the firewall" configs, your v6 network will break in mysterious ways.
v4 also breaks in mysterious ways when you just blindly firewall ICMPv4. It's the reason we have so many dumb work-arounds for MTU issues because "ahhhhh, firewall all the things"
> there's no widely-supported equivalent to UPNP or NAT-PMP
UPnP and NAT-PMP were replaced with https://en.wikipedia.org/wiki/Port_Control_Protocol which was standardized in 2013.
> So while v6 is much easier to handle on a global scale, it's at the same time much harder to handle at your local site
I completely disagree. IPv6 is as simple to deploy as IPv4, and in fact because everything now has a globally unique IP address is makes routing so much simpler.
- broadcasts for address discovery have been replaced by multicast which is much harder for switches to handle correctly
- address discovery is now mostly handled via SLAAC which is different from how it worked via DHCP and also doesn't universally allow setting name servers which then will still require DHCP to actually get a working network (if you run v6 only), so now you have two daemons running when in v4 you only needed one.
- hosts are multi-homed by default and rely heavily on multi-homedness which might invalidate some assumptions you had when configuring hosts.
- for a network to be meaningfully useable, you need working name resolution because while you can remember v4 addresses and v4 address assignments, this is impossible for v6 addresses (yes, you can of course manually assign addresses in your prefix and you can just make them low numbers and hide everything else behind a ::, but you still have to remember your prefix which still is impossibly hard and there's no cheating there even if you know somebody at your ISP because it's not entirely under their control either)
- and in a similar vein: Subnetting is harder because the addresses are much less memorable. If you want to subnet a 10.- v4 network, in many cases, you can do this in very memorable full-byte chunks.
- also subnetting: due to many ISPs still doing /64 allocations to their customers, and due to the way how SLAAC works, you often have to decide between subnetting or SLAAC (which still is the default in many OSes). Worse, some ISPs only do a /128 assignment (one address), so now you're back in NAT territory, only that's really, really murky waters because next to nobody is doing this ATM. If your ISP only gives you a single v6 address, you are practically screwed about running v6 internally. If you're given a single v4 address (which is common practice), you can do NAT/RFC1918 addressing and you're fine.
- v6 relies on ICMP much more heavily but this fact has not propagated to default firewall settings, so in many default "let me turn on the firewall" configs, your v6 network will break in mysterious ways.
- in home networks where you want devices to be reachable directly (for P2P usages like video calls or gaming), there's no widely-supported equivalent to UPNP or NAT-PMP yet to punch holes into your firewall to make clients reachable. Yes, you don't have to do NAT any more, so clients are potentially reachable, but you really don't want that, so your firewall is still blocking all incoming connections, but now there's no way for an application to still punch temporary holes through which is a solved problem in v4 (where a hole is punched and a temporary port-mapping is created)
There are more issues as your network grows bigger, but this is what I had to deal with in my small networks (<50 hosts) where I can say with certainty that v4 was much more straightforward to get up and running than v6 (though I was much older when I was learning v6 than when I was learning v4, so I might also just be getting old and slow)
Yes. These are all solvable issues, but they are huge ergonomic downsides that are now pushed on local network admins to the point that for them it's still much easier to just disable ipv6 rather than learning about all these small issues and working around them.
So while v6 is much easier to handle on a global scale, it's at the same time much harder to handle at your local site, but, the internet is as much about the global scale as it's about the local site and when the new thing is much harder to use than the old thing, inertia is even bigger than in the normal "everything is mostly the same" case (where inertia already feels like an insurmountable problem)