This is just a mistaken goal. There is no benefit to adding this additional artificial limit that your devices have exactly and only the one IP...
In IPv6 it is normal for each interface to have say 5 or 6 IPs... Link local, ULA, public DHCP, public SLAAC, privacy addresses... Etc etc
Some people might give a few hundred to each NIC if they want to run a bunch of different services on each machine.
Not sure I agree ;). I can understand and share the goal here. If one wants to control the traffic to/from a host (like in cake's per internal-IP-fairness modes) it can be quite helpful to ascertain that hosts can not circumvent that by exploding their number of concurrently active addresses. I note that typical IPv6 configurations will not actually do that, but there still is conceptual value in being able to set world reachable addresses at a central point (which will also make it easier to create special rules for IPv6 hosts in the firewall). Sure often one could use a host's MAC address for the same purpose, but IIRC iptables is set up for per IP rules out of the box in OpenWrt, not sure whether per MC rules are equally easy to create*.
But then, I have also accepted that IPv6 privacy addressing is a good thing (at least for non servers) so I realize that multiple concurrent addresses for IPv6 also can be the consequence of a sane process... Any idea how to properly "solve" this?
*) Sure MACs can be spoofed as well, it is never about having absolute control, but levels of gray instead 
I had similar issues like a half year ago.
At the beginning (I had no clue about anything IPv6 related) I was convinced to drop IPv4 completely. What a fool 
... I was also near to implement NAT for IPv6 to get old conventions back.
Anyway I ended up with a more strict segregated LAN. Parts of it are still IPv4 only and some are mixed. I decided also to disable DHCPv6 and using SLAAC only. Most clients here are Linux based so address configuration (static and/or temp; private/public) is not an issue. Even for Windows 10. The IoT things, Android devices and Guest devices are doing what they want cause they are getting IPv4 only. With proper IPv4 routing they can access other devices also.
What me helped a lot was this readme:
There are all necessary "buzzwords" inside which you can search/ask here or on internet. You can try out things and see what happen.
To find the SLAAC devices with their hostnames you can use this script:
But it's entirely up to the host. Any device can have a piece of software on it that adds 135 million addresses (given appropriate privilege)... your router can do nothing to prevent this. on Linux you can even add macvlan virtual devices and appear to be many different devices so the router can't firewall one MAC one IP6.
If you insist on DHCPv6 addresses only all Android devices cease to work. Basically just assume that devices can have multiple ipv6. This is a standard situation in ipv6 land. The OS has a source address selection algorithm that prevents non malicious machines from using multiple addresses for outgoing connections so the per IP fairness doesn't get broken. the incoming connections of course use whatever IP is in the source packet so this is a reason not to publicise many addresses per machine on your servers perhaps.
Yes of course it can, by using an allow list for which IPv6 addresses can traverse to/from the internet into the LAN, but for that to work, there needs to be a way to map that single permitted IP address to the MAC address (which for android will not work...)
Yes I realize this, as so often often the world is not binary but a gradient ;).
Yes, I know, unless one goes to the extreme of only allowing IPv4 for android devices as demonstrated by @pwned.
The issue are "non malicious machines" that is an assumption I have given up on ;).
You can't do that, if you use privacy addresses the old owner of an address will respond to it for a considerable time after it stopped using them for outgoing connection. Anytime the machine starts a TCP connection the IPv6 address used will be valid fo at least as long as the TCP connection lives, which can be multiple days, so privacy addresses can accumulate. Not sure how persistent these are over a reboot, but rebooting all machines regularly without additional cause seems like a bad idea.
But yes, IPv6 is going to be the way of the future, and IPv6 proponents typically counter concerns about control with, you need to make sure all end-nodes are secure by themselves. Which unfortunately falls flat in the face of the absurdity of security in the field of internet of things. Ad the saying goes, " the S in IOT stands for security"
Per IP fairness is a decent heuristic, and will continue to work fine with typical real world ipv6 deployments, even with privacy addresses and SLAAC. But it absolutely breaks in the presence of malicious machines on the LAN. if a machine wants to DoS the LAN it can attach to speed test machines with hundreds of IPs and soak up all the bandwidth. My QoS system uses DSCP and downgrades bulk transfers based on bytes transferred for example. it also identifies sparse UDP flows by packet size and frequency and auto upgrades them as well as identifying VOIP servers by a small static list and upgrading them. So from a malicious machine perspective I think it is somewhat more robust than the per IP heuristic.
long lived connections on privacy addresses is a theoretical concern but nonmalicious long lived connections with high bandwidth requirements are rare. Malicious long lived connections with high bandwidth are usually noticed and shut down.
Realistically multiple IP addresses on ipv6 isn't a problem by itself. malicious machines are a problem. perhaps better to address detection of malicious behavior directly than try to shoehorn one machine one IP as a kind of guarantee of fairness
Agreed, I think this is a reason to place "things" on their own VLAN and limit their access to Internet and total bandwidth. All my IP cameras are on a VLAN that has zero internet access, and each camera has a port based bandwidth limit on the switch. to view the cameras remotely you have to vpn to the home network... this kind of thing is going to be even more necessary in future.
I don't quite boot my Android phones off my home LAN but I limit my kids tablets to the guest Network for example.
Having a shit ton of IPv6 addresses is like boon and bain.
It is really nice to have for each single service running on a machine/vm or whatever a dedicated public IP.
But it is (IMO) a security nightmare if you realise that each application/device on your home network is able to request/set his own IP public address and open a port over Upnp. I mean there are already apps on Android having their own DNS resolver integrated. Games are opening ports like what ever they want. And now Apps/Devices can set/request a public IP by themself. Sure I've disabled Upnp. But the huge majority out in world probably not. And I imagine that (in future) Apps will run like half in cloud and like half on device within their own crypted networks simply because they can do it easy. (huge speculation, be aware!)
I am feeling that this thread is getting a little off topic by discussing the pros and cons of having multiple IPs or not. The basic statement remains: if you want to centrally control (and possibly firewall) the active IPv6 GUAs in your downstream network, the only suitable protocol is stateful DHCPv6 which unfortunately rules out Android.
Going back to @vevere initial questions/doubts... it seems like we're indeed handing out dynamic DHCPv6 leases with infinite validity. I am not yet sure what the decision behind this is, if it is mandated by any RFC or best practise but as pointed out, setting option ra_useleasetime 1 works by pegging the default DHCPv6 lease validity to option leasetime used for DHCPv4 already.
If there aren't any standard requirements to hand out infinite leases by default, pegging the default DHCPv6 leasetime to the DHCPv4 one would certainly follow the principle of least surprise.
A further possibility is declaring static DHCPv6 leases for each host, where an individual leasetime can be set per reservation.
As for suppressing e.g. the ULA prefix from being handed out over DHCPv6, one could use the option prefix_filter setting. Setting it to something like option prefix_filter 2000::/3 should cause odhcpd to hand out global internet unicast IPs to clients and not local ULA ones.
Hi guys,
Thanks a lot for all these replies.
It starts to be too hard for me to understand all of that (my English is not so good, I do my best)
IPv6 @home still doesn't work with the he.net tunnel.
So I decided to make another test, from scratch, stop working on my new router (Fritz!box 4040 with OpenWRT 19.07.3 with a custom build: see here => VLAN tagging on ipq40xx (GL-B1300) no longer works and use my old one (Western Digital My Net N750) also running 19.07.3.
So there is the DETAIL of all what I have done:
- went to tunnelbroker.net and get a /48 to conform with the tunnelbroker.sh
- reset Western Digital router
- Leave it unconnected from WAN/LAN (ISP box in bridge mode - fixed IPv4), only connected to my laptop
- Log on OpenWrt 19.07.3 r11063-85e04e9f46
- System : set hostname/timezone/NTP server => Save and apply
- Administration: password / allow ssh from LAN => Save and apply
- Network/Interfaces:
- WAN: change LAN settings (IP .. so scope) to match my home LAN
- WAN:
IPv6 assignment lengthto 64 - WAN: change DHCPv4 settings to:
Start address: 150; limit: 50, lease time 1h - WAN: save / save and apply ...
=> on my computer ipconfig/renew - WAN6: uncheck
Bring up on boot
Note: this time I didn't change the IPv6 ULA-Prefix (as I used to do before with one generated on https://cd34.com/rfc4193/ )
-
DNS:
- Set Local domain on DNS Server settings => Save and apply
-
SSH on the router:
- on /etc/config/dhcp add my static leases (without any "option duid" or "option hostid" ... just to have my IPv4 hosts IPs correct as soon as possible)
=> /etc/init.d/dnsmasq restart - on /etc/config/firewall add my very basic FW rules (DNAT for my mail server on TCP 25/80/143/443/587)
=> /etc/init.d/firewall restart
- on /etc/config/dhcp add my static leases (without any "option duid" or "option hostid" ... just to have my IPv4 hosts IPs correct as soon as possible)
-
Plug the router in place of the Fritz!box 4040
- quick check for the mail server (send/receive mail) => Ok
- install 6in4 : opkg update && opkg install 6in4 (oops, saw later than the script will do that alone)
- copy / edit tunnelbroker.sh, put in on the router, run it.
- run Ok
- quick check on the router Ok
- reboot router, quick check again (HENET on WAN firewall zone, tunnel up and running ...)
- ping4 and ping6 from Luci Diagnostics works fine
- => ... but not from the LAN
From my LAN:
- IPv4 DNS resolution => OK
- ping4 => Ok
- IPv6 resolution => OK
- ping6 => KO (100% packet loss)
I see I have no gateway on the HE link:
Any idea ??
And also, my Linux clients only retain the IPv6 information on /etc/resolv.conf
So I only have an IPv6 nameserver on this file (instead on 3 lines, the "domain" search, one IPv4 nameserver, one IPv6 name server)
I can add the search domain in the DHCPv6 configuration, but not the IPv4 name server to use ... a Debian behaviour ???
Thanks in advance for any help
I just see the last @jow reply ... with read this later, my children also need a bit of attention !!
but still problems with leases time (without the ra_useleasetime set)
Regards
Herve
No I didn't.
As it seems to me I have a big lack of understanding about IPv6 (and how OpenWRT works with) I decided to stop chew about that and to do .... the monkey.
So I decided to do just follow the doc ( https://openwrt.org/docs/guide-user/network/ipv6/ipv6tunnel-luci ), running the script linked on the doc and ask if it does not work.
But I took time to write ANY step I made during the process
If it worked it will be time later to spend time to understand WHAT I have done bad before
So ... I dindn't use any CPU (brain) time on this test, I just start again from scratch with a fresh install + the script and NOTHING else on the router (no Wireguard VPN for my laptop/phone, no adblock, no MWAN3, ni USB tethering ...)
So, the script tunnelbroker.sh should have done that for me: uci set network.henet.ip6prefix=$Routed_48_Prefix
.... but it doesn't
And I dindn't checked that .... monkey mode ... sorry
So I just added my 2 routed prefixes on Luci:
Now it (seems to) works under Windows (after a /renew) ... sorry, in French:
Thanks !
But some things still does not work => anything in this page in IPv6 only: eg. http://ip.lafibre.info/connectivite.php => http://[2a01:6e00:10:410::2]/images_test/
But it does not work under Linux (new VM for IPv6 testing) after a networking restart or a dhclient -6 -v -r && dhclient -6 -v or even after a reboot:
I made a test with Always announce default router checked (Not activated by tunnelbroker.sh)... much better under Linux !!!!!!
Yes there is an error in this script. The variable is defined:
Routed_48=2001:470:abcd::/48
But the variable is called with:
$Routed_48_Prefix
Just add to the line where you modify your prefix "_Prefix" (without quotes): So it looks like:
Routed_48_Prefix=2001:470:abcd::/48
Thanks everybody,
It works now, thanks to all of yours 
the Always announce default router solved the trick for the Linux hosts (seems not needed for Windows hosts)
but to be honest I really don't like this stuff.
DHCP means (meant ??) Dynamic Host Configuration Protocol
You decide (in a central point) what will do the devices for their network config.
Something was lost in space with IPv6 ...
Devices do what they want (defined on the standards, I know) and you hope to be able to control anything with that ???
I had a big joke in my LAN today, all my devices changed progressively their nameservers with those from google xxxxxxxxxx:8888 and xxxxxxxxxx:8844.
So I lost (resolv.conf or equivalent on Windows):
- Domain list
- Domain search list
- nameservers
Within an hour, none of my devices were still able to resolve local hostnames
It took some time but I found it came from one of my TP-Link Archer C7 v2 telling all the network to use these NS
And NOWHERE on the TP-Link interface you can find these NS .... NOWHERE !!!!!!!
So I think it is hardcoded on the Archer firmware and when you hit the "enable IPv6" it starts to broadcast that (and many more things ... and many of these things explain why I had an hard time to make this stuff working at home) ......... Good job TP-Link !!!!!!!!!
One more exemple for :
1/ How to destroy your LAN in 10 minutes ... plug a scrappy device on the first RJ45 plug you can find
2/ Or how to create a "ghost" scope (2nd scope in parallel of the official one) in an existing LAN allowing devices to have many IPv6 addresses and talk together on this another scope with another common broadcast address
And this was without any DHCP server running on the TP-LINK (I think) ... something you can't stop with firewall rules (eg 67-68 denied on client switches)
Thanks again,
Sorry if you think I'm too ... old-school
and sorry again for my bad English
Best regards
Herve
You do realize that an IPv4-only network isn't shielded against rogue DHCP servers either? Or clients using static configurations including malicious features (even if uncommon, it's very well possible that a single device using a single ethernet card runs dozens of IPv4 addresses at the same time, both for valid and nefarious purposes), unless you validate against a local RADIUS installation with (wired) IEEE8021X on your managed switch, there isn't really anything you can do against that either.
IPv6 is different in some aspects, but it will do the same jobs with similar implications. Part of the learning period includes getting to know its quirks - and to embrace them to some extent (to confirm if those are really an issue or just part of the game).
Yes, there are some aspects which aren't that easy (multi-WAN in its various flavours comes to mind, not so much because of inherent issues with IPv6, more because your off-the-mill ISP won't give you the option to accept packets from an alien prefix).
Hi @slh ... my Fritz!box 4040 run fine 
(I also have a x86 box [N3160] on the way ... end of the off_topic)
Yes I do, of course I do.
But I still think v4 is more mature (fortunately !!!!!!!!) and has better support (client side) than v6 that looks like more ... fragile/susceptible/delicat.
v6 is yet an "old" protocol (RFC1883: 1995 // RFC2460: 1998 // and RFC8200 .... 2017) but there is, even in 2020, not a real consensus (client side ... look at Android devices) to how to configure the clients network side (probably because one "thing" is not enough (dhcpv6, ra, slaac) and they can ... and need .. to work together, but you can implement this different ways
With IPv6 I always read something like : it depends (... to many ways to do things)
So yes, it is hard to make the jump ... but I'm doing this jump (not the easiest way thanks to my provider) and will learn that as I've learnt many things before
it should have been easier
I can say that with other words:
For a "father" (at home, small lan. Not for an IT guy at work) it is a way easier/quicker to configure (and understand) a LAN behind a NAT quickly and have its NAS (or whatever you want) working from outside that it will ever with IPv6. But you always can (and probably do) tell me that many things will work better with v6 (SIP phones, TV boxes .....)
this "technology" is not for easily for everybody
Oh,
I forgort to report about that: it is not better with or without option ra_useleasetime 1
not sure if it is because of clients or because of odhcpd or just a display problem on OpenWRT
When I made a change on OpenWRT (eg. by removing the Hurricane /48 on my HE interface) , without any other action, clients take care of modifications on the scope (eg. on Windows hosts: old IPs from this /48 go from "preferred" to "deprecated" few seconds after a change on OpenWRT even with a lease valid until ... sept. 2156)
Don't sure I have to care anymore about that
This isn't as helpful as it looks. For dynamic prefix forwarding to work, each receiving client must have a static address suffix. The only ways to do this are with DHCPv6 static addressing rules or by using tokenized identifiers and client-based static addresses.
Android doesn't do DHCPv6 or tokenized addressing, so dynamic prefix forwarding can't work with Android-based devices. Tokenized addressing is pretty much a Linux-only thing; it's not supported on Windows much less more consumer oriented devices. DHCPv6 static addressing generally defeats the purpose of DHCP because it means every system must have its address defined manually. Both methods to select a static IPv6 suffix disable IPv6 privacy addressing, which may be undesirable. As such, dynamic prefix forwarding is more of a niche thing for people who are running servers.
For IPv6 forwarding to be generally useful to the average user who just wants to get VOIP or gaming to work without NAT hassles, OpenWRT needs better IPv6 tooling. Some way to tie IPv6 rules to DUIDs, MACs, or other unique identifiers would make things far easier. I've filed an enhancement request on the bug tracker but it hasn't attracted any interest yet.
There are ways to prevent this; default-deny firewall policies that only open traffic to devices after they have authenticated through a captive portals is the most practical public and small-scale solution. This is how login-required public wifi networks work.
In the enterprise space, 802.1x addresses this problem.
Another option is a default-deny firewall policy combined with an internally-facing VPN server: any device that wants Internet access has to authenticate with the VPN server, which can impose its own access controls.
SLAAC IPv6 devices can be identified by unique identifiers: if the devices are on the same broadcast domain, the IPv6 neighbor protocol can obtain their MAC addresses. SLAAC devices in a different broadcast domain would need to be traced by other techniques, such as with 802.1x or by requiring them to identify themselves to a captive portal before they are allowed to connect to the Internet.
"work"
but yes you can go that route if so inclined.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.