Yes I know, the problem is well described in the article you cite, for pure consumers this is a reasonable strategy (even though end-networks can still be tracked via the IPv6 prefix), but for offering services reachable from the outside one needs to add some sort of stable address as well. IMHO doing this via DHCP from the router is quite convenient (and OpenWrt already tries to do this) as one needs to configure the firewall on the router anyway.... (but in fairness one also needs to adjust the firewall on the server-to-be, so either way it is not likely to be one-stop-shopping; and at least for me the number of servers I would run over IPv6 is in the low single digits, so doing this by hand on each machine is fully doable).
1 Like
and works fine on any device you'd want to actually offer services from.
Though one of the great things about IPv6 is that you can literally generate a random 64 bit number and it'll work fine as a host address.
That is IMHO partly true, I might have an android base appliance I want to share over my WAN port. Really, I consider the android exception not primarily an android failure, but an IPv6 standardization failure as the android approach is/was acceptable within the IPv6 specs...
This is one of the tricks I have relatively little interest in... memorizing random 64bit numbers is not much fun, so while I agree that for ephemeral addresses such randomly drawn addresses are A-OK, for offering services or hardcoding addresses of internal infrastructure nodes (where I would like to be able to reach the node by address months later) random 64bits are far less attractive, at least for somebody with my limited short term memory capacity. 
This is what DNS is for! I've got what 12 or 15 machines in my house all running ipv6 all potentially providing services (at least ssh) and I have never ever entered their ipv6 address directly into anything. All the items that provide externally accessible services are doing DDNS to a subdomain of my personal vanity domain, so even if I'm accessing from the broader internet I can vpn into my home or mount my kerberos encrypted NFS4 fileserver. I have no idea what the ipv6 numbers are of any of them.
Occasionally I want/need to access network nodes without DNS working.... (I am not alone in that /127 or /128 are supposedly common for addressing infrastructure nodes in bigger networks as well). For IPv4 in my small home network that works reasonably well, as I does with specifically tailored IPv6 addresses ending in e.g. ::a but random 64bit numbers not so much...
And that is fine as long as everything (mostly DNS) works, but as I said might be nice to be able to debug things at least to some degree if DNS goes boink... (which again is possible with IPv6, but with ramdom64bit requires written notes)
Sure, if you want to manually number 5 nodes, that works too... Say the router is ::1 the NTP server is ::2 the three access points are ::3 ::4 ::5 the NFS server is ::6 it's also totally doable. It makes it easy to DoS your network because external users can guess all your infrastructure addresses, but yeah it's a low risk for most people and might be worth the tradeoff.
I don't understand the issue. Basically we have:
- I want to use DHCPv6 to give servers addresses... (ok, it works !)
- I want to use short suffixes for a small number of devices (ok, it work!)
- I want to use random 64 bit numbers and DNS (ok, it works!)
- I want to use SLAAC with MAC addresses (ok, it works!)
- I want to use SLAAC with stable privacy addresses (ok, it works!)
- I want to use unstable short lived privacy addresses (ok, it works!)
- I want to force android clients to use one and only one address (ok, google believes this is a strong enabler of a surveillance state / privacy intrusion / address hoarding / precludes future valid uses / prevents tethering / etc and won't let it work, if you want Android devices on your network you can't eliminate all above options except 1).
SeE Ipv6 is BrOkEn!
I just don't get it. Yeah, android is pushing back against a system whose primary use case is various forms of oppression. This doesn't mean the protocol is broken.
Sorry interface identifiers are not inyended to reduce the DOSability of edge networks, as long as the attacker knows my prefix and can muster>> my access rate my network is toast, independent of how I selected interface identifiers. What random IIDs do is make it really hard to brute force internal hosts, but for that I have a firewall in place....
Look IPv6 is a decent succesor for IPv4 splving its single biggest issue in a grandiose way that is unlikely to reach its limits in our lifetime, but what it is not is the best idea since sliced bread, it has its own collection of 'warts'. Not the least of it is its tendency (or IPv6's evangelists tendency) to try to not accept these warts but to claim people want the wrong thing and should chsnge their ways. Or argue away issues (like arguing nobody should use android devices as 'servers' so android's SLAAC insistency would not count as failure).
This is very much not my argument, my argument is more grayscale than black and white, I just don't buy the "IPv6 solves all problems" argument.
To be explicit, I consider 64 bit interface identifiers as a collossal waste of precious IP header bits, but I am confident that the current SLAAC approach will serve well to avoid ossification (no firewall will drop based on iid bit patterns as these are sufficiently unpredictable/variable), and I expect some time in the future some of these 64 bits will find alternative uses...
E.g. I would like to use (randomly selected*) 3 IID bits as priority selectors so I could have reliable end2end 'DSCPs', or take >=4bits to store max buffer occupancy along a network path to get a better early congestion notification system**. For all these ideas it will be excellent to be able to tap into a nice reservoir of IP bits....
*) to avoid intermediate hops to try to deduce my internal priorities.
**) Not my idea unfortunately, but IMHO one way to help with TCP slow start
SCNR, given that android ships with a lot of privacy extraction apps already I do not buy that google is doing this to fight oppression and surveilance, orvso then only 'surveilance' by parties other than google
Anyway, looks like we got into the weeds inevitably.
I still think it's a good thing that US traffic to google is more than 50% ipv6 and that maybe in a year or so with 60% or more ipv6 it'll be time for people to wake up and get connected. It's still mind blowing to me that there are ISPs that are ipv4 only.
2 Likes
+1, some even do IPv4 only via CG-NAT which I am not sure can be qualified as 'internet access'.
2 Likes
Works fine for me. Why do I need IPv6 or public IP? I don't need a postbox to fly a plane. Or a toaster accessible from Mongolia. I'm more bothered about weak regulation failing to prevent traffic management.
Still, nearly all ISP offer only dynamic ipv6 prefix without costing your arm and leg for a business lease, making ipv6 essentially useless for power users who want more than just steaming youtube videos.
Always impressed by how much I learn watching Daniel and Sebastian discuss a topic. 
3 Likes
Have you ever read the rules of an RIR?
E.G. some don't even allow governments to alter...and I'm sure "surrender" may exist in some. Also, such uses are not for assignment, they must go by RFC (i.e. another exhaustion idea).
Also, TBH, where is there an actual need for more 6 to 4?
Nothing solves/cures the original "end-to-end principal" - save IPv6.
Why would a government give that up?
EDIT: from my ISP paradigm, I really just want to carry your traffic to you - no alterations. If it pings, and basics,etc. you're good. Figuring out translations, who handles that (and do you really want some device not in your control doing it (recall, IPv6 has always mobile secure assignment implications not fully seen yet)? (that's why Idon't get why ppl wanna play with the design of WG for example without seeing the white paper)
Because of all the things that simply can not really be done now that you don't know about because they aren't being done...
why do you need internet when your telephone works just fine wired to the wall with a dial... that kind of thing.
They're literally sitting on this enormous block. Recently during the Trump administration they put it under the control of some company and used it like a honeypot...
anyway, the point is if you're an enormous "big dog" like the US Govt with a massive cache of unused addresses, you can just tell people what to do with them. Lease them out directly for example. The US Govt has a huge incentive to make ipv6 happen at scale (the US Military would benefit enormously from 27 electronic devices on each soldier's body all with their own ipv6 address all communicating in real time to swarms of surveillance drones, send blue-force tracking data to battlefield computers etc etc etc) That kind of thing is only going to happen when the device mfg are actually familiar with it all, and that kind of thing is only going to happen when commercial usage is widespread.
Beyond the internal motivation, the govt should be forcing the creation of public goods, and more small ISPs able to offer full featured ipv6 only connections, with NAT64 so their service isn't useless to those who want to access ipv4 only sites is part of that. (and yes, I know that the govt has generally gone the other direction, and there are even state laws making it illegal for municipalities to compete with commercial ISPs etc)
1 Like
Case in point for that? the removal of traditional copper based home phones with IP/SIP phones over data lines instead. Over here the major ISP (BT) is no longer providing copper telephony. Its all SIP based now.
It made for interesting experiment and reading. But thing is that people have been abusing reserved or other ip ranges for years. Spammers in particular would abuse legitimate ranges to mass spam. Throw in BGP hijacking and you can do all sorts of nefarious things... Like china rerouting major chunks of the internet to go via their routers. Not just once... but repeatedly. Its why secured BGP is being worked on to prevent things like that happening.
I disagree to a point on this, but for the following reasons.
Firstly it should be down to international standards for internet protocols and deployment. Having a government mandate how you connect to the internet leads to things like China's great firewall. (Russia and Iran as well).
I do agree there should be legislation that treats internet access like water/gas/electricity providers. Sadly the brown paper envelopes stuffed with cash are still making sure in some places that never happens. Ars Technia has multiple articles on that and how its abused. There are some nice stories of people who have formed Co-Operative or municipal ISPs and are murdering the profits of the big 6 (who are bluntly... a shitshow).
Also we are more into discussion rather than actual using of OpenWrt. Still its always good to see the viewpoints and technical discussions of the underlying tech.
1 Like
grumble like bloody TalkTalk in uk. Can't wait to be rid of them.
I think sky took like 10yrs to get theirs sorted too. I moved off them ages back because they didn't have IPv6 either.
I thought in the UK andrews&arnold would offer a boutique service catering to exquisite tastes like yours? Fixed IPv4 and IPv6...
We have a similarly enlightened small ISP in tal.de, but over here the incumbent (and some bitstream reseelers) deploys full DualStack with a /56 prefix, serving my needs* well at a lower price.
*) I embraced dynamic DNS already.... for IPv4 so extending that to IPv6 is not a big deal... unless addresses are fully static it does IMHO not matter all that much whether they last 24 hours or 180 days, you need to be prepared for address changes and ddns does that reasonably well.
1 Like
I am still not sure what I am missing, mindful that I don't need to access my toaster from Mongolia. Isn't IPv6 just a very long and horrible-looking, unwieldy identifier that works for computers but not so well for humans? I clearly don't understand the issues but am enjoying reading the posts on this thread.
With CG-NAT the number of connections you can simultaneously open (and hold open) is typically severely limited (with a public IP you can have 16bits worth of TCP and UDP connections each IIRC, with CG-NAT you typically only get a small helping of ports). This becomes especially dire when you actually want to make services available (note the plural) also with CG-NAT you share IP addresses with other users and if they are misbehaving in some sort the IP might be blocked and that block will affect all users of that IP.
In general CG-NAT with limited port space is a rather terrible solution for generic internet access (passive and active) it is however typically good enough for a more consuming internet usage (after all people paying for internet access expect at least typical stuff like streaming to work), but already stuff like peer to peer voice chat can become tricky with CG-NAT.
In short CG-NAT, don't do it. Now if an ISP does not have enough IPv4 addresses to at least assign public IPv4 addresses dynamically, they should at the very least make up for this by also deploying public IPv6 addresses/prefixes (actually, and I think I agree with @dlakelan for a change, ISPs should deploy public IPv6 prefixes unconditionally)... Internet works best if all participants have the freedom to participate as servers and as clients...
We already had internet connected coffee machines in the 90s over IPv4:
Yes, but here is the thing, 128 bit addresses likely will last until the demise of humanity and arguably 64bit addresses would also already by more than most people can remember well. (we can haggle whether the representation as hexadecimal is more intuitive than decimal-byte values would be, but at least is is a bit shorter ("fields" are at most 2 characters wide)).
It boils down to that 32bit ~ 4 billion addresses are not fit for purpose for 8 billion humans and something needed to be done; however when things are done often more changes are folded in. I think most here agree that extending to addresses to >> 32bit is not controversial, while the opinions on some of the other changes seem to differ
2 Likes