Is IPv6 too hard for me?

Hi guys,

First, sorry for my English, it is not my native language, feel free to ask me if you don't understand what I mean !

I try to enter the actual millennium at home by activating IPv6.
I start to think my old brain will never be able to work with IPv6 !!!!!!!!!! never :o(

My internet provider send me a non routable /64 (I can't delegate a router for it)

So I suscribed a /64 tunnel from Hurricane Electric, it was the easy part of the challenge, no problem with that, the tunnel works fine on my FRITZ!Box 4040 with OpenWrt 19.07.3.
I think I don't need more than a /64 to learn IPv6, I want to stay with this /64 until all is well understood.

Just to stat with: my LAN works fine in IPv4 with my mail server behind the NAT accessible worldwide, no problem.
IPv6 works also fine but not really like I want ... and I don't understand WHY it works and WHY it doesn't works when I change anything on the config.

Can someone can redirect me to great/simple (but complete)/understandable tutorials ?

For me IPv6 is very hard to understant on OpenWRT:

  • 2 DHCP servers, one for IPv4, one for IPv6
  • DHCP config lost everywhere on Luci (a bit on the DNS menu, another bit on each net interface) .... why is it so complex ????
  • DHCP options are not the same for the 2 DHCP servers (eg. unable to have a fixed lease time for my V6 clients ... always see " unlimited leases)
  • wording not always conform with what you can read on RFCs or on other distros

What I want to do:

  • I want to remove IPv4 .... but it is too early, so I forgot that
    So:
    -1- Easy part; keep IPv4 as actual with NAT - no help needed for that:
    • 1-1 some clients on my LAN with fixed (with or DHCP) addresses [file server, mail server, Wifi APs, printers, major workstations ...]
    • 1-2 all the others in normal DHCP (no static leases for smartphones, tablets, laptops ....)
    • Port forwarding for my mail server

-2- Hard part for me ... almost the same for IPv6:
* 2-1: Some clients with fixed IPv6 adresses (the same as previous) ... but ONLY the fixed IPs I want them to have !!!
* 2-2: All the others 'as they want' (DHCPv6 or SLAAC or ... I don't care the name of that)
* 2-3: External routing working for selected ressources (at least mail server)
* 2-4: no secirity breach from IPv6 to enter on my network

My problem: I can't do 2-1 and 2-2 at the same time
If I do 2-1 (DHCPv6 statefull only) I can have my fixed IP for the selected hosts .... but they can't talk together on the LAN (on IPv6)
If I add 2-2 to the game so everybody can talk together .... but my server got 6 IPs !!!!!!!! (1x IPV4 + 5x IPv6: the fd80::, one ULA fixed [fdd5::], one ULA dynamic[fdd5::], one GUA fixed(2001::] from DHCP, one GUA dynamic [2001::])

I really don't care to share the exact configuration, one understood I can destroy/recreate all from scratch with new scopes.

I don't want to 'click here ... click there", I want to UNDERSTAND what I HAVE TO DO before applying anything.
I can destroy the config and start again from the beginning if needed, no problem

Can anybody can help me to understand this stuff ???
Can anyboby can tell me how it is easier than IPv4 ???
Can anyboby can tell me if OpeWRT is a good start for IPv6 at home or not (I really start to think it is not !!!!!!)

many thanks in advance
Herve

1 Like

One could argue about the distribution of options, however it is the very same for DHCPv4 and DHCPv6 in OpenWrt

The DHCPv6 server (odhcpd) uses the same leasetime option as the DHCPv4 one (dnsmasq). Right now it is not easily possible to set different lease times for DHPv4 and DHCPv6. The unlimited display in LuCI could be a display bug, hard to tell without further details

This means you need to use stateful-only DHCPv6 service to prevent hosts from self-assigning IPv6 GUAs, this is something that happens client side and cannot be really controlled on a per-host basis on the server side. Iirc Android does not stateful DHCPv6 though, so no IPv6 for Android clients then

As explained earlier, this is unfortunately not possible. The DHCPv6 server essentially broadcasts a Router Advertisement stating "you are allowed to make up your own address" in one of its flags (A / autoconf). This will cause all IPv6-capable clients to do exactly that once receiving it. Since it is an undirected broadcast, there is no per-client way to toggle address self-assignment (SLAAC) on or off.

There is another flag (M / managed) stating "you should send a DHCPv6 discovery to obtain an IPv6 GUA". Hosts receiving an RA having this flag set will start to initiate a DHCPv6 transaction. Except Android, which does not implement DHCPv6.

In order to support the broadest possible amount of clients (some may disable SLAAC for policy reasons), OpenWrt's odhcpd is configured to set both the A and the M flags by default, means IPv6 capable hosts will both self-assign a SLAAC GUA and try to obtain a DHCPv6 assigned GUA as well. This is then done for each prefix managed by OpenWrt, usually both the ULA and the global delegated one.

For clients like servers, where you feel that SLAAC IPs do not make sense, you could disable the IPv6 SLAAC assignment locally. On Linux this can be done using sysctl -w net.ipv6.conf.eth0.autoconf=0 (replace eth0 with the actual interface).

I assume you refer to the ability to access these servers from the internet (what would typically be a "port forward" for IPv4). In order to achieve that, you need to create a traffic rule which allows IPv6 traffic from the wan zone, towards the lan zone and IPv6 destination address.

In LuCI, such a rule could look like this:

In /etc/config/firewall, like this:

config rule
	option name 'Allow inbound traffic to desktop'
	list proto 'all'
	option src 'wan'
	option dest 'lan'
	list dest_ip '2001:470:1234:0:1234:824c:5588:16d4'
	option target 'ACCEPT'

Or using plain ip6tables:

ip6tables -I FORWARD -i eth1 -o br-lan -d 2001:470:1234:0:1234:824c:5588:16d4 -j ACCEPT

For a he.net tunnel, it is rather trivial since your prefix never changes so all your internal IPv6 addresses always stay the same. In case you use an ISP provided prefix which is frequently changing, a netmask matching only the last 64 bit may be given, causing iptables to only match the host part of the address. Coupled with a solution like DynDNS, it would allow permanent access to dynamic IPv6 addresses similar to how it would function with IPv4 + port forward + DynDNS:

ip6tables -I FORWARD -i eth1 -o br-lan -d ::1234:824c:5588:16d4/::ffff:ffff:ffff:ffff -j ACCEPT

This is not expected. What error do you get exactly when you try to ping6 a peer host?
If you receive a message similar to "destination port unreachable" it hints at a firewall misconfiguration. You might need to set the forward policy of the lan zone to accept then, but this is just speculation.

Yes, this is expected. Having multiple addresses is pretty much the norm with IPv6 and the operating systems source selection logic ensures that it always replies with the IPv6 address that was initially requested. As written above, you could disable IPv6 SLAAC assignments on hosts where you do not want it.

OpenWrt is supposed to make obtaining and redelegating IPv6 connectivity simple and it should work more or less out of the box. Judging from your post, this appeared to be the case.

From what I gathered, your pet peeve is that you do not want multiple IPv6 addresses on your servers or that you feel you're lacking some form of control?

1 Like

Thanks a lot jow for the time you took to make this great reply !
I learned many things in your reply, sorry if I dont react to all your great pieces of informaiton

I'm a sys-admin (VMware principally) but with limited skills in networking (I play a bit with VLANs but not relly deaper) so the jump to IPv6 is a bit hard.

I will try to make a short reply if possible:

  • Oh yes, very annoying to always navigate from one menu to the other

  • DHCPv6 leasetime: I have that (and for the first time I have 2 hosts with something else than "unlimited"
    image

from top to bottom; Debian 10 / Windows 10 / Windows 10 / Windows 10

The dhcp 'lan' config zone is:
image
=> Note the ra_useleasetime '1' to try to have a lease expiration.
Without this option I always had "unlimited" for all leases

For the "Unlimited" Debian:

For the "Unlimited" Windows:

.... valid until september 2156 !!!!!!!!!!!!!!

if I understand well what you explained to me: With SLACC (with or without DHCPv6) I will never see on the "DHCP Server Leases List" (in /tmp/hosts/odhcpd or in the Luci page) all the autoconfigured clients ?

If I understand well (again !!) I have no way to define a DHCPv6 scope as we can in DHCPv4 ?
image

So they are up-and-running devices on my LAN but with no way to easily see them on the DHCP server (I know I can see them with ip neigh or equivalent on other OSes but I don't see the hostnames in front of IPv6 addresses ... and also in this list there is many duplicate host entries

Is it possible to configure odhcpd with the flag M but without the flag A ? I think I can live with Android devices still in IPv4 and all the other in dual-stack for a while.
But I don't like too much to allow any client to get automatically an IP on my subnet once "connected" on the LAN (LAN or WLAN ... even if I only allow known MAC addresses to connect through Wifi)

The best for me (but seems impossible to do in a single /64) should be to only allow wired devices do get an fixed IP GUA with DHCPv6 and Wireless clients to get one with SLAAC

With DHCPv4 I can prohibit any unknow host to get an IP, I simply set an empty DHCP scope and configure only static leases, even if I can't prohibit a guy to manually configure a fixed IP on my local subnet. It seems to be harder to do the same thing with IPv6.

Yes, thanks, Of course already done ;o) ... even if I have no way to test my rules, none of my phones have IPv6 :o(

THANKS A LOT JOW !!!!
You just save my next headache !
I will move to FTTH (300/300mbps) next monday ... unfortunatly with a dynamic prefix and also a dynamic IPV4 (instead of DSL 15/1 with fixed IPv4 but no delegation on the /64).
I precisely got the HE tunnel this week to play with it and learn IPv6 before that.
This tunnel seems a bit slow (or with latency) but I didn't find anything better for my testing.
It seems to work well, I will perharps keep this tunnel even after my testing period

It perhaps my fault, because I tried many things:

  • disable the RA-Service to force my devices to have only one (and one only) fixed GAU address (iface eth0 inet6 static on Debian) ... not a good idea, it seems that default gw address is taken with RA, not with DHCP.
  • I also tried to force the "DHCPv6-Mode" to "Stateful-only" but I don't remember if I made this test with RA on or off .... to many tests these last days

Ok, tested => all is working fine with RA+Statefull-Only

Perhaps the good mode (for me !) is RA + DHCPv6 Stateful-only ... if I really want to see all my devices leases on the DHCP view. Or perhaps I can find an OpenWRT module that can display a "devices map" (some routers have that, like the Fritz!Box factory Firmware ... it could even see an old CPL plug I forgotten on the wall plugged on a switch ... thanks Fritz !)

So: IPv6 is not easy;

  • Internet Providers don't propose the same things all over the world (mine send a /64 without any possible delegation. It works in dhcpv6 with its box .... but that's all ... my future ISP will send me a /56 with delegation .... but with dynamic prefix grrrrr :grimacing:)
  • Many tuto are absolete
  • Many way for doing things
  • Protocol created for big networks ... nobody explains the "easy" (but correct) way for doing that for a home (read small) network
  • DHCPv6 is perhaps less mature than DHCPv4 (eg. when a device got an IPv6 and if you define later a static lease with a different address [because you need to know first its DUID to create the reservation] the device will not change its IP, even after a reboot. You need to do some manual tasks on the client for that. That is not the case with DHCPv4)
  • clients implementation differ widely
  • DHCPv6 needs RA to works ... RA alone is not enough and needs DHCPv6 also ... so what ? it shouldn't be simplier ?
  • FW/Router distro (OpenWRT, pfSense, DD-WRT, and all others) make choices (option I, Option M, Option O ....) but when you have to choose your distro (or your vendor, Netgear, D-Link, Linksys, Asus, MikroTik ...) you don't know wich choices they made for you, and wich limitations you will have to face !!
  • Linux (at least Debian with resolvconf) is really bad on some details (/etc/resolv.conf can have only one DNS server configured, IPv4 or IPv6 ... depending on wich DHCP server replies first, the last one to reply replace the nameserver gotten from the first one ... but is is perhaps because of OpenWRT wich as 2 DHCP servers .... Windows hosts don't care of that, they keep the 2 nameservers). The proof:

After a fresh reboot:
image

Another fresh reboot 5 min. later:
image

I'm sure that will be better soon ... but when ?

Many thanks again jow, it (almost) works as I want now

Best regards
Herve

fw3 IPv6 configuration examples > Dynamic prefix forwarding

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.

3 Likes

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 :wink:

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 :smiley: ... I was also near to implement NAT for IPv6 to get old conventions back. :smiley:

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.

1 Like

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" :wink:

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!)

1 Like

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 length to 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
  • 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:
image

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

Did you configure your /48 prefix in the henet interface settings?

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:
image
image

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 :innocent:
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).

1 Like

Hi @slh ... my Fritz!box 4040 run fine :cowboy_hat_face: (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

image

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