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)
> 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.
> 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.
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.
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.
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.
> 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.
- 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.
> 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.
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.
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.
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.)
That was fine as long as the network was thinnet or thicknet as most universities probably were, because a well planned network would start at the hub and extend out and terminate. When networks became more based on 10baseT and you could add devices by just plugging a very cheap hub into a wall socket, and then plug another hub into that, for cheap, you could get loops more easily, and degraded broadcast quality, and that kills the entire network.
Yes, it was indeed! But the PITA-ness and need for termination meant that once it was planned and implemented, it was rarely monkeyed with for a while.
MIT originally was single /8 network (Class A from before CIDR), however they had it subdivided with routers AFAIK pretty soon.
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.
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.
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.
Exactly - your L2 Ethernet shouldn't go beyond immediate connection between end system and first L3 router, in DC conditions it should be to Tor... Or on-Hypervisor router.
Larger L2 spans should be done only when required, and preferably with things like TRILL/SPB.
> (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.
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.
> 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.
> 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.
> 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".
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.
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.
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).
>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.
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.
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.
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...
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.
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
No it means my router is not routing IPv6 traffic. It doesn't need to though. My router and all of my computers each have /128 addresses. No issues. 19/20 on ipv6-test.com.
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.
You need a /48 (or /56) if you want to do your own subnetting and keep using SLAAC (which is the default way for assigning v6 addresses and detecting address conflicts).
A /64 is not enough for that. You can still create your own subnets, but you will be on your own with address assignment
BellAliant in eastern Canada, the only provider of residential layer 1 fiber in my area, still isn't even assigning a /128 or /64, let alone proper delegation.
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.
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?
> - 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
> 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)