I'm pretty sure that openwrt with some optional packages, meets or exceeds most of the mandatory and most of the optional "checkboxes" for CPE, but not entirely.
4.6 Requirements for CPE equipment
Mandatory support:
Basic Requirements for IPv6 Customer Edge Routers [RFC7084] *
Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service [RFC6092]
If support for specific IPv4 transition mechanisms is required, the device must support the relevant requirements, as can be taken from Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service [RFC8585] and Discovering PREF64 in Router Advertisements [RFC8781]
If support for SNMP is required:
SNMP protocol [RFC3411]
SNMP capabilities [RFC3412, RFC3413, RFC3414]
SNMP MIBs for IP [RFC4293] Forwarding [RFC4292] and DiffServ [RFC3289]
As far as I can tell SNMP is a giant security joke. The most common versions have essentially no security and the most secure versions have laughable security using things like MD5 and DES which can be broken in hours on modern hardware. am I wrong about that?
I think OpenWRT is 99% ready with some minor problems. I am using it for couple of years without any problems. Like restarting upstream router makes downstream router loose IPv6 connectivity, Assigning my own 64 bit suffix for my device, which is getting fixed now.
The number of ISPs handing out less than /56 is just staggering. lots of them hand out just a /64. ATT on its fiber gives a /60 to their CPE equipment and that will let you request 4 /64s from it. F*** that. /56 by default and /48 to anyone who requests, with DHCP-PD lease duration minimum 6 months or static assignment to the customer mandated by law. We need legislation on this.
That doesn't really surprise me. The concept of subdelegation and proper bidirectional routing is hard to grasp with a "single public IP + NAT" mindset... Those single /64 assignments are likely just naive 1:1 translations of the existing IPv4 DHCP setup, basically the bare minimum to offer IPv6 to customers. I could also imagine that some ISPs might see it as an opportunity to charge additional fees for larger subnets in the future.
One additional problem is that RFC6177 can be read in multiple ways, the least generous being a /64 is enough... (yes, the text recommends >> /64, but a /64 is still compliant and hence there will be players that argue if a /64 is not "verboten" we are going to do it). IMHO this is in a good part driven, by the fact that anything > /64 is currently technically not strictly needed for the majority of end-user leaf networks, so there is no immediate "price" in customer dissatisfaction for converging on a /64...
That is going to be hard ATM since our own standards bodies do not put out guidance that can be backed-up by law: "Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default." What are law-makers to do here if the "internet" does not seem to agree?
On the plus side, realistically speaking, a /64 is large enough to do "internal subnetting" if need be and it is nice that RFC6177 remove the special case where a /128 was deemed sufficient.
That RFC was written in 2011 when essentially zero ISPs had IPv6 and smartphones we're tsomething only 25% of US adults had compared with something like 95% today. Sure, it needs an update but it's language is clear enough
Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either.
In particular I don't think you can read "significantly more than a single /64" as "a /64 or more".
Yes, you can (if you are sufficiently motivated). IEFTese for /64 is not OKAY would be something like "assignments MUST be > /64", the point is they do recommend >> /64, but they clearly do not disallow a /64... heck, they do not even reference and use the IETF normed capitalized SHOULD/MUST convention. Don't get me wrong, I also read a clear call for >>/64 in there, but single /64 is clearly not disallowed and that gives enough ambiguity to lobby law-makers that the technical community is not unequivocally aligned behind a strict >> /64.
What could should an update actually change? We are ten years later and home networks with multiple levels of routers are still essentially unicorns....
ISPs MUST provide /56 to all end users with a duration of assignment at least 6 months. ISPs MUST provide /52 or /48 to any end user requesting such assignments with duration at least 6 months.
It can't be the case that we allow artificial scarcity of "numbers" that's like allowing companies to charge for air to breathe.
I personally think it was an unfortunate choice to choose /64 as the network/host boundary. 48 bits for host was already plenty. No fool would connect more than 1e6 devices to a single network, most likely 1e4 would already bring most networks to their knees with chatter.
Yeah, I do not see the IETF converging on that... maybe if pitched under the angle that /52 are important in the field to avoid ossification of 8bit prefix boundaries (but then arbitrary assignments from /48 to /56 would be more useful).
BTW, "assignment duration at least 6 months" basically makes privacy extensions mostly useless (as long as the MAC address is not coded using EUI-64 instead).... And as a datapoint the incumbent in Germany assigns IPv4/IPv6 prefixes in its dual stack deployment for up to 180 days and still users ask in forums how to force a prefix change....
Welcome to late-stage capitalism ;)... But in all honesty, 64 bits are a lot already.... 64 + (64-(X>=48) bits even more so.
I think that this split is not set in stone any way... it is just the most equitable thing you can do when you happen to stumble over a motherload of address bits that should make both sides happy. In addition a 64/64 split nicely aligns with hardware word sizes, 64bit ALUs are a thing 128-48 = 80 not so much.
My impression is that "everyone" agrees on nibble boundaries so you don't have to split up individual hex digits
Not meant to mean outlawing release and rerequest just outlawing a forced reassignment on less than 6mo intervals. I personally think providing services from home will be a big thing eventually. Commercial companies will want to sell you a "my cloud" box that lets you access your files from anywhere. And Minecraft servers at home (my son already does this for his friends enough of whom actually have IPv6 today) and whatever else that becomes the new hotness once end to end is restored on the internet. ISPs forcing renumbering down your throat is not ok.
Privacy extensions should be thought of primarily as a way to not reveal the individual hardware device and to prevent incoming connection attacks (as once a devices address is known to an attacker it has a limited hour or so to attack it). It was never going to work as a "do not track for ads" purpose. Browser fingerprinting makes IP addresses irrelevant for that anyway.
Until nibble boundaries are too coarse... I have not much opinion there, I just thought that RFC6177 anti-ossification argument logically leads to as little predictable boundaries as possible.
Interestingly we already have a solution around that issue, DNS, or DDNS as the variant for home users is mostly called. And that will still be helpful even at 180 days prefix renewals, because who is going to remember IPv6 addresses by heart, especially multiple of them. Sure for longer running connections prefix exchange not every 24 hours can help helpful.
Well, every 6 months is frequent enough that one still needs to deal with the fall-out of renumbering. Mind you I do not argue about my personal preference here (I like your proposal) but how likely I see this picked up by law-makers.
To the second part I can say, I prefer a stateful firewall over "security by obscurity" any old day. Why? Because there are enough IPv6 enabled devices already in my network that I only trust in a limited fashion.
Yes and no, a modified EUI-64 interface ID (with ethernet MAC) is far superior to browser fingerprinting , or better yet can be used as ground truth for getting ML-classifies training.
No doubt. So privacy addresses are a good thing. They just aren't intended to make your device "untrackable" more like not trivially trackable.
Exactly. And DNS cache lifetime is often hours. It would suck to not be reachable every afternoon from 12-2pm because DNS propagation delays. If ISPs can make your life suck and then charge more to eliminate that suckage they will. This is classic "chain across the canal" type rent seeking.
Sure of course, but suppose you open a UDP connection to a compromised game server (or to a quic based web server) and now that game server is hammering you with download saturating UDP traffic. As far as the stateful firewall knows, you want that information. Having your IP go offline after an hour is helpful here. The sparsity of addresses does definitely help against the kind of stuff that goes on all day long against my ipv4 address. I probably get hundreds of connections per hour probing my ssh port or SIP server ports or whatever. Noone is going to do that against my entire IPv6 home subnet but they may well harvest my incoming connections and make a list of known devices to probe. Making those worthless after an hour is good.
Yes and no. IMHO they are an additional layer of defense, but really their main use is to make up the original SLAAC EUI-64 naivety (a long term stable global identifier sure sounds like a great idea for quite a number of use cases, but not for the place the internet has become....). I guess if original SLAAC had not been so optimistically naive, privacy extensions might never have been required. And by the way this is where e.g. DHCPv6 as address assignment helps, because the address generation can be easily switched from one centra point instead of having to squash unfortunate defaults at each individual host, but I digress.
Well, DDNS providers like duckdns.org use considerable shorter lifetimes, and for my use via mosh i rarely notice prefix changes (mind you IPv4 only at the moment, as my work place is an IPv4 only shop ATM).
Yes this is why DDNS-services is something you get from somebody else than your ISP ;).
But will it, or will the packets coming in keep that privacy address active? Have not looked for UDP. BTW this also is one more of the reasons why operators seem to dislike UDP.
Well as long as the prefix did not change that download saturating UDP flood is still going to clog the downlink direction of the access link, no?
Not sure, yes the likelihood of guessing an active address is low, but that was also considered true for IPv4 at one point in the internet's life cycle.
Not sure how much this actually adds to security, but I agree it adds "something", also not sure whether "something" is worth the inconvenience PE brings, but probably yes.
