I just think it's not needed. When you have limited IP space, you need to use all of them, so you reserve some and "lease" them out. But when you have essentially unlimited address space you just use any random one and it's "guaranteed" to be free. The first time an OS boots it can generate a random token, and then it's got a stable privacy address. Why hand out addresses from a DHCP server?
Stable privacy provides non-trackability for a mobile device as it moves from one network to another. So in that sense when you're at a coffee shop it's not obviously still the same you that was at your home or at your work. Also stable privacy doesn't reveal what kind of NIC you have (so for example could reveal vulnerabilities). This is decent privacy for something like a desktop machine.
For something like a phone, which really does move around a lot, rotating privacy addresses make good sense I think. But then you can't associate them to names and devices... this is the price you pay for privacy. But when do you want your Android to be a ssh server?
I just don't see what DHCP adds beyond these except complexity and failure modes.
As for associating names to stable privacy addresses... for a small LAN you can do it with mDNS easily. For a medium sized LAN (small/medium business) host files on the router or DDNS.
this is what "tokenized" addresses means. You had the OS a token which is a 64 bit number and it just uses that as the host part. So basically I agree with you, but a DHCP server and constant lease renewals doesn't add anything here.
DSCP tags are just numbers that are attached to your packets. You can use them for whatever you want. Only when you have devices that you can't configure do you need to worry about which tag to use to make that device do what you want.
This is mostly small cheap switches that have a single QoS system built in.
Also cake has a set QoS scheme, mapping from DSCP to various tins, you can't change it. So you choose tags that do the right thing.
Because I can configure this conveniently centrally from my router?
How? As long as the last 64bits stay constant the device is trackable, nobody sane uses the full 128bits for tracking... given prefix delegations... and the standard nicely splits the address into 2 64bit words...
Ah, yes the "pack the MAC address into the interface identifier" approach, I fully agree that that was not too user-friendly, but any stable interface identifier can be used for tracking, hence the rotation of IPv6 addresses in the design of the provacy extensions with each hosts still responding for older addresses for some time, but actively initiating connections only with the most recent one.
As I said, I can live with that for the phones, these should never supply services to the wider internet
One stop shopping, one place to define/maintain/change the MAC to IPv6 address mapping tables, really just convenience, same as with IPv4.
I do not want to start a rant here, but let's just say I am not a big fan of overloading mDNS with important stuff
On the router? Not my idea of keeping a tight ship ;). IMHO the fewer functions a router implements the better (within reason, some things are done well on a router). But honestly, it is mostly about SSH, either shell sessions or data transfers
stable privacy uses a token and the prefix, hashes that, and creates the suffix. So it varies from network to network, but stays constant within a given network. Only "tokenized" addresses stay constant across prefixes. Basically I'm proposing three tiers:
Tokenized addresses: someone manually specifies a host part, the OS just glues it on
Stable privacy addresses: someone manually specifies a secret, and then hash(prefix+secret) is host part
Privacy addresses: randomly generate rolling addresses every half hour or so and age them out
I think this handles essentially 100% of ipv6
Except you can't use the MAC address in DHCPv6 you have to use the DUID which means you have to configure a DUID token anyway. By the time you're generating a random DUID or looking up the one that the OS generated or whatever you're doing, you might as well just use it to generate a 64 bit host part, and then just discover it once and record it on the host file of your router. The DHCP server doesn't add any convenience.
I'm assuming the router is doing the DNS, so that's where it needs the info on what's the name associated with each IP address... But if you want to do it on a PiHole or something that's cool too.
How that? My ISPs strongly believes that assigning me a new prefix every 24 hours is the right way to deal with IPv6. With that approach, all my machines fully rename every 24h, no? Sure, knowing the prefix and the token, I can recreate that interface identifier, but what I wanted is that to be stable, like in does not change just because the prefix needs to be changed...
This will change every 24 hours for me so only a tad better than filly rotating privacy extension addresses, no?
Looks like rfc6939 contains a bridge for folks that think that MAC addresses are pretty good DUID-candidates, at least for small networks.
So one of the things that went completelt pear shaped with IPv6 was the attempts to change more things than needed changing based seemingly on philosophical considerations. The IPv6 folks had DHCP clearly on their "hit list" in spite of the deployed mass of DHCP in the field, if you ask me not allowing to use MAC addresses as regular identifiers was such a move (which clearly back fired). The moral being, if you want to deprecate something, make sure your intended replacement is up for the task and does not introduce too much added complexity for its gains, but I digress
Argh, I do not want to manually configure each device and the router, the one thing I like(d) about DHCPv4 is that is conveniently allowed me to bind MAC, address, local DNS name, and IP address from one management interface... But I get it, no amount of complaining is going to make that happen. And before I get misunderstood, in spite of the DHCPv6 kerfuffle I am all for IPv6 and accept that it is here to stay. (But so is IPv4 for a loooong time).
your ISP is broken (I assume all your ssh sessions die at midnight, all long running downloads die at midnight, you can't watch streaming TV across the midnight boundary, you can't make voip calls across midnight boundary, you can't help someone on teamviewer across the midnight boundary... If you're editing a document on a remote machine it'll get lost at midnight. if that was my ISP I'd be organizing a blitz on Twitter to cancel them ;-))
But yes, this will change every 24 hrs because the network (prefix number) you're on changes every 24 hrs. If you want a stable public address you need to use option (1) from above: tokenized addresses. If you're ok with just stable site-local addresses you can thankfully have ULA that doesn't change like a child's diapers.
Well if you have a sane ISP, you just need to once configure the router / DNS to know the name of each machine... and given you have insane ISP, you can use ULA for that mostly. You only really need those few publicly accessible machines to have public names... for that I do DDNS on those few machines.
you can either use iptables directly, or edit /etc/config/firewall they are both valid ways of getting your custom rules into the firewall. If you use /etc/config/firewall it will survive a firewall reset better etc.
Sadly most consumer ISPs in europe (and germany in particular) behave that way (due to VoIP, many are slowly moving away from hard daily disconnects, but they'll still enforce an IPv4 and prefix change after each reconnect), even those who aren't that evil provide semi-static prefixes at best (won't change regularly, but can change without any advanced warning after a reconnect or hickup in their network).
That is a bit harsh, after all my ISP communicated that behaviour explicitly before signing the contract, so I knew what I was getting into.
The automaticpppoe and prefix renew is always 24 hours after the last, so by forcing a PPPoE reconnect I can basically select when this happens. And I started using screen and mosh heavily so my interactive sessions mostky deal gracefully with the forced IP address changes.
None of these things you list actually bother me, in spite of me expecting to be annoyed, I guess my applications mostly deal gracefully with that (like the address renewal is so fast, that streaming video might not even stutter). And the last really long transfer (rsync of ~8 TB over the atlantic, with <= 6 TB already upto date) happened whit my previous ISP, and they forced a new address every 180 days.
I guess using screen and mosh allows me to shrug the IP changes off, and both have additional advantages so I use them not only for this one reason alone.
Yes, that probably is the path of least resistance...
The incumbent actually only forces a PPPoE reconnect and associated prefix change every 180 days, but will otherwise use any un-enforced PPPoE reconnect to hand out new/different IPv4 address and IPv6 prefix. And that means that screen and mosh are already good ideas (when I was their customer my flaky DSL line later re-synced multiple times a week, making the nominal 180 days less relevant).
Here's the thing. There are 7 billion people on the planet. Let's avg 3 people per household so there are 2.3 B households. If we give each household a /48 permanently and NEVER reclaim it, we could do this for every household EVERY DAY for 122380 days which is 335 years without ever reclaiming any of them. If we give every household a single /48 and only reclaim it when you move houses or die, you could do this forever and ever and never run out or have any form of scarcity at all.
So as far as I am concerned this behavior is purely an attempt to market segment: to make it so that you a "mere consumer" can't have a "real" internet connection because then they can charge more for a "real" one. So as far as I'm concerned it's not harsh enough. It simply should not be the case that we use ipv6 addresses as an artificial scarcity. that's the original definition of rent seeking in economics: creating and charging for scarcity that doesn't exist.
We can at the same time also give up IPv6 privacy extensions, because with stable prefixes, most of the tracking issue is solved, add a modicum of fingerprinting to get tp the device, et voila, cookies become optional
Partly, that ISP actually does not even offer fixed IP addresses on DSL lines at all, so I believe the issue is that they are short on IPv4 and hence need to cycle them quickly (at least these are real public IPv4 address and none of that CGN-stuff). IPv6 is probably just in for the ride since it is tacked on to and negotiated over the same PPPoE tunnel. I guess it is simply easier to not keep separate state for IPv4 and IPv6, but yeah, that is still a lame rationale. The incumbents 180 days however are market segmentation, but at 180 days the consequences are pretty mild and will probably push no one into a business contract.
Well, sure, but rent is what every company's bean-counter compartment (and investors) would like the company to seek... I get your point, though and that probably is an important part of the motivation, plus the fact that for IPv4 they need to do it (for true scarcity reasons).
EDIT: Turns out they do offer business contracts with fixed IP addresses, that are actually not unreasonably priced, with a fixed public IPv4 address and a modem still a few cents cheaper than the incumbent's plan for private customers without a fixed IP address. No word on IPv6 though, so well possible that the fixed IPv4 comes without IPv6 access at all (none of the local ISPs seems willing to commit to IPv6 addresses, even though most actually provision them).
The tracking issue is solved anyway. No one uses ip addresses for tracking since ipv4 uses so much NAT/CGNAT, so whatever tracking they're doing now is all browser cookie and fingerprinting based anyway. Using the IPv6 prefix just tells you that "some large or small group of people did these things" since a /48 would work fine for an entire liberal arts college, or a household. Is it 5000 students, or 2 adults and 3 kids? You don't know because privacy addresses.
This is a real problem, not a made up one, and if they're using 6rd then of course the ipv6 will change accordingly. Since T-Mobile has essentially 100% ipv6 deployment, it shows it can be done. Let's do it! I want to leave Ipv4 behind 4 years ago.