| Message ID | 20220908135804.735499-1-baptiste@bitsofnetworks.org |
|---|---|
| State | Under Review |
| Delegated to: | Baptiste Jonglez |
| Headers | show |
| Series | base-files: Don't enable ULA IPv6 addresses by default in new config | expand |
>>>>> Baptiste Jonglez <git@bitsofnetworks.org> writes: > ULA IPv6 prefixes (Unique Local Addresses, RFC 4193) are not routable > on the Internet. As such, they have very limited use, and enabling > them by default causes more problems than it solves: > - if an OpenWrt device already has external IPv6 connectivity with > globally routable addresses, then ULA addresses are not useful. That's just not the case. ULAs are intended to be the IPv6 version of RFC1918, useable for local communications. Please go read RFC7084. ULAs are required, and OpenWRT has been a leader here. I strongly object to this proposal.
>>>>> Baptiste Jonglez <git@bitsofnetworks.org> writes: > - there have been various bug reports [1, 2, 3] in 19.07 and 21.02 > where ULA addresses basically break global IPv6 connectivity. These > bugs have not been solved in several years, indicating a probable lack > of interest for ULA from the OpenWrt developer community. Seems to be a) a bug in MacOS. b) a bug reported in french, where my reading is that an he.net tunnel is involved. I don't see anything about ULAs here. c) a bug where a client didn't get a GUA, and not surprisingly, couldn't ping the internet. "so I suppose IP assignment is fine." But they weren't because the router didn't assign a v6 prefix to the LAN. Having ULAs available is critical to efforts to do HTTPS to the router. Please do not change this default.
> Le 8 sept. 2022 à 19:35, Michael Richardson <mcr+ietf@sandelman.ca> a écrit : > > >>>>>> Baptiste Jonglez <git@bitsofnetworks.org> writes: >> - there have been various bug reports [1, 2, 3] in 19.07 and 21.02 >> where ULA addresses basically break global IPv6 connectivity. These >> bugs have not been solved in several years, indicating a probable lack >> of interest for ULA from the OpenWrt developer community. > > Seems to be > > a) a bug in MacOS. > b) a bug reported in french, where my reading is that an he.net tunnel is > involved. I don't see anything about ULAs here. > c) a bug where a client didn't get a GUA, and not surprisingly, couldn't > ping the internet. > "so I suppose IP assignment is fine." > But they weren't because the router didn't assign a v6 prefix to the LAN. > > Having ULAs available is critical to efforts to do HTTPS to the router. > Please do not change this default. I’ve personally experienced on a linux client (running 5.18) a situation where ipv6 connectivity was lost, apparently because of foul play from ULA. The most obvious symptom was: pinging a target ipv6 address resulted in a ping reply from the OpenWrt router’s ULA address with « Destination unreachable: Unknown code 5 », as below: $ ping6 git.openwrt.org PING git.openwrt.org(git-01.infra.openwrt.org (2a03:b0c0:3:d0::160e:e001)) 56 data bytes From router.lan (fdc9:6d06:832a::1) icmp_seq=1 Destination unreachable: Unknown code 5 ^C --- git.openwrt.org ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms A traceroute would similarly stop at the router: $ traceroute6 git.openwrt.org traceroute to git.openwrt.org (2a03:b0c0:3:d0::160e:e001), 30 hops max, 80 byte packets 1 router.lan (fdc9:6d06:832a::1) 2.392 ms !<5> 2.351 ms !<5> 2.333 ms !<5> The issue was random. The client had a GUA assigned, below is the ipv6 routing table at the time of the issue: $ ip -6 route 2a0e:e701:11c2::/64 dev bond0 proto kernel metric 256 expires 7082sec pref medium fdc9:6d06:832a::/64 dev bond0 proto kernel metric 256 pref medium fe80::/64 dev bond0 proto kernel metric 256 pref medium fe80::/64 dev bond0.10 proto kernel metric 256 pref medium default via fe80::184f:a7ff:fe21:d230 dev bond0 proto ra metric 1024 expires 1793sec mtu 1492 hoplimit 64 pref medium For that matter, this setup only uses SLAAC (no DHCPv6 on LAN). Disabling ULA « fixes » this issue. HTH T
One of the first things I do when I bring up a new OpenWrt box is to disable ULA to the LAN as it has not usage in most scenarios I think. I basically use the IPv6 connectivity to receive a global prefix delegated from my ISP, install it on the LAN and bring global connectivity to devices behind it. I hardly see scenarios where ULA are used - and I know there may be legitimate scenarios - but I don't think they are many that justifies to have ULA turned on by default. I see no problem in turning it off and leave it as optional to be enabled for those cases Fernando On 08/09/2022 14:30, Michael Richardson wrote: >>>>>> Baptiste Jonglez <git@bitsofnetworks.org> writes: > > ULA IPv6 prefixes (Unique Local Addresses, RFC 4193) are not routable > > on the Internet. As such, they have very limited use, and enabling > > them by default causes more problems than it solves: > > > - if an OpenWrt device already has external IPv6 connectivity with > > globally routable addresses, then ULA addresses are not useful. > > That's just not the case. > ULAs are intended to be the IPv6 version of RFC1918, useable for local > communications. > > Please go read RFC7084. > ULAs are required, and OpenWRT has been a leader here. > > I strongly object to this proposal. > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi, On 08-09-22, Michael Richardson wrote: > > >>>>> Baptiste Jonglez <git@bitsofnetworks.org> writes: > > ULA IPv6 prefixes (Unique Local Addresses, RFC 4193) are not routable > > on the Internet. As such, they have very limited use, and enabling > > them by default causes more problems than it solves: > > > - if an OpenWrt device already has external IPv6 connectivity with > > globally routable addresses, then ULA addresses are not useful. > > That's just not the case. > ULAs are intended to be the IPv6 version of RFC1918, useable for local > communications. > > Please go read RFC7084. > ULAs are required, and OpenWRT has been a leader here. Thanks for the pointer, I had forgotten about this one. I just read it again. ULAs should be supported, but there is no hard requirement to use them by default. Even ULA-1 is a SHOULD, not a MUST, and it's only about generating a ULA prefix. I see two main arguments for ULAs in this RFC: 1) Section 3.2.1: allowing local IPv6 communication when the home router manages several links and there is no global IPv6 connectivity. If there is a single link, then the RFC agrees that "link-local addressing can be used instead". This is a good use-case for ULAs, but I'm not sure whether the multi-link situation is really common, and if there are any applications that can take advantage of ULAs in this specific case. In other words: how can clients coordinate when they are in different links and they have no global connectivity? That does not sound easy. 2) Section 3.1: stability of local addresses, even when the global prefix delegated by the ISP might change. This may work for IPv4 (192.168.1.1 is stable and well-known), but that argument doesn't fly for IPv6: who would use "well-known" raw ULA IPv6 addresses? Stable identifiers belong in the DNS, not in the IP layer. Actually, my main concern about ULA is that they don't get enough exposure among developers and power users, resulting in the kind of bugs I mentioned going unnoticed and unfixed, which is not good for a default-on feature. As a matter of fact, I always disable ULA on my OpenWrt builds (personal taste), and I suspect several other OpenWrt developers do the same. Baptiste
On 08-09-22, Michael Richardson wrote: > > >>>>> Baptiste Jonglez <git@bitsofnetworks.org> writes: > > - there have been various bug reports [1, 2, 3] in 19.07 and 21.02 > > where ULA addresses basically break global IPv6 connectivity. These > > bugs have not been solved in several years, indicating a probable lack > > of interest for ULA from the OpenWrt developer community. > > Seems to be > > a) a bug in MacOS. That's debatable, Linux should probably always use a link-local address as source address for NDP (but I haven't checked whether it's legal or not to use ULA here). > b) a bug reported in french, where my reading is that an he.net tunnel is > involved. I don't see anything about ULAs here. > c) a bug where a client didn't get a GUA, and not surprisingly, couldn't > ping the internet. > "so I suppose IP assignment is fine." > But they weren't because the router didn't assign a v6 prefix to the LAN. Both are actually the same issue. I spent some time with Thibault troubleshooting this issue on his setup, and it does look like a real bug when using both ULAs and global addresses. But since I don't have any use for ULAs, I cannot dedicate time to debug it further and try to fix it. Same for Thibault, he didn't actually have any use for ULA so he ended up disabling them. I suspect this is a rather common way of sidestepping the issue. > Having ULAs available is critical to efforts to do HTTPS to the router. > Please do not change this default. How do ULAs relate to HTTPS? Baptiste
On Thu, 8 Sep 2022 19:51:06 +0200 Thibaut <hacks@slashdirt.org> wrote: > The issue was random. The client had a GUA assigned, below is the ipv6 routing table at the time of the issue: > > $ ip -6 route > 2a0e:e701:11c2::/64 dev bond0 proto kernel metric 256 expires 7082sec pref medium > fdc9:6d06:832a::/64 dev bond0 proto kernel metric 256 pref medium So AFAICS here lies the problem. Same metric, same preference. The addresses below are usually tagged link local somewhere, but I assume the ULA is not. > fe80::/64 dev bond0 proto kernel metric 256 pref medium > fe80::/64 dev bond0.10 proto kernel metric 256 pref medium > default via fe80::184f:a7ff:fe21:d230 dev bond0 proto ra metric 1024 expires 1793sec mtu 1492 hoplimit 64 pref medium > > For that matter, this setup only uses SLAAC (no DHCPv6 on LAN). > > Disabling ULA « fixes » this issue. Sure. Above, it looks like a game of chance which address is used. From my understanding, router.lan would need to be told to do IPv6 NAT if clients are to reach outside with their ULAs, right? If I get a vote, I'd enable ULA generation only iff an IPv6 NAT was also configured, and, last but not least, I wouldn't randomise it. I'd go for e.g. fd00:4f57:5254 ("OWRT"), like all AVR use 192.168.178.0/24 on v4. Torsten
Hi, pá 9. 9. 2022 v 11:21 odesílatel Torsten Duwe <duwe@lst.de> napsal: > > On Thu, 8 Sep 2022 19:51:06 +0200 > Thibaut <hacks@slashdirt.org> wrote: > > > The issue was random. The client had a GUA assigned, below is the ipv6 routing table at the time of the issue: > > > > $ ip -6 route > > 2a0e:e701:11c2::/64 dev bond0 proto kernel metric 256 expires 7082sec pref medium > > fdc9:6d06:832a::/64 dev bond0 proto kernel metric 256 pref medium > > So AFAICS here lies the problem. Same metric, same preference. > The addresses below are usually tagged link local somewhere, but > I assume the ULA is not. When pinging a public IPv6 address the default route should be used. This should have nothing to do with the two routes above (2a03:b0c0:3:d0::160e:e001 IPv6 address has no match here). > > fe80::/64 dev bond0 proto kernel metric 256 pref medium > > fe80::/64 dev bond0.10 proto kernel metric 256 pref medium > > default via fe80::184f:a7ff:fe21:d230 dev bond0 proto ra metric 1024 expires 1793sec mtu 1492 hoplimit 64 pref medium This default route over bond0 should be actually used during pinging of git.openwrt.org (2a03:b0c0:3:d0::160e:e001). > > For that matter, this setup only uses SLAAC (no DHCPv6 on LAN). When you are pinging global addresses, also global IPv6 address should be used independently of the presence of ULA. For your public IPv6 prefix 2a0e:e701:11c2::/64 any ping outside should use the IPv6 address of your computer having this prefix. I would be interested in which address is actually used during pinging. Please share your `ip -6 address` too. And if possible, also please share `tcpdump -i bond0 -nv icmp6` while the computer is pinging. Important - all of this assumes that you are delegating your public IPv6 prefix from the router to all computers (I used to have a static IPv6 configuration on my OpenWrt router with option `ip6prefix` for that purpose). There is also a possibility that you mentioned - have NAT66 (ULA to public IPv6 prefix translation) on the router. This means that you could remove the public prefix delegation and just keep the ULA configured. All computers would use the ULA prefix when accessing public addresses. In this case you would need to change the firewall and add the following SNAT rule to the NFT firewall for the srcnat_wan chain: ip6 saddr fdc9:6d06:832a::/61 snat prefix to 2a0e:e701:11c2::/64 > > > > Disabling ULA « fixes » this issue. There is probably some different issue in your configuration, which causes this behaviour. Oldrich. > Sure. Above, it looks like a game of chance which address is used. > > From my understanding, router.lan would need to be told to do IPv6 NAT > if clients are to reach outside with their ULAs, right? > > If I get a vote, I'd enable ULA generation only iff an IPv6 NAT was also > configured, and, last but not least, I wouldn't randomise it. I'd go for > e.g. fd00:4f57:5254 ("OWRT"), like all AVR use 192.168.178.0/24 on v4. > > Torsten > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
út 18. 10. 2022 v 16:43 odesílatel Oldřich Jedlička <oldium.pro@gmail.com> napsal: > > Hi, > > pá 9. 9. 2022 v 11:21 odesílatel Torsten Duwe <duwe@lst.de> napsal: > > > > On Thu, 8 Sep 2022 19:51:06 +0200 > > Thibaut <hacks@slashdirt.org> wrote: > > > > > The issue was random. The client had a GUA assigned, below is the ipv6 routing table at the time of the issue: > > > > > > $ ip -6 route > > > 2a0e:e701:11c2::/64 dev bond0 proto kernel metric 256 expires 7082sec pref medium > > > fdc9:6d06:832a::/64 dev bond0 proto kernel metric 256 pref medium > > > > So AFAICS here lies the problem. Same metric, same preference. > > The addresses below are usually tagged link local somewhere, but > > I assume the ULA is not. > > When pinging a public IPv6 address the default route should be used. > This should have nothing to do with the two routes above > (2a03:b0c0:3:d0::160e:e001 IPv6 address has no match here). > > > > fe80::/64 dev bond0 proto kernel metric 256 pref medium > > > fe80::/64 dev bond0.10 proto kernel metric 256 pref medium > > > default via fe80::184f:a7ff:fe21:d230 dev bond0 proto ra metric 1024 expires 1793sec mtu 1492 hoplimit 64 pref medium > > This default route over bond0 should be actually used during pinging > of git.openwrt.org (2a03:b0c0:3:d0::160e:e001). > > > > For that matter, this setup only uses SLAAC (no DHCPv6 on LAN). > > When you are pinging global addresses, also global IPv6 address should > be used independently of the presence of ULA. For your public IPv6 > prefix 2a0e:e701:11c2::/64 any ping outside should use the IPv6 > address of your computer having this prefix. I would be interested in > which address is actually used during pinging. Please share your `ip > -6 address` too. And if possible, also please share `tcpdump -i bond0 > -nv icmp6` while the computer is pinging. Important - all of this > assumes that you are delegating your public IPv6 prefix from the > router to all computers (I used to have a static IPv6 configuration on > my OpenWrt router with option `ip6prefix` for that purpose). > > There is also a possibility that you mentioned - have NAT66 (ULA to > public IPv6 prefix translation) on the router. This means that you > could remove the public prefix delegation and just keep the ULA > configured. All computers would use the ULA prefix when accessing > public addresses. In this case you would need to change the firewall > and add the following SNAT rule to the NFT firewall for the srcnat_wan > chain: > > ip6 saddr fdc9:6d06:832a::/61 snat prefix to 2a0e:e701:11c2::/64 Sorry, typo here, prefix length should be 64 in both cases: ip6 saddr fdc9:6d06:832a::/64 snat prefix to 2a0e:e701:11c2::/64 Oldrich. > > > > > > Disabling ULA « fixes » this issue. > > There is probably some different issue in your configuration, which > causes this behaviour. > > Oldrich. > > > Sure. Above, it looks like a game of chance which address is used. > > > > From my understanding, router.lan would need to be told to do IPv6 NAT > > if clients are to reach outside with their ULAs, right? > > > > If I get a vote, I'd enable ULA generation only iff an IPv6 NAT was also > > configured, and, last but not least, I wouldn't randomise it. I'd go for > > e.g. fd00:4f57:5254 ("OWRT"), like all AVR use 192.168.178.0/24 on v4. > > > > Torsten > > > > > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
diff --git a/package/base-files/files/bin/config_generate b/package/base-files/files/bin/config_generate index 596fcf41fa..f0ea4b6eb2 100755 --- a/package/base-files/files/bin/config_generate +++ b/package/base-files/files/bin/config_generate @@ -45,13 +45,6 @@ generate_static_network() { set network.loopback.ipaddr='127.0.0.1' set network.loopback.netmask='255.0.0.0' EOF - [ -e /proc/sys/net/ipv6 ] && { - uci -q batch <<-EOF - delete network.globals - set network.globals='globals' - set network.globals.ula_prefix='auto' - EOF - } if json_is_a dsl object; then json_select dsl