[neilalexander]

> Why isn’t IPv6 more popular? ... and an arguably overly complex design.

I really don't know where this ridiculous claim comes from. Yes, IPv6 addresses look more complicated but various other things about the protocol are drastically simplified — no more on-path fragmentation, simpler header formats and fewer required header fields, correctly implemented link-local scopes, previously separate ICMP+ARP+IGMP protocols consolidated into ICMPv6 (which handles neighbour discovery, router advertisements, path MTU discovery and multicast group membership amongst others), no more broadcast, and in many cases clients will quite happily get along without DHCP. If anything, it is considerably less complex.

[phicoh]

In my experience, IPv6 is often more complex. The main exception is that by and large IPv6 doesn't have NAT, so that saves a few headaches in that area.

No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems.

Moving fragmentation to an extension header similarly creates problems. Dealing with extension headers is just more code complexity.

Link local does not work (reliably) in browsers: https://[fe80::1]/ doesn't work on most platforms.

ICMP, ARP, and IGMP perform completely separate functions. Putting then all in ICMPv6 doesn't help. In contrast, having ND in ICMPv6 leads to code complexity. In IPv4, ICMP logically uses IP to send packets with uses ARP. In IPv6, ICMPv6 logically uses IPv6 to send packets, which uses ICMPv6 for neighbour discovery.

IPv6 created a lot of flexibily by having multiple addresses per interface created automatically from router advertisements. And multiple routers on a subnet that can each support different prefixes (poor man's multihoming). Net result, certainly with devices that frequently connect to different networks, such as phones and laptops), is way too complex.

That said, the only way forward is IPv6. Putting everything behind multiple layers of NAT is ultimately going to fail.

[zamadatix]

> No more on-path fragmentation is not a benefit. IPv6 and large DNS replies is an endless source of problems.

I thought this was the other way around, IPv4 only guarantees reassembly up to 576 bytes so DNS avoided issues with split UDP datagrams by limiting the payload to 512. Ends stuff got added on once the defacto internet mtu became 1500 and there was more room. Things like 4G have a 1482 MTU though so it may seem frag!mentation helps but in reality most IPv4 routers don't fragment and reassemble anymore they just drop. In practice with DNS this has meant either keeping the packet size closer to 1k or using TCP which negotiates miss and handles correcting/merging lost split payloads.

If anything IPv6 has made the situation cleaner with a minimum supported MTU of 1280 vs IPv4s 68 guaranteeing the 1kish UDP DNS payloads can make it through without relying on pmtud.

[phicoh]

That's two separate issues. The default (maximum) IPv4 reassembly buffer is 576. This issue is solved in DNS with the EDNS udp buffer size option.

For IPv4, you can just send a 1500 octet DNS reply and it will be fragmented as needed. For IPv6, you have to fragment at 1280 or do path MTU discovery (which doesn't work very well, certainly not for DNS over UDP). You can always fragment at 1280 but many firewall will drop fragmented packets, also because IPv6 extension header parsing is complicated.

[zamadatix]

> For IPv4, you can just send a 1500 octet DNS reply and it will be fragmented as needed

As mentioned in theory yes, in practice most hardware base IPv4 routers don't actually implement fragmentation anymore.

> You can always fragment at 1280 but many firewall will drop fragmented packets, also because IPv6 extension header parsing is complicated.

Many of the same firewalls drop fragmented DNS packets as well because of cache poisoning attacks and other issues.

All that isn't to say people haven't tried/used fragmentation for UDP DNS packets but rather it's historically never worked reliably or securely anyways which is why all of the current BCPs RFCs are to avoid it at all costs.

All of that is why EDNS0 specified the min max to be 1220 bytes and dnsflagday last year focused on 1232 of payload bytes instead of 1500 (minus change).

[ArchOversight]

> Link local does not work (reliably) in browsers: https://[fe80::1]/ doesn't work on most platforms.

1. You have to specify an interface, since fe80::1 may be in use on more than one link (so that becomes https://[fe80::1%en0]/ for instance), 2. that IP address may not be assigned to any devices on the link-local network.

What platforms does it not work on?

[tsimionescu]

That breaks significant assumptions of the WWW. Specifically, it means that devices have different addresses when accessed by different hosts, which breaks all hyperlinks the Server may send back, unless the User Agent also sends the scope ID to the Server. However, the scope ID is meant to be meaningful only in the context of the host that originated it, so RFC6874, which introduced this concept officially in URLs, prohibits sending it.

Overall, this means that, in practice, WWW on IPv6 does not support link-local addresses. This is especially true given that none of the major browsers support them.

[phicoh]

On POSIX systems (including MacOS), just 'fe80::1' doesn't work. You need something like fe80::1%eth0. The 'eth0' is in general unknown, because it is the name of the outgoing interface, which varies from OS to OS and even between Linux distributions.

Then in URLs you have the question whether it is 'http://[fe80::1%eth0]' or 'http://[fe80::1%25eth0]' ('%'s escaping). And by and large browsers have decided that the whole '%eth0' is complex from a security point of view, so they don't support it.

In some cases Windows does allow just a 'fe80::1'. But I don't know under what circumstances.

[crawshaw]

The URL you have in parentheses with a zone name is not supported by Chrome:

https://bugs.chromium.org/p/chromium/issues/detail?id=70762

In general, zone support is spotty. Many networking libraries do not handle it at all.

[ArchOversight]

Sounds like Chrome is broken.

[tsimionescu]

It's not supported in any browser, so good luck using it on the web. Even more, the semantics for such a URL as defined by RFC6784 means that common HTTP features like redirects can't work: client sends a request to http://[fe80::6%7], the User Agent sends a request to server with "Host: http://[fe80::6]", and receieves a 302 response with "Location: https://[fe80::6]" . What can client do next?

[HALtheWise]

I'm curious what you see as the reason that putting everything behind multiple layers of nat can't work? It seems to me like it has worked pretty well so far, and we're nowhere close to running out of (ip, port, ip, port) tuples.

[zamadatix]

1 layer of nat on each side hasn't bad, the 2 layers of nat on each side carriers have been moving to has been a godawful mess of complexity for any conversation where at least one side isnt a public IP (e.g. p2p chat/calls).

[Akronymus]

> The main exception is that by and large IPv6 doesn't have NAT, so that saves a few headaches in that area.

I wish. ipv6 under cgnat is a PAIN.

[kstrauser]

You could drop everything before "cgnat".

[pilif]

While routing at global scale is much easier, running v6 in a local network has more moving parts than v4 had:

- 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)

[ansible]

> 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 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.

[throw0101a]

> 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.

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.

[zekica]

It took me a long time to finally "get" IPv6.

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

[goohle]

> default gateway is always on fe80::

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.

[themulticaster]

Just a heads up for anyone confused about 169.254.1.1: 169.254.0.0/16 is the link-local address block for IPv4, but link-local addressing is rarely used in IPv4. OTOH, the fe80::/10 address block on IPv6 is widely known since link-local addresses are mandated by the standard.

[Dagger2]

If you already know v4 then there's not much to learn. There are only really three differences:

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.

[curryst]

> 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.

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.

[p_l]

- A reminder that Ethernet doesn't do broadcast, only multicast. (And L2 switching is broken by design anyway, but that's a story of hysterical raisins for another day)

- 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.

[AnIdiotOnTheNet]

> And L2 switching is broken by design anyway, but that's a story of hysterical raisins for another day

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.

[p_l]

The story as I learnt it goes around this way - hopefully on this forum someone with first-hand knowledge could chime in:

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.

[wmf]

Ethernet switching isn't broken. STP works fine at reasonable scale (as long as you leave it on) and 1980s history isn't relevant now. Obviously routing is better than switching and we can now do routing to the host with affordable "L3 switches", but switching is still usable.

[icedchai]

I knew several colleges that had the entire campus on a flat /16 network. Dozens of buildings, 1000's of computers. It worked fine. Well, except for the "no firewall" part (this was mid 90's.)

[p_l]

The very reason we're talking about IPv4 vs IPv6 is because of 1980 (and 80s, 1980) history, concerning people getting convinced that the temporary solution that IPv4 was supposed to be will be won't need more than obviously short 32bits and will be replaced with something better before wide adoption.

[kazen44]

avoid spanning tree like the plague in large datacenter networks as well. because of the scale and it becomes an impossible black box.

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.

[ArchOversight]

I am a firm believer in layer 3 everywhere. No more layer 2 connectivity as much as possible.

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.

[pilif]

> (And L2 switching is broken by design anyway, but that's a story of hysterical raisins for another day)

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.

[90minuteAPI]

> The applications broken in v4 are so niche that most people won't notice.

Except when you’re building these applications. Then it’s infuriating! Maybe more often a feeling of hopelessness than anger.

[neilalexander]

How switches "handle" multicast is not a new problem — many will treat it as broadcast traffic and flood it across the network segment, leaving clients to work out if they are interested or not. More intelligent switches might perform IGMP snooping to avoid flooding and this will be no more complex with IPv6 than it is with IPv4 today.

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.

[pilif]

> many will treat it as broadcast traffic and flood it across the network segment

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.

[icehawk]

> 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.

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.

[spinax]

> because while you can remember v4 addresses and v4 address assignments, this is impossible for v6 addresses

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".

[lowercased]

Good word ergonomics.

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.

[phicoh]

When the web was young, millions of people have learned how to type www.example.com. People would often spell out the 'http://' on the radio.

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.

[lazide]

People did that because they had no choice - here people are just not opting in to v6 because they can still use v4, which is easier. Very different situation.

[FroshKiller]

They could use AOL keywords, too, but they still advertised and used Web URLs.

[p_l]

You shouldn't remember numeric addresses anyway, and we had reasonable ways to deal with that for decades now. It's really just human unwillingness (ok, and maybe a bit of BSD Sockets shitshow, but as much as I hate them for keeping networking broken it's not their fault this time).

[pilif]

>And you didn't touch on "should I use Stable Privacy or EUI64 for my laptop IP?"

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.

[spinax]

I'm literally on Arch using NetworKManager, when creating a new connection it defaults to Stable Privacy in the dropdown, but EUI64 is listed first in the dropdown itself. So, since you didn't actually state which one to use, now what? Point being: don't be condescending claiming "outdated OS", IPv6 is a minefield of footguns and there are many of them just like this choice.

[neilalexander]

The sane default is Stable Privacy. It's a good thing that NetworkManager agrees if it has offered that to you as the default. Ultimately though any confusion that arises from how that option is presented to the user is really a bug in NetworkManager and not in IPv6. The footgun here is that NetworkManager allows you to change it so easily without offering any explanation as to what changing it will do.

[jamespharaoh]

Do ISPs really give out /128s? That's, erm, that's monstruous! Mine gives a /60 but their router doesn't have any way to use it, which is a bit shit. Still, 10 gigs symmetric...

[jagger27]

Rogers in Canada gives out a /64 by default, and a /56 if you send a hint.

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.

[throw0101a]

> Bell, on the other hand, gives a big fat /nothing and doesn't support IPv6.

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.

[sidewndr46]

Spectrum here in Austin TX assigns me a /128

[ArchOversight]

If you request a prefix delegation using DHCPv6 you will get up to a /56 which you can subnet.

8 bits of subnetting means you can create up to 256 different subnets.

[wmf]

Your router may be doing something wrong because DHCPv6-PD worked fine for me on Spectrum Austin.

[willis936]

My two data points:

- Spectrum gave me /64.

- Comcast gives me /128.

[ArchOversight]

Spectrum and Comcast both will happily hand out prefix delegations that are larger than the /64.

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.

[Dagger2]

Comcast uses /64 for the WAN network and will give you up to a /60 routed prefix for LAN-side networks.

[pilif]

Which means the /64 is not usable if you want to do subnetting and use SLAAC and the /128 is not useable at all if you have more than one machine.

No such issues with v4.

That was my point about subnetting.

[willis936]

I had the /64 via DHCPv6-PD/SLAAC.

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.

[pilif]

A /128 is a single address and given the state of v6 NAT that means it can’t be shared with other machines in your network which means only your router will be able to access the v6 internet without the router being a proxy and you using it

[uvesten]

I got a /48, and I think it will take me a while to put all those addresses in use. I'm using 9-10 now, so while I've certainly started down the path, the end is not in sight just yet.

[sedachv]

Have you heard of unique local addresses? Most of the LAN "problems" you describe are solved by using ULAs. Yes, even name resolution - the hosts file becomes useful again. PCP (the 2013 replacement for NAT-PMP) supports IPv6 port opening; UPnP has supported it since IGDv2 (2015). Any ISP that does not do IPv6 prefix delegation ("your ISP only gives you a single v6 address"), might as well stop claiming IPv6 support.

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.

[otabdeveloper4]

Exactly this.

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.

[willis936]

Thank you. This summarizes my headaches I've had while trying to implement a dual stack in my home network.

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?

[ArchOversight]

> - broadcasts for address discovery have been replaced by multicast which is much harder for switches to handle correctly

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.

[crawshaw]

Because it wasn't designed as a drop-in replacement, so using ipv6 necessarily means using ipv4+ipv6 for a time. That time is now twenty years and counting.

[l0b0]

There should be lots of implementations of both protocols by now - could we compare them for length and complexity to determine some sort of objective measure of the difference?

[SSLy]

Linux's net/ipv4 is 2.7MiB of code, net/ipv6 is 1.7MiB.

[benttoothpaste]

I tried to set up IPv6 a while ago, and it looked simple at first. After configuring the router - just flipping "enable ipv6" in gui - my machine got 10 IPv6 addresses (why this many? I don't know). Cool.

I then set up the firewall to expose one of these addresses and I could ssh to my machine from the outside world. A win!

Unfortunately the win was short lived. Eventually I lost the ability to ssh in. It turned out that the 10 IPv6 addresses were replaced by a different bunch of 10 addresses. So I would have to reconfigure the firewall again. I decided it was too much work for me and disabled IPv6. Maybe some other time.

[jppittma]

This is what dynamic dns is for. Your isp should have you covered there, and if not there are other free ones.

[magicalhippo]

How does dynamic DNS help change his firewall rules?

[kaba0]

How is that the fault of IPv6 over eg. your internet provider?

[benttoothpaste]

I did not blame anyone, just shared why it is not great for me.

[BruiseLee]

Believe it or not this feature is intentional. It is for your privacy so you cannot be tracked by your IP address...

[api]

It’s less complex in many ways for machines but the long addresses make it unwieldy for human beings.

[e2le]

At least in local network environments, using mdns (avahi) to discover other hosts is preferable and possibly more user friendly for less knowledgeable users.

[aaaaaaaaaaab]

If only we could attach names to IP addresses somehow!

[api]

... and have it work reliably ...?

The real problem is standing up DNS on local or enclave networks with zero effort. Right now setting up DNS is a pain, configuring DNS is a pain, and mDNS doesn't scale and is slow.