> The framing of 'share your weights freely' as a remedy is interesting but underspecified. The FSF's argument is essentially that training on copyrighted code without permission is infringement, and the remedy should be open weights.
Ignoring the fact that the statement doesn't talk about FSF code in the training data at all, [0] are you sure about that? From the start of the last of three paragraph in the statement:
Obviously, the right thing to do is protect computing freedom: share complete training inputs with every user of the LLM, together with the complete model, training configuration settings, and the accompanying software source code. Therefore, we urge Anthropic and other LLM developers that train models using huge datasets downloaded from the Internet to provide these LLMs to their users in freedom.
This seems to me to be consistent with the FSF's stance of "You told the computer how to do it. The right thing to do is to give the humans operating that computer the software, input data, and instructions that they need to do it, too.".
[0] In fact, it talks about the inclusion of a book published under the terms of the GNU FDL, [1] which requires distribution of modified copies of a covered work to -themselves- be covered by the GNU FDL.
> Rent control drives up rents, not down. Since rent control was enacted in SF, rents have increased by 15x in 45 years.
A couple of things:
You're aware of the Californian property tax control? If you aren't, go read up on the 197X Proposition 13, as well as the ways even vaguely-savvy landowners can get around the "tax is reassessed when the property changes hands" rule. IMO, it's only fair that tenants get the same sort of price-increase-protection that landlords get. If the landlords get rid of Prop 13 and anything even remotely like it for the next fifty years, I'll be first in line to clamor for the removal of what passes for rent control in the few cities that have it.
Unless you -as a developer- especially request otherwise, SF's rent control only applies to buildings that were in existence back in 197X, when the ordinance was enacted. New units are not covered by rent control. It does not apply to any commercial buildings... just residential rentals. It also only controls the rate of rent increase until the unit is vacated. Once it's vacated, the landlord is free to charge whatever rent they wish.
Your story gets confounded by the fact that -for a variety of reasons- it's nearly impossible to build any new residential buildings in SF. When demand is met with a nearly zero increase in the supply, the cost of the thing being demanded tends to go up.
Rents are generally quite high in California, not just in SF. From [0]
2000 1990 1980 1970 1960 1950 1940
United States $602 $447 $243 $108 $71 $42 $27
California $747 $620 $283 $126 $79 $42 $27
Washington $663 $445 $254 $113 $71 $43 $22
Only a few cities in California have rent control [1], so that doesn't explain the fact that rents are high state-wide.
Though, it is more interesting to look at the numbers when adjusted to 2000's dollar. [2] I wonder if your "15x" figure is inflation-adjusted...
2000 1990 1980 1970 1960 1950 1940
United States $602 $571 $481 $415 $350 $257 $284
California $747 $792 $560 $484 $389 $256 $286
Washington $663 $569 $503 $434 $350 $263 $226
First off, thanks very much for giving me exactly what I asked for.
You propose that instead of sometimes running ~five lines of C as root, I do one of the following:
1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in.
2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs.
3) Use a package that has several-thousand lines of C (and who knows how many lines of Python) running as root and does way more than I need.
All of these alternatives tell a story:
The alternative to running ~five lines of C as root is to run *many* more lines as root.
This is kinda my point. Some people rave about setuid programs and assert that they should not exist, but when you absolutely need to let an unprivileged user do things that only root is ordinarily permitted to do you're going to have to have code running as root. And when you have code running as root, you have to be careful to get it right. Whether it's running from a setuid root-owned executable, a persistent daemon running as root, or a regular program that sudo [1] has executed as root is irrelevant: it's all code running as root!
[0] People shit on sudo for both being setuid root and for being "too complicated". I love the hell out of the program; it's an essential part of how I get shit done on my PC. sudo is -very seriously- a great tool.
I think the only thing that I find kinda strange about setuid/setgid is the fact that it is tied to an executable rather than as part of the executing principal.
As an example of an OS that doesn't use a concept, Windows only recently got Unix domain sockets (which is kinda the standard for IPC in *nix land) and generally used named pipes, mailslots, etc for IPC, which can be ACLed. Communication with services and elevation after Windows XP[1] was based on the the user's privileges and not "uid == 0" or "bit set on a file"
[1]: Before Vista, a lot of services actually straight up did show UIs on the desktop or whatnot. It was found though that doing this was pretty bad as you could use automation tools to drive the UI and it could lead to some pretty nasty local privilege escalations.
Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).
The systemd service executable is just your simple C program as-is.
Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.
Yup! There's no way around that if in the end you need elevated privileges somewhere.
What the other options allow is to contain the blast radius. With the daemon you can control access via groups on the socket, and with sudo you can control access via sudoers.d
...huh. There isn't. I checked out the git repo, and read the contents of the daemon directory. I guess I looked at the meson stuff at top level and thought to myself "Meson? Isn't that one of the half-billion Python build systems?" [0] and -from that thought- assumed that there was some Python in the directories I didn't examine. (It turns out that there is not. It's all C and configuration.)
> What the other options allow is to contain the blast radius.
I can do that by removing the "other" executable bit, adding the group executable bit, and setting the file's group appropriately to control access. You are limited to a single group, but it's not like you're unable to "contain the blast radius".
> With the daemon you can control access via groups on the socket...
As long as it's a UNIX socket, yes. (Getting guaranteed information about the identity of the process on the other side of such a socket is one of my favorite things about them.)
> Yup! There's no way around that if in the end you need elevated privileges somewhere.
Exactly. I hope the "setuid is evil and shouldn't exist" people who are complaining in good faith are capable of both realizing this and also recognizing that "just daemonize it" and "just run it with sudo" are -at times- not obviously the right thing to do.
> 1) Run a persistent whole-ass daemon using something for IPC
This is the recommended way on Windows as well. Have the (privileged) installer install a privileged service, and have the non-privileged user program communicate with it.
Quite possibly because there are something like two people on earth who understand the Impersonation machinery [0] and one of the two is likely to cause an HN Black Banner Event any day now... so there's no real 'sudo' or 'setuid' equivalent on NT. ;)
[0] Seriously, it's fucking complicated. Decades ago, I wanted to write a sudo for the then-$DAYJOB. I gave up after a week when I couldn't even get the Impersonation equivalent of "Hello world" to work.
In general, I think it's because it tends to be an XY problem. If you're on a service account or something, you generally have SeBackupPrivilege (override read ACLs) and SeRestorePrivilege (override write ACLs) and other relevant privileges so like if you're changing files that's less needed since you can overwrite the ACLs to the necessary files as needed
Building services should be easy. The fact that Linux does not have an easy to use IPC mechanism is the fault of Linux. Yes, systemd can make it so services don't have to run until they are connected, and yes dbus exists, but it's overcomplicated for something which should be easy to make. This is a Linux devex failure.
>2)
I agree this is going in the wrong direction. Full sudo is also even more in the wrong direction away from only giving the minimal amount of privileges to the code that needs it.
>3)
See my response to 1). Making programs with different capabilities able to talk to each other should be made dead easy to do.
> The fact that Linux does not have an easy to use IPC mechanism...
What? Send bytes down a UNIX socket. There's nothing easier, really. It's so simple, it's what systemd uses to have monitored daemons indicate that they're now actually running.
The rest of your commentary has nothing to do with my commentary about unprivved users running code as root. Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
It really isn't. You have to a whole protocol on top of it if you want to use it and then build out the daemon logic yourself. If it was so easy why didn't you write it instead of making a suid binary. The complexity is not sufficiently abstracted away.
>Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.
My whole response was addressing the core of your argument in your post "The alternative to running ~five lines of C as root is to run many more lines as root." The reason it's many more lines is because the Linux developers did not write abstractions to make it simple to do. If you read my original post in this comment chain you will see that I do have problems with setuid executables and want distros to disable them.
> The central idea is that a IPv4x packet is still a globally routable IPv4 packet.
That's cool and all, but end-user edge routers are absolutely going to have to be updated to handle "IPv4x". Why? Because the entire point of IPvNext is to address address space exhaustion, their ISP will stop giving them IPv4 addresses.
This means that the ISP is also going to have to update significant parts of their systems to handle "IPv4x" packets, because they're going to have to handle customer site address management. The only thing that doesn't have to change is the easiest part of the system to get changed... the core routers and associated infrastructure.
Yes. The router in your home would absolutely need to support IPv4x if you wanted to make use of the extended address space, just like how in the real world your home router needs to support NAT if you want to make use of shared IP.
> The router in your home would absolutely need to support IPv4x if you wanted to make use of the extended address space...
No. The router in your home would need to support IPv4x, or you would get no Internet connection. Why? Because IPv4x extends the address space "under" each IPv4 address -thus- competing with it for space. ISPs in areas with serious address pressure sure as fuck aren't going to be giving you IPv4 addresses anymore.
As I mentioned, similarly, ISPs will need to update their systems to handle IPv4x, because they are -at minimum- going to be doing IPv4x address management for their customers. They're probably going to -themselves- be working from IPv4x allocations. Maybe each ISP gets knocked down from several v4 /16s or maybe a couple of /20s to a handful of v4 /32s to carve up for v4x customer sites.
Your scheme has the adoption problems of IPv6, but even worse because it relies on reclaiming and repurposing IPv4 address space that's currently in use.
> the easiest part of the system to get changed... the core routers and associated infrastructure.
Is that really the easy bit to change? ISPs spend years trialling new hardware and software in their core. You go through numerous cheapo home routers over the lifetime of one of their chassis. You'll use whatever non-name box they send you, and you'll accept their regular OTA updates too, else you're on your own.
When you're adding support for a new Internet address protocol that's widely agreed to be the new one, it absolutely is. Compared to what end-users get, ISPs buy very high quality gear. The rate of gear change may be lower than at end-user sites but because they're paying far, far more for the equipment, it's very likely to have support for the new addressing protocol.
Consumer gear is often cheap-as-possible garbage that has had as little effort put into it as possible. [0] I know that long after 2012, you could find consumer-grade networking equipment that did not support (or actively broke) IPv6. [1] And how often do we hear complaints of "my ISP-provided router is just unreliable trash, I hate it", or stories of people saving lots of money by refusing to rent their edge router from their ISP? The equipment ISPs give you can also be bottom-of-the-barrel crap that folks actively avoid using. [2]
So, yeah, the stuff at the very edge is often bottom-of-the-barrel trash and is often infrequently updated. That's why it's harder to update the equipment at edge than the equipment in the core. It is way more expensive to update the core stuff, but it's always getting updated, and you're paying enough to get much better quality than the stuff at the edge.
[0] OpenWRT is so, so popular for a reason, after all.
[1] This was true even for "prosumer" gear. I know that even in the mid 2010s, Ubiquiti's UniFi APs broke IPv6 for attached clients if you were using VLANs. So, yeah, not even SOHO gear is expensive enough to ensure that this stuff gets done right.
[2] You do have something of a point in the implied claim that ISPs will update their customer rental hardware with IPv6 support once they start providing IPv6 to their customer. But. Way back when I was so foolish as to rent my cable modem, I learned that I'd been getting a small fraction of the speed available to me for years because my cable modem was significantly out of date. It required a lucky realization during a support call to get that update done. So, equipment upgrades sometimes totally fall through the cracks even with major ISPs.
I entirely disagree. Due to a combination of ISPs sticking with what they know and refusing to update (because of the huge time/cost in validating it), and vendors minimising their workloads/risk exposure and only updating what they "have to". The vendors have a lot of power here and these big new protocols are just more work.
In addition, smaller ISPs have virtually no say in what software/features they get. They can ask all they want, they have little power. It takes a big customer to move the needle and get new features into these expensive boxes. It really only happens when there's another vendor offering something new, and therefore a business requirement to maintain feature parity else lose big-customer revenue. So yeh, if a new protocol magically becomes standard, only then would anyone bother implementing and supporting it.
I think it's much easier to update consumer edge equipment. The ISP dictates all aspects of this relationship, the boxes are cheap, and just plug and play. They're relatively simple and easy to validate for 99% of usecases. If your internet stops working (because you didn't get the new hw/sw), they ship you a replacement, 2 days later it's fixed.
But I will just say, and slightly off topic of this thread, the lack of multiple extension headers in this proposed protocol instantly makes it more attractive to implement compared to v6.
> I entirely disagree. Due to a combination of ISPs sticking with what they know and refusing to update... and vendors minimising their workloads/risk exposure and only updating what they "have to"...
You misunderstand me, though the misunderstanding is quite understandable given how I phrased some of the things.
I expect the updating usually occurs when buying new kit, rather than on kit that's deployed... and that that purchasing happens regularly, but infrequently. I'm a very, very big proponent of "If it's working fine, don't update its software load unless it fixes a security issue that's actually a concern.". New software often brings new trouble, and that's why cautious folks do extensive validation of new software.
My commentary presupposed that
[Y]ou're adding support for a new Internet address protocol that's widely agreed to be *the* new one
which I'd say counts as something that a vendor "has to" implement.
> I think it's much easier to update consumer edge equipment. The ISP dictates all aspects of this relationship...
I expect enough people don't use the ISP-rented equipment that it's -in aggregate- actually not much easier to update edge equipment. That's what I was trying to get at with talking about "ISP-provided routers & etc are crap and not worth the expense".
On the other hand, consumer routers route in software, which is easily updated. Core routers with multi-terabit-per-second connections use specialized ASICs to handle all that traffic, which can never be updated.
> On the other hand, consumer routers route in software, which is easily updated.
Sure. On the other other hand, companies going "Is this a security problem that's going to cost us lots of money if we don't fix it? No? Why the fuck should I spend money fixing it for free, then? It can be a headline feature in the new model." means that -in practice- they aren't so easily updated.
If everyone in the consumer space made OpenWRT-compatible routers, switches, and APs, then that problem would be solved. But -for some reason- they do not and we still get shit like [0].
> ...you end up with http://[2001::1]:80/ which is horrible
That is horrible, but you do no longer have any possibility of confusion between an IP address and a hostname/domain-name/whatever-it's-called. So, yeah, benefits and detriments.
> Your network then has a route to ::ffff:0:0/96 via a gateway...
I keep forgetting about IPv4-mapped addresses. Thanks for reminding me of them with this writeup. I should really get around to playing with them some day soon.
So, I bothered to play around with these addresses. I find myself a little confused by what you wrote.
> If you machine is on say 2001::1, then when an application attempts to listen on an ipv4 address it opens a socket listening on 2001::1 instead, and when an application writes a packet to 1.0.0.1, your OS translates it to ::ffff:100:1. ...
> Your network then has a route to ::ffff:0:0/96 via a gateway (typically just the default router), with a source of 2001::1
What's the name of this translation mechanism that you're talking about? It seems to be the important part of the system.
I ask because when I visit [0] in Firefox on a Linux system with both globally-routable IPv6 and locally-routable IPv4 addresses configured, I see a TCP conversation with the remote IPv4 address 192.168.2.2. When I remove the IPv4 address (and the IPv4 default route) from the local host, I get immediate failures... neither v4 nor v6 traffic is made.
When I add the route it looks like you suggested I add
ip route add ::ffff:0:0/96 dev eth0 via <$DEFAULT_IPV6_GATEWAY_IP>
I see the route in my routing table, but I get exactly the same results... no IPv4 or IPv6 traffic.
Based on my testing, it looks like this is only a way to represent IPv4 addresses as IPv6 addresses, as ::ffff:192.168.2.2 gets translated into ::ffff:c0a8:202, but the OS uses that to create IPv4 traffic. If your system doesn't have an IPv4 address configured on it, then this doesn't seem to help you at all. What am I missing?
> I ask because when I visit [0] in Firefox on a Linux system with both globally-routable IPv6 and locally-routable IPv4 addresses configured, I see a TCP conversation with the remote IPv4 address 192.168.2.2. When I remove the IPv4 address (and the IPv4 default route) from the local host, I get immediate failures... neither v4 nor v6 traffic is made.
Yes, that's the failure of ipv6 deployment.
Imagine you have two vlans, one ipv4 only, one ipv6 only. There's a router sitting across both vlans.
VLAN1 - ipv6 only
Router 2001::1
Device A 2001::1234
VLAN2 - ipv4 only
Router 192.168.1.1
Device B 192.168.1.2
Device A pings 192.168.1.2, the OS converts that transparently to ::ffff:192.168.1.2, it sends it to its default router 2001::1
That router does a 6>4 translation, converting the destination to 192.168.1.2 and the source to 192.168.1.1 (or however it's configured)
It maintains the protocol/port/address in its state as any ipv4 natting router would do, and the response is "unnatted" as an "established connection" (with connection also applying for icmp/udp as v4 nat does today)
An application on Device A has no need to be ipv6 aware. The A record in DNS which resolves to 192.168.1.2 is reachable from device A despite it not having a V4 address. The hard coded IP database in it works fine.
Now if Device B wants to reach Device A, it uses traditional port forwarding on the router, where 192.168.1.1:80 is forwarded to [2001::1234]:80, with source of ::ffff:192.168.1.2
With this in place, there is no need to update any applications, and certainly no need for dual stack.
The missing bits are the lack of common 64/46 natting -- I don't believe it's built into the normal linux network chain like v4 nat is, and the lack of transparent upgrading of v4 handling on an OS level.
Ah. So, you're saying that what you describe doesn't actually exist. That the best you can currently do is stuff like [0] and [1] where the IPv4 or IPv6 client use v4 or v6 addresses (respectively) and an intermediary sets up a fake destination IP on both ingress and egress and does the v4 <-> v6 address translation.
If so, that was not at all clear from your original comment.
It does exist though. The OS part is 464xlat and the router part is NAT64. You can try the second part out by setting your DNS server to one of the ones listed on https://nat64.net/, which will work with hostnames. To get IP literals to work you need 464xlat, which is currently a bit annoying to set up on Linux.
(Note that using the servers provided by nat64.net is equivalent to using an open proxy, so you probably don't want it for general-purpose use. You would probably want either your ISP to run the NAT64 (equivalent to CGNAT), or to run it on your own router (equivalent to NAT).)
The standard prefix for NAT64 is 64:ff9b::/96, although you can pick any unused prefix for it. ::ffff:0:0/96 is the prefix for a completely different compatibility mechanism that's specifically just for allowing an application to talk to the kernel's v4 stack over AF_INET6 sockets (as you figured out). It was a confusing choice of prefix to use to describe NAT64.
You will certainly need to update applications, because they won't be able to connect to v6 addresses otherwise. 464xlat only helps you connect to v4 addresses. It just means that updating _all_ of your applications is no longer a prerequisite of turning v4 off on your network.
Could have used 2001~1001~~1 instead of 2001:1001::1, which looks weird today, but wouldn't have done if that had been chosen all those years ago.
(unless : as an ipv6 separator predates its use as a separator for tcp/udp ports, in which case tcp/udp should have used ~. Other symbols are available)
I don't see IPv4 going away within the next fifty years. I'd not be surprised for it to last for the next hundred+ years. I expect to see more and more residential ISPs provide their customers with globally-routable IPv6 service and put their customers behind IPv4 CGNs (or whatever the reasonable "Give the customer's edge router a not-globally-routable IPv4 address, but serve its traffic with IPv6 infrastructure" mechanism to use is). That IPv4 space will get freed up to use in IPv4-only publicly-facing services in datacenters.
There's IPv4-only software out there, and I expect that it will outlive everyone who's reading this site today. That's fine. What matters is getting proper IPv6 service to every Internet-connected site on (and off) the planet.
With you on “IPv6 only will become a thing for many clients”, but servers (or at least load balancers) will absolutely not stay v4-reachable only.
They’re already not. For example, I believe you won’t get an iOS app approved for distribution by Apple these days if it doesn’t work on v6-only clients.
> With you on “IPv6 only will become a thing for many clients"...
That's not what I said. I said that having a globally-routable IPv4 address assigned to a LAN's edge router will stop being a thing. Things like CGN (or some other sort of translation system) will be the norm for all residential users.
> ...but servers (or at least load balancers) will absolutely not stay v4-reachable only.
Some absolutely will. There's a lot of software and hardware out there that's chugging along doing exactly what the entity that deployed it needs it to do... but -for one of handful of reasons- will never, ever be updated ever again. This is fine. The absolute best thing any programmer can do is to create a system that one never has to touch ever again.
> That's not what I said. I said that having a globally-routable IPv4 address assigned to a LAN's edge router will stop being a thing. Things like CGN (or some other sort of translation system) will be the norm for all residential users.
That's still what I would call a v6-only (with translation mechanisms) client deployment. Sorry for being imprecise on the "with translation mechanisms" part.
> Some absolutely will.
Very few, in my prediction. We're already seeing massive v6 + CG-NAT-only deployments these days, and the NAT part is starting to have worse performance characteristics: Higher latency because the NATs aren't as geographically distributed as the v6 gateway routers, shorter-lived TCP connections because IP/port tuples are adding a tighter resource constraint than connection tracking memory alone etc.
This, and top-down mandates like Apple's "all apps must work on v6 only phones", is pushing most big services to become v6 reachable.
At some point, some ISP is going to decide that v6 only (i.e. without translation mechanisms) Internet is "enough" for their users. Hackers will complain, call it "not real Internet" (and have a point, just like I don't consider NATted v4 "real Internet"!), but most profit-oriented companies will react by quickly providing rudimentary v6 connectivity via assigning a v6 address to their load balancer and setting an AAAA record.
I agree that v4 only servers will stick around for decades, just like there are still many non-Internet networks out there, but v4 only reachability will become a non-starter for anything that humans/eyeballs will want to access. And at some point, the fraction of v4-only eyeballs will become so small that it'll start becoming feasible to serve content on v6 only. At that point, v4 will be finally considered "not the real Internet" too.
Sure, I agree. I'm not sure how you got the notion that I thought a large percentage of systems out there will never get IPv6 support. There's a lot of solid systems out there that just fucking run. They're a small percentage of all of the deployed machines in the world.
> That's still what I would call a v6-only (with translation mechanisms) client deployment.
When people say "IPv6 only", they mean "Cannot connect to IPv4 systems". IMO, claiming it means anything else is watering down the definition into meaninglessness. Consider it in the context of what someone means when they envision a future where the Internet is "IPv6 only", so we don't need to deal with the "trouble" and "headache" of running both v4 and v6.
Yeah, it's my understanding that that's been the situation for a great many folks in the Asia/Pacific part of the world for a while now. Lots and lots of hosts, but not much IPv4 space allocated.
What's the advice on ULAs? On my internet-connected VLANs, I have a -er- site-local IPv4 subnet, a unique local IPv6 subnet, and a global IPv6 subnet. This works just fine.
Does the "advice" boil down to "You should NEVER use ULAs and ALWAYS use GUAs!" and is given by the same very, very loud subset of people who seemed to feel very strongly that IPv6 implementations should explicitly make it impossible to do NAT?
Why would anyone need IPv6 to be incapable of doing NAT?
To answer your question: Who knows? Perhaps you have a shitlord ISP that only provides you with a /128 (such as that one "cloud provider" whose name escapes me). [0] It's a nice tool to have in your toolbox, should you find that you need to use it.
[0] Yes, I'm aware that a "cloud provider" is not strictly an ISP. They are providing your VMs with access to the Internet, so I think the definition fits with only a little stretching-induced damage.
As a network admin I can say that NAT makes everything much harder and that the source and destination IP should stay the same from source to destination whenever possible.
It's not. It's simple, understandable, straightforward. Only natting to a single address is flawed, but also understandable, because they want to charge you for a prefix.
> It's not [fucked up]. It's simple, understandable, straightforward.
Things that are fucked up can also be simple, understandable, and straightforward.
Unless you're claiming that DHCPv6 is not simple, understandable, and straightforward... in which case:
DHCPv4 is "Give me an IP address, please.". DHCPv6 is "Give me an IP address, please. And also give me what I need for all of my directly-connected friends to have one, too, if you don't mind.".
If your edge router supports IPv6, it almost certainly can make a DHCPv6-PD request and handle advertising the assigned prefix on its LAN side.
Because of Google's continued (deliberate?) misunderstanding of what DHCPv6 is for, Android clients don't do anything sane with it. That doesn't mean that DHCPv6 isn't simple.
Again, DHCPv6 is "Please give me an IP address, and maybe also what my directly-attached friends need to get IP addresses.". Simple, straightforward, and easy to understand. Even if it were relevant, Google's chronic rectocranial insertion doesn't change that.
In any scenario where you want to do traffic steering at a network level. Managing multiple network upstreams (e.g. for network failover or load balancing) is a common example that is served well by numerous off-the-shelf routers with IPv4. That's an important feature that IPv6 cannot offer without using NPTv6 or NAT66.
It's conceivable that OSes could support some sort of traffic steering mechanism where the network distributes policy in some sort of dynamic way? But that also sounds fragile and you (i.e. the network operator) still have to cope with the long tail of devices that will never support such a mechanism.
> Managing multiple network upstreams (e.g. for network failover or load balancing) is a common example ... that IPv6 cannot offer without using NPTv6 or NAT66.
I don't think that's true. I haven't had reason to do edge router failover, but I am familiar with the concepts and also with anycast/multihoming... so do make sure to cross-check what I'm saying here with known-good information.
My claim is that the scenario you describe is superior in the non-NATted IPv6 world to that of the NATted IPv4 world. Let's consider the scenario you describe in the IPv4-only world. Assume you're providing a typical "one global IP shared with a number of LAN hosts via IPv4 NAT". When one uplink dies, the following happens:
* You fail over to your backup link
* This changes your external IP address
* Because you're doing NAT, and DHCP generally has no way to talk back to hosts after the initial negotiation you have no way to alert hosts of the change in external IP address
* Depending on your NAT box configuration, existing client connections either die a slow and painful death, or -ideally- they get abruptly RESET and the hosts reestablish them
Now consider the situation with IPv6. When one uplink dies:
* You fail over to your backup link
* This changes your external prefix
* Your router announces the prefix change by announcing the new prefix and also that the now-dead one's valid lifetime is 0 seconds [0]
* Hosts react to the change by reconfiguring via SLAAC and/or DHCPv6, depending on the settings in the RA
* Existing client connections are still dead, [1] but the host gets to know that their global IP address has changed and has a chance to take action, rather than being entirely unaware
Assuming that I haven't screwed up any of the details, I think that's what happens. Of course, if you have provider-independent addresses [2] assigned to your site, then maybe none of that matters and you "just" fail over without much trouble?
[0] I think this is known as "deprecating" the prefix
[1] I think whether they die slow or fast depends on how the router is configured
> * Hosts react to the change by reconfiguring via SLAAC and/or DHCPv6, depending on the settings in the RA
This is the linchpin of the workflow you've outlined. Anecdotal experience in this area suggests it's not broadly effective enough in practice, not least because of this:
> * Existing client connections are still dead, [1] but the host gets to know that their global IP address has changed and has a chance to take action, rather than being entirely unaware
The old IP addresses (afaiu/ime) will not be removed before any dependent connections are removed. In other words, the application (not the host/OS) is driving just as much as the OS is. Imo, this is one of the core problems with the scenario, that the OS APIs for this stuff just aren't descriptive enough to describe the network reconfiguration event. Because of that, things will ~always be leaky.
> [1] I think whether they die slow or fast depends on how the router is configured
Yeah, and that configuration will presumably be sensitive to what caused the failover. This could manifest differently based on whether upstream A simply has some bad packet loss or whether it went down altogether (e.g. a physical fault).
In any case, this vision of the world misses on at least two things, in my view:
1. Administrative load balancing (e.g. lightly utilizing upstream B even when upstream A is still up
2. The long tail of devices that don't respond well to the flow you outlined. It's not enough to think of well-behaved servers that one has total control over; need to think also of random devices with network stacks of...varying quality (e.g. IOT devices)
> The old IP addresses (afaiu/ime) will not be removed before any dependent connections are removed.
I have two reactions to this.
1) Duh? I'm discussing a failover situation where your router has unexpectedly lost its connection to the outside world. You'd hope that your existing connections would fail quickly. The existence of the deprecated IP shoudn't be relevant because the OS isn't supposed to use it for any new connections.
2) If you're suggesting that network-management infrastructure running on the host will be unable to delete a deprecated address from an interface because existing connections haven't closed, that doesn't match my experience at all. I don't think you're suggesting this, but I'm bringing it up to be thorough.
> ...the OS APIs for this stuff just aren't descriptive enough to describe the network reconfiguration event.
I know that Linux has a system (netlink?) that's descriptive enough for daemons [0] to actively nearly-instantaneously start and stop listening on newly added/removed addresses. I'd be a little surprised if you couldn't use that mechanism to subscribe to "an address has become deprecated" events. I'd also be somewhat surprised if noone had built a nice little library over top of whatever mechanism that is. IDK about other OS's, but I'd be surprised if there weren't equivalents in the BSDs, Mac OS, and Windows.
> In any case, this vision of the world misses on at least two things, in my view:
> 1. Administrative load balancing...
I deliberately didn't talk about load balancing. I expect that if you don't do that at a layer below IP, then you're either stuck with something obscenely complicated or you're doing something like using special IP stacks on both ends... regardless of what version of IP your clients are using.
> 2. The long tail of devices that don't respond well to the flow you outlined.
Do they respond worse than in the IPv4 NAT world? This and other commentary throughout indicates that you missed the point I was making. That point was that -unlike in the NATted world- the OS and the applications running in it have a way to plausibly be informed of the network addressing change. In the NAT case, they can only infer that shit went bad.
> 1) Duh? I'm discussing a failover situation where your router has unexpectedly lost its connection to the outside world. You'd hope that your existing connections would fail quickly. The existence of the deprecated IP shoudn't be relevant because the OS isn't supposed to use it for any new connections.
Well failover is an administrative decision that can result from unexpectedly losing connection. But it can also be more ambiguous packet loss too, something that wouldn't necessarily manifest in broken connections--just degraded ones.
If upstream A is still passing traffic that simply gets lost further down the line, then there's no particular guarantee that the connection will fail quickly. If upstream A deliberately starts rejecting TCP traffic with RST, then sure, that'll be fine. But UDP and other traffic, no such luck. Whereas QUIC would fare just fine with NAT thanks to its roaming capabilities.
> I know that Linux has a system (netlink?) that's descriptive enough for daemons [0] to actively nearly-instantaneously start and stop listening on newly added/removed addresses. I'd be a little surprised if you couldn't use that mechanism to subscribe to "an address has become deprecated" events. I'd also be somewhat surprised if noone had built a nice little library over top of whatever mechanism that is. IDK about other OS's, but I'd be surprised if there weren't equivalents in the BSDs, Mac OS, and Windows.
Idk, I'll have to take your word for it. Instinctively though, this feels like a situation where the lowest common denominator wins. In other words, average applications aren't going to do any legwork here. The best thing to hope for is for language standard libraries to make this as built-in as possible. But if that exists, I'm extremely unaware of it.
> I deliberately didn't talk about load balancing. I expect that if you don't do that at a layer below IP, then you're either stuck with something obscenely complicated or you're doing something like using special IP stacks on both ends... regardless of what version of IP your clients are using.
I presume you meant a layer above IP? But no, I don't see why this is challenging in a NAT world. At least, I've worked with routers that support this, and it always seemed to Just Work™. I'd naively assume that the router is just modding the hash of the layer 3 addresses or something though.
> Do they respond worse than in the IPv4 NAT world?
I've basically only ever had good experiences in the IPv4 NAT world.
> That point was that -unlike in the NATted world- the OS and the applications running in it have a way to plausibly be informed of the network addressing change. In the NAT case, they can only infer that shit went bad.
I'm certainly sympathetic to this point. And, all things being equal, of course that seems better! If NAT66 were to not offer sufficient practical benefits, then I'd be convinced.
But please bear in mind that this was the original comment I responded to (not yours). Responding to this is where I'm coming from:
In fairness, aside from whining about the minority attitude towards NAT [0] the person you're replying to absolutely met your definition of "gratuitous":
(i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters)
I (and I expect the fellow you're replying to) believe that if you're going to have to rework ARP to support 128-bit addresses, you might as well come up with a new protocol that fixes things you think are bad about ARP.
And if the fellow you're replying to doesn't know that broadcast is another name for "all-hosts multicast", then he needs to read a bit more.
[0] Several purity-minded fools wanted to pretend that IPv6 NAT wasn't going to exist. That doesn't mean that IPv6 doesn't support NAT... NAT is and has always been a function of the packet mangling done by a router that sits between you and your conversation partner.
Ignoring the fact that the statement doesn't talk about FSF code in the training data at all, [0] are you sure about that? From the start of the last of three paragraph in the statement:
This seems to me to be consistent with the FSF's stance of "You told the computer how to do it. The right thing to do is to give the humans operating that computer the software, input data, and instructions that they need to do it, too.".[0] In fact, it talks about the inclusion of a book published under the terms of the GNU FDL, [1] which requires distribution of modified copies of a covered work to -themselves- be covered by the GNU FDL.
[1] <https://www.gnu.org/licenses/fdl-1.3.html>
reply