if have a main OpenWrt 18.06 router hooked up to my ISP, who gives me a /56 IPv6 prefix, which is then delegated to LAN with ip6assign 60. Towards LAN both dhcpv6 and ra servers are enabled.
I now configured a second, cascading 2nd tier router on LAN for testing purposes, and set up its WAN side with dhcp & dhcpv6. Which basically all works, the router gets a /128 address plus a /62 prefix.
What confuzzles me though is that the 2nd tier router also does slaac on the WAN client side. I thought it would use router advertisements only for gateway configuration and not for IPv6 address autoconfiguration. But it configures a second /64 global address with EUI-64 part. Moreover, that address is used as default source address for all global routes.
Is that how it's supposed to work? I though slaac was supposed to be disabled on the WAN side.
The reason that troubles me is that I don't want to have MAC addresses leaked to the Internet. Which is why I wrote an according firewall rule on my 1st tier router, and that's why I noticed the problem, by having no connectivity on the 2nd tier router.
So no slaac on WAN interface, that's what I'm looking for, and what I thought was the default but then it wasn't ...
Thanks in advance for responses,
R.
EDIT:
Ok guys, I'm done fiddling around with this rather annoying ipv6 stuff. Permanently cleared the A bit in the 1st tier's router advertisements (ra_management 2), effectively turning off slaac for the entire LAN. So any client that wants to do ipv6 networking around my house has to use stateful dhcpv6. Which also does away with the messy address inflation happening on interfaces. Question not answered but problem solved.
First off, if - like in my case - your ISP provides you with changing IPv6 prefixes each time you connect "ra_management 2" is no good. Because that leaves your clients w/ stale dhcpv6 leases, as long as the lease time goes. So I changed that back to 1.
Then there's again the problem of MAC address leakage, by means of EUI 64. Normal clients would support rfc4941, which is a remedy, but not OpenWrt. So a 2nd tier router would still leak.
Yes, sort of. The router behind the router, that's why "cascading". A second router I've been testing on my LAN, behind the one that connects to my ISP. This 2nd tier router also has global IPv6 addresses, and those use EUI64 by default.
Also, it isn't about the MAC my ISP directly sees. It's about the encoding of the MAC in IPv6 addresses which everybody on the Internet sees. That's why the ruckus.
So again, if you have OpenWrt routers behind your main, ISP connected router on your LAN and you take no extra measures, as suggested above, those 2nd tier routers do "broadcast" their MAC addresses to the entire (IPv6) Internet if the main router provides SLAAC configuration.
I'm somewhat lost...and perhaps it's because I think it's impossible to do what you describe.
Are you requesting that SLAAC be an option to be removed from the IPv6 stack?
SLAAC is required in IPv6. I'm almost certain you need static addresses and static routes to your LAN for disabling this...my IPv6 gateway is my Link-local IP. That is obtained through SLAAC.
The thing I should mention here is this: the Link-local address is derived in this manner, and this likewise required. It's also how routers with IPv6 can know if they're connected to the same device...even if on different VLANs (which don't particularly matter except for static routing)...because there's the same Link-local address on different interfeces. A lot of us in the community have prevented a "soft brick" to their device by locating the Link Local IP of the router when we messed up our IPv4 config.
No, it's configurable via the 'A' flag in router advertisements. You can turn SLAAC off for your LAN if you set "ra_management" to 2 on your OpenWrt router. In this case all (global) addresses your clients will get are DHCPv6 addresses (recognizable by /128 prefix). Link local addresses are obviously not affected by this and of no interest to this discussion anyway, because they aren't routable and thus can't leak any information to the Internet.
On the other hand, if you set ra_management to 1 your LAN clients will receive router advertisement with 'A' bit set, and begin to configure global (!) SLAAC addresses on their own. And that's when trouble can arise, as detailed above. Specifically when you have more OpenWrt routers (or poorly configured clients of any kind) on your LAN.
I have to assume by the way that similar behavior can be expected if you connect to your ISP via DHCPv6 and your ISP provides SLAAC enabled router advertisements. The situation would basically be the same as I observed it with my 2nd tier router at home. Namely that, if the router has both global DHCPv6 and SLAAC addresses, it will prefer a SLAAC address for outgoing connections. And thus reveal its MAC to the Internet in its default configuration.
I wrote a whole response...but then, I finally recalled what I was looking for:
The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses
information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the
Duplicate Address Detection procedure described in this document on
all addresses prior to assigning them to an interface.
The IPv6 CE router MUST support Stateless Address Autoconfiguration (SLAAC) [RFC4862].
Partly. The link-local aspect is, as already said, totally beside the point. The other aspect though, "routers will need to be configured by some other means" is exactly what I'm talking about. Routers should not perform autoconfiguration for global addresses. Which is exactly what I'm saying.
I've already found the culprit though, which is /lib/netifd/dhcpv6.script. When commenting the
line in the RA_ADDRESSES block autoconfigured addresses don't get merged. Which leaves us with the DHCPv6 configured ones plus - your apparently so beloved - link local address. But no more global SLAAC addresses.
Maybe I should file a bug report against odhcp6c ...
I understand that to some degree...I'll get back to that in response when addressing your bug report inquiry...have you considered that a router can be setup just to be an IPv6 client on the upstream network, exclusive of the purpose of routing IPv6 Internet to the downstream network(s)?
If this IPv6 connectivity on your downstream CE Router bothers you, the RFC-friendly approach would be to disable IPv6 in that router, and it ceases to be an "IPv6 CE Router." I surmise, though, your issue is that you want it to be a downstream IPv6 router with hosts connected to it (likely because it's a downstream IPv4 router, too). Although, it seems you have a dynamic IP block issued by you ISP. As the RFC says, routers must be configured by some other means. That also means your ISP's config in relation to your downstream IPv6 subnets.
Feel free to do so; but in my opinion, this isn't a bug. You need static IPv6 addresses, per RFC4862.
I honestly think the community will experience increased complaints and issues of "my router can't use opkg" and other commands that use the Internet on IPv6 networks.
Then I think you aren't understanding the point of the 2 RFCs.
I think it should be borne in mind that, because of this address, I can route Public IPv6 traffic across downstream networks without Public IPv6 address space.
And using divisions of ULA as the routed subnets, I can route non-Public IPv6 traffic across networks I control.
As a side note if you have any Android devices you must enable SLAAC. Android doesn't support dhcpv6. I ran into this on my home network. I originally only had dhcpv6 enabled and my Windows and network devices worked great but my phone and tablet didn't get a IPv6 address.
which prevents leakage of MAC addresses from my LAN to the Internet. Which is precisely what my 2nd tier OpenWrt router tried to do, hence opkg failures.
Well, even if ip6ifaceid works with DHCPv6, which I'm going to test, I'd still consider it highly problematic that OpenWrt is prone to EUI64 MAC leakage in its default configuration. The simple kernel parameter setting I've mentioned above for example would fix that, without losing anything.
IMHO You should be able to disable SLAAC when using DHCPv6-PD. BTW a router with a delegated IPv6 prefix doesn't need a global IPv6 assigned to the WAN(6) interface since an address from the delegated prefix assigned to any interface, for example the LAN interface, can be used.
I always loose folks on this...according to RFC, you need static addressing to make a WAN interface configured "by other means"...I'm showing that OpenWrt contains no bugs. IF you were able to address your LAN with an IPv6 address from that block, it wouldn't be derived from the MAC, and problem solved! Again, that requires a static IPv6 address issued from the ISP, per the RFC...or you have to solve the problem of your upstream IPv6 addresses dynamically rotating because of DHCPv6.
Yes and no...this is against RFC if the downstream router must still be configured by autoconfiguration. That must be borne in mind...and I don't understand how a downstream router can be configured from an upstream dynamic bloc statically (except to make a static address as the upstream rotates, as noted above). This part of RFC4862 is vital in understanding this:
it is expected that routers will generate link-local addresses using the mechanism described in this document
In addition, routers are expected to successfully pass the
Duplicate Address Detection procedure described in this document on
all addresses prior to assigning them to an interface.
Some other software must be developed, or NAT66 must be used.
inet6 2003:xxxx:xxxx:xxxx:xxxx:ff:fe12:5362/64 scope global dynamic noprefixroute
and then
option ip6ifaceid '::1:2'
which yields exactly the same.
Just for initial testing. Maybe the documentation isn't up to date, the option might have a different name now or whatever. What's clear though is that this option, in combo w/ DHCPv6, does not do what we would like it to.
EDIT: Uhm sorry, and the same in the wan6 section of course:
You have to address your LAN using some proprietary means, and block use of the WAN address...it is impossible to to have a working IPv6 configuration if you do not use SLAAC on an autoconfigured WAN.
You are not an ISP, you don't "own" the IPv6 addresses. Meaning, - an RIR didn't issue them to you; and you wenrn't allocated those Ipv6 addresses by an ISP to whom they were issued.
I only surmise your upstream router is also an OpenWrt...that's where you need to place this proprietary script to address your LAN statically out of this WAN DHCPv6 pool/prefix/block, and to change it as it dynamically rotates.
If you want to easily do this, get a Tunnelbroker.net account and set it up. The IPv6 addresses are allocated; and therefore static. So your RFC4862 limitation of needing some other means to setup the downstream IPv6 CE router is solved. Do traceroutes to your closest tunnel server available to get best service.
Make sure you add your correct mailing address...if so the original /64 block they issue will be geocached to the correct location and registrant name. You shuold then be able to use services like netflix on IPv6.
Friend, I've addressed that already in my very second "update" post at the very top of this entire thread. You can do it w/ stateful DHCPv6 only (ra_management 2, no SLAAC). Problem is that it leaves you w/ stale addresses when you have no stable prefix, and when that one changes. So that's where you need SLAAC, and that's why I turned it back on.
So in that very post - again, the very second one at the top - I explained why I needed SLAAC, and what can still be done to turn the MAC leaking off. So thanks for telling me what I already said myself at the very beginning of this discussion.
Besides, what's w/ all the bold letters? Are you the yelling type or what's going on there?
No...I was showing you relevant portions...but somehow we went in a circle. I likewise explained early on:
I think you should file your bug report, re-read those bolded sections...or get static IPs. Glad you realize that code has to be rewritten to be noncompliant with the RFCs, in order to get it working.
