Mobile IPv6 support is theoretically possible. Practically, like so many cool things you could do with your network, ISPs won't have it. The best you can do is hide it from your ISP by using some tunnel, but then you might as well just use a VPN.
> For instance, IPv6's NDP is built on actual IPv6 packets (ICMPv6), rather than some spoofed IP-lookalike thing. No layering violation, and, thanks to multicasting, no need to dump a bunch of broadcast traffic on the layer 2 network.
Only if the L2 network actually supports L2-multicast. Ethernet doesn't, except if your switches are intelligent enough. With cheap ethernet switches, multicast will be simulated by broadcast.
And actually, you can never avoid a layering violation. The only thing that NDP avoids is filling in the source/destination IP portions with placeholders. In NDP, you fill the destination with some multicast IPv6 address. But that is window dressing. You still need to know that this L3-multicast IPv6 address corresponds to a L2-multicast MAC address (or just do L2 broadcast). The NDP source you fill with an L3 IPv6 address that is directly derived from your L2 MAC address. And you still get back a MAC address for each IPv6 address and have to keep both in a table. So there are still tons of layering violations where the L2 addresses either have direct 1:1 correspondences to L3 addresses, or you have to keep L2/L3 translation tables and L3 protocols where the L3 part needs to know which L2 protocol it is running on, otherwise the table couldn't be filled.
I think that's actually about avoiding NIC to CPU traffic. NICs have multicast address filters which determine which packets to receive, but they always receive broadcast packets. It would have been more useful in the 90s, when NICs weren't so programmable.
It's pretty silly anyway. NDP is more of a layering violation than ARP, because now IPv6 has a stupid circular dependency on itself. Mapping L3 addresses to L2 is a layer below 3, it is not part of layer 3, it is part of the sub-layer that adapts between 2 and 3. DHCP should be part of that sub-layer, too.
Did you know that for every kind of network that IP can run on top of, there's a whole separate standard specifying how to adapt one to the other? RFC 894 specifies how to run IP over Ethernet networks. RFC 2225 specifies how to run IP over ATM networks.
IMHO all this whining about "layering violations" is stupid. One will always need some kind of layer glue, neighbors bordering on each other need to know something about each other, correlate addresses, etc. It is impossible to do anything practical without such violations. And it doesn't really matter if that glue protocol belongs to the below layer, the above layer or is a weird hybrid of both. Because in the end, the glue will necessarily be a hybrid and it will be specific to the combination of both those layers.
The only thing one should really really really avoid is the TCP mistake of not just having some minimally necessary glue, but that tight coupling of TCP connections to IP addresses in the layer below.
It's a layering violation because it makes the inter-layer-glue more messy than it should be. IPv6 having a circular layer dependency on itself is not a good thing. It makes that glue messy. ARP is cleaner glue.
> Only if the L2 network actually supports L2-multicast. Ethernet doesn't, except if your switches are intelligent enough. With cheap ethernet switches, multicast will be simulated by broadcast.
True, but outside bottom-barrel switches, any switch that's not super old should support multicast, no?
Regarding the rest of your comment, I really don't see how all those things count as layering violations. Yes, there is tight coupling (well, more like direct correspondence) between l2 and l3 addresses. However, these multicast addresses are actual addresses furnished by IPv6; nodes answer on these addresses. Basically, the fact that there is semantic correspondence between l2 and l3 is basically an implementation detail. Whereas ARP even needs its own EtherType!
And, yes, nodes need to keep state. But why is that relevant to whether or not this is a layering violation? When two layers are separate, they need to be combined somewhere ("gluing the layers together"). The fact that the glue is stateless seems irrelevant. But again, I'm just a sysadmin.
h264 and h265 are patent-encumbered and therefore very expensive and/or dangerous. Patent trolls would rip Mozilla apart and eat all their money. The only reason H.264 works atm is that Cisco sponsors a plugin for that.
H264 patents are finally starting to expire, all the known patents have already expired in Europe.
As for HEVC, that particular licensing trash fire continues to burn bright. VVC had an opportunity to learn from the situation, and decided what they really wanted was a trash fire that burned even brighter.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
> In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses.
Only a problem for home users with frequently changing dialup networks from a stupid ISP. And even then: Your host can still have ULA and link-local addresses (fe80::<mangled-mac-address>).
RFC6724 is still valid, they are only debating a slight update that doesn't affect a lot.
> Then there's DHCP.
DHCPv6 is an abomination. But not for the reasons you are enumerating.
> With IPv4 the almost-universal DHCP serves as an easy way to do network inspection.
IPv4 DHCP isn't a sensible means to do network inspection. Any rougue client can steal any IP and MAC address combination by sniffing a little ARP broadcast traffic. Any rogue client can issue themselves any IPv4 address, and even well-behaved clients will sometimes use 169.254.0.0/16 (APIPA) if they somehow didn't see a DHCP answer. If you want something sensible, you need 802.1x with some strong cryptographic identity for host authentication.
> Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6).
Yes, that is grade-A-stupid stubborness. On the other hand, see below for the privacy hostname thingy in IPv4 and the randomized privacy mac addresses that mobile devices use nowadays. So even if Android implemented stateful IPv6, you will never be reliably able to track mobile devices on your network. Because all those identifiers in there will be randomized, and any "state" will only last for a short time. If you want reliable state, you need secure authentication like 802.1x on Ethernet or WPA-Enterprise on Wifi, and then bind that identity to the addresses assigned/observed on that port.
> With IPv6 there's literally _nothing_ similar.
Of course there is. DHCPv6 can do everything that IPv4 DHCP can do (by now, took some time until they e.g. included MAC addresses as an option field). But in case of clients like Android that don't do DHCPv6 properly, you still have better odds in IPv6: IPv6 nodes are required to implement multicast (unlike in IPv4 where multicast was optional). So you can just find all your nodes in some network scope by just issuing an all-nodes link-local multicast ping on an interface, like:
(The interface ID (like eth0, eno1, "Wired Network", ...) is necessary here because your machine usually has multiple interfaces and all of those will support those multicast ranges, so the kernel cannot automatically choose for you.)
> And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
DHCP option 12 ("hostname") is an option in IPv4. Clients can leave it out if they like. There is also such a thing as "privacy hostname" which is a thing mobile devices do to get around networks that really want option 12 to be set, but don't want to be trackable. So the hostname field will be something like "mobile-<daily_random>".
What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests. DHCPv6 forwarders may add that option, but in lots of equipment this is a very recent addition still (though the RFC is 10 years old by now). So if you unbox some new hardware, it will identify by some nonsensical hostname (useless), an interface identifier (IAID, useless, because it may be derived from the MAC address, but it may also be totally random for each request) and a host identifier (DUID, useless, because it may be derived from the mac address, but it may also be totally random for each request). Whats even more stupid, the interface identifier (IAID) can be derived from a MAC address that belongs to another interface than the one that the request is issued on. So in the big-company usecase of unboxing 282938 new laptops with a MAC address sticker, you've got no chance whatsoever to find out which is which, because neither IAID nor DUID are in any way predictable. You'll have to boot the installer, grab the laptop's serial number somewhere in DMI and correlate with that sticker, so tons of extra hassle and fragility because the DHCPv6 people thought that nobody should use MAC addresses anymore...
> That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
Look, I've been doing IPv6 for 20 years, starting with a 6to4 tunnel and then moving to HE.net before getting native connectivity. I'm probably one of the first people who started using Asterisk for SIP on an actual IPv6-enabled segmented network.
I _know_ all the pitfalls of IPv6 and IPv4. And at this point, I'm 100% convinced that NAT+IPv4 is not just an accidental artifact but a better solution for most practical purposes.
> What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests.
Yes. DUIDs were another stupid idea. As I said, IPv6 is a cascade of recursive WTFs at every step of the way.
And let me re-iterate, I'm not interested in academic "but acshually" reasons. I know that you can run IPv4 with DHCP giving out publically routable IPv4 addresses to every host in the internal network without NAT. Or that you can do NAT on IPv6 or laboriously type static IPv6 addresses in your config.
What matters is the actual operational practice. Do you want a challenge? Try to do this:
1. An IPv6 network for a small office with printers, TVs, and perhaps a bunch of smart lightbulbs.
2. With two Internet uplinks. One of them a cellular modem and another one a fiber connection.
3. You want failover support, ideally in a way that does not interrupt Zoom meetings or at least not for more than a couple of seconds.
4. No NAT (because otherwise why bother with IPv6?).
Go on, try that. This is something that I can do in 10 minutes using an off-the-shelf consumer/prosumer router and IPv4. With zero configuration for the clients, apart from typing the WiFi password.
Well, I can do that with OpenWRT, no idea which prosumer devices already implement this, but it isn't rocket science: Announce the Prefix of the currently active connection, invalidate the other one. Will interrupt all your TCP connections, but they are toast anyways, most software should handle this just fine. It's quite the same as a Wifi-to-Cellular handover.
> Announce the Prefix of the currently active connection, invalidate the other one
And this doesn't actually work. Prefix deprecation is a best-effort feature that is not implemented correctly in tons of devices, including such rarely used niche operating systems as macOS. It even technically violates RFC4862 (section 5.5.3).
I highly recommend actually trying what I proposed. Not in a theoretical hand-wavy way, but actually setting it all up and verifying that it works. I did not pose this challenge in a "gotcha" way. I really was not able to make it work cleanly with either Mikrotik or OpenWRT routers.
fd::1 is somewhere in the reserved ::/8 space where various stuff like old ipv4 mapped addresses and localhost reside. What you probably mean is something like fd00::1, but that is something you shouldn't use, because 'fd00::/8' is a probabilistically unique local address (ULA) block. You are supposed to create a /48 net by appending 40 random bits to fd00::/8. Of course, if your fair dice roll lands on all zeroes, and you are ok with probable collisions in case of a network merge, you are fine ;)
In home networks, the idea of merging with someone else's network is... most certainly not worth worrying about. Maybe you marry someone or become roommates with someone who also picked fd00::/8? And you still want two separate subnets? Other than that I don't see a scenario where it matters.
Granted, if you're doing this in a corporate setting (where merging with someone else's address space is a lot more realistic), then yes definitely pick a random 40 bits. But at home? Who cares. Same as using 192.168.1.0/24 instead of a random 10.0.0.0/24 subnet... it's not worth worrying about.
I'm having my own and my girlfriend's router (in different flats) connect to each other with a wireguard tunnel, so I can print on her printer. Non-colliding addresses make this a lot easier.
Basically, there is no standard beyond the ages-old requirement to have abuse@ and postmaster@ email addresses that react to such reports. Which Google doesn't follow at all, you just get redirected to some useless web form which requires a Google account and the sacrifice of a goat.
It is entirely Google's fault, and they should be shunned for it and their emails dropped. But unfortunately, they are too big for that by far...
AD is LDAP+Kerberos, which has existed in the Unix/Linux world long before Microsoft bastardized it. So pick any of half a dozen LDAP server implementations and any of 3 or 4 Kerberos implementations and use those. If you want point-and-click/drool interfaces, use FreeIPA. If you really want it to look like AD, use Samba 4. Even Windows boxes will hardly know the difference.
Group policies don't exist and won't ever exist on Linux. Group policies are LDAP entries that are copied on system boot and user login into their respective parts of the local registry. Software may then read, interpret and use those registry entries. On Linux that wouldn't work for numerous reasons. First, on a multiuser system rebooting to apply configuration changes is not viable. On windows that's apparently fine because its single-user anyways, and reboots are an accepted fact of life. Also, to apply a system policy that is intended to limit what a user could do, asking the user's software nicely via registry entries is stupid and insecure. Lots of software won't even read the registry and have group policies that it will obey. Want to get around an Internet Explorer Group policy? Use Chrome or Firefox!
So what you do instead on Linux is: If it's just configuration, just copy it over, using the usual text configuration formats that are common on Linux. There are lots of tools to do this, starting from simple hack jobs like using scp to full configuration management systems like ansible or puppet. The "group" part is handled by those systems as part of their function, you can easily group/subgroup/discover/inventory/parameterize. If it's policy, so you want to restrict what a user can do, you use the higher-privileged layers of the system to put in actual restrictions, not just "group policy" suggestions. You can configure the user's home directory to be mounted noexec, so software execution after an unauthorized installation is impossible. You can put them in containers, namespaces, limit their resources and system access using cgroups, filesystem permissions, and more fine-grained permission systems like SELinux. If you are so inclined, you can forbid the user from opening files starting with the letter 'f', using eBPF syscall filters (this will of course break everything, but I needed a stupid example ;). All those can also be configured with your configuration management system of choice.
Just as a comparison: Our windows team needs 3h just to re-image a laptop, just for windows. After that, all the software needs to be reinstalled, all the data copied over. Then, after 2 days and 10 reboots or something, it will have picked up all the policies, updates and things and maybe be usable. Our Linux installation takes 45 minutes. Including all the software that was previously assigned to this system, including all the settings. It will be fully updated, configured and usable after the first reboot.
It's also rare because advertising for lawyers (and doctors) is strictly regulated in some member states. A sign in front of the office saying "S. Goodman, attorney, specialized in drugs, organized crime and whiplash" is OK, billboards, TV spots, newspaper ads and any kind of claims beyond "I'm an attorney and this is my office and specialty" are verboten.
> I'm not sure if they still can do it, but the English made nuclear submarines.
Not really. The Polaris and Trident SLBM systems as well as the nukes they carry are US designs that the UK is allowed to use. And while their current PWR2 reactor is a British design, it is lacking. Therefore the next PWR3 design will be based on US S9G reactors.
The Trafalgar class were nuclear attack submarines made at Barrow-in-Furness shipyard in Cumbria. The current Astute class were also made there.
A nuclear submarine is one with nuclear propulsion, not nuclear weapons (just like a diesel-electric submarine is one with a diesel engine and batteries, not diesel weapons).
> All this "Americans must realize you are now PARIAHS and will NEVER BE TRUSTED AGAIN" business will seem novel to people today, but this was true when I was younger and America had just invaded Iraq right after Afghanistan.
Nobody really cared about Iraq or Afghanistan. Sure, it was fashionable to pretend to care, to get on a high horse and tell the USian rabble how immoral they were. But at the same time, people on their high horses also were glad that there was no Saddam Hussein anymore and that the Taliban were beaten (seemingly, back then).
It's different now because the US threatened to invade the Kingdom of Denmark, a supposedly very close ally. Even the threat of doing that is a red line that will be very very hard to uncross after Trump.
Yes, and I'm sure that the next time the US does something against European interests it will again be the case that the last time was just pretense but this time is real. The thing with terminal declarations is that there is no pathway back. If the US was never to be trusted again after the Iraq War, we are never to be trusted again now, so telling us that we are never to be trusted now is not of any significance. We're now post that declaration. That's what the word 'never' means.
The US-Europe military-economic bloc is a strong structure, but of the two Europe is weaker and the participants in Europe stand and fall according to weak ties. Without NATO, it isn't even clear if Poland will have allies. Each of the constituent countries have leaders aware of this. And I'm sure they'll attempt to keep the structure intact. If they fail, they fail but all these dramatic declarations won't have been significant either way. The declarations themselves are just emotional outbursts without even the semblance of even self-interest.
I mean, think about it. If the US has no pathway back to normalcy in relations ("never be trusted") then the cost for all future Presidents to militarily intervene is low. After all, trust is at its minimum value and guaranteed not to rise. If Greenland is core to US interests and Denmark has decided there is no pathway back to normalcy, invasion is on the table for all Presidents, Democratic Party or Republican Party.
Essentially, once you decide that you will never normalize relations, then you're just an adversary: not even a potential future ally. And those who pitch themselves as guaranteed adversaries had better find allies quick.
Just think of the relations the US has with the British. Back in the day, after the independence war, I'm quite sure that there were quite a few people in the US who said something like "never will we have cordial relations with the Kingdom of Britain"...
I guess that's just the usual hyperbole in these kinds of heated talks. I mean, it is basically the same as all those instances of TACO: Propose something outrageous, outlandish and absolute, later compromise to do something lesser.
reply