Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Bjørn Mork, le mar. 12 juin 2018 15:19:25 +0200, a ecrit: > Samuel Thibault writes: > > > It's a matter of someone fixing the code. It seems Igor Scheller is > > happy to work on it, he just needs a way forward, not being only told > > that what is currently there is nonsense. > > Well, using fe80::1 as default gateway would not be a problem if it > weren't for the existing nonsensical code. Don't know how to say that in > any other way. By proposing actual solutions instead. So there was for one that netcfg-static needs to explicitly add a route to the gateway. Now, to check that it works: > So if you take a single default router address as input, then the > validation bolis down to sending a Neighbor Solicitation and seeing if > you receive a Neighbor Advertisement back. The question is now how to do that easily in netcfg-static (i.e. not crafting packets by hand). Samuel
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Samuel Thibault writes: > It's a matter of someone fixing the code. It seems Igor Scheller is > happy to work on it, he just needs a way forward, not being only told > that what is currently there is nonsense. Well, using fe80::1 as default gateway would not be a problem if it weren't for the existing nonsensical code. Don't know how to say that in any other way. Selecting a default router is described in https://tools.ietf.org/html/rfc4861#section-6.3.6 which points to https://tools.ietf.org/html/rfc4861#section-7.3 for the reachability detection. So if you take a single default router address as input, then the validation bolis down to sending a Neighbor Solicitation and seeing if you receive a Neighbor Advertisement back. Bjørn
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Bjørn Mork, le mar. 12 juin 2018 14:12:28 +0200, a ecrit: > Samuel Thibault writes: > > Bjørn Mork, le mar. 12 juin 2018 13:30:39 +0200, a ecrit: > >> But this will: > >> > >> frtest3:~# ip route add 2001:db8:f00::1/128 dev eth1 > > > > So this is a route, which can be checked for. > > No, it is a route you can safely add. Ok, then netcfg-static needs to be improved to do that. > But I think we are running in circles now. We aren't. > let's just flag the Debian IPv6 implementation as broken on this point > and move on. And let it stay broken at vitam æternam?... It's a matter of someone fixing the code. It seems Igor Scheller is happy to work on it, he just needs a way forward, not being only told that what is currently there is nonsense. Samuel
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Samuel Thibault writes: > Bjørn Mork, le mar. 12 juin 2018 13:30:39 +0200, a ecrit: >> But this will: >> >> frtest3:~# ip route add 2001:db8:f00::1/128 dev eth1 > > So this is a route, which can be checked for. No, it is a route you can safely add. Checking for it is no point. It does not have to exist prior to adding the gateway. >> > which is the point of the test AIUI. >> >> The test is pointless. There is absolutely no requirement that the >> gateway should be part of any larger on-link prefix or related to any of >> the configured host addresses in any way. > > Please scratch from your mind whatever you thought I meant. > > What I meant is that a route is needed for that. That is what we can > really check for to provide useful feedback to a user making a typo, > before trying to reach something on the Internet that might just be > randomly off. Noe, you can't check this. It makes no sense. But I think we are running in circles now. let's just flag the Debian IPv6 implementation as broken on this point and move on. Bjør
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Bjørn Mork, le mar. 12 juin 2018 13:30:39 +0200, a ecrit: > But this will: > > frtest3:~# ip route add 2001:db8:f00::1/128 dev eth1 So this is a route, which can be checked for. > > which is the point of the test AIUI. > > The test is pointless. There is absolutely no requirement that the > gateway should be part of any larger on-link prefix or related to any of > the configured host addresses in any way. Please scratch from your mind whatever you thought I meant. What I meant is that a route is needed for that. That is what we can really check for to provide useful feedback to a user making a typo, before trying to reach something on the Internet that might just be randomly off. Samuel
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Samuel Thibault writes: > Bjørn Mork, le mar. 12 juin 2018 10:52:30 +0200, a ecrit: >> Huh? What is this? There is no "gateway must be in subnet" requirement >> in IPv6. The gateway must only be reachable, which means that you must >> be able to resolve the L2 address using ND. > > Before that, you need a route, Sure. And that will be automatically added when the gateway sends an NA. But you can also simply add the gateway address as a static on-link /128 since you must assume that the gateway is on-link. Only static routing, no RAs involved and no NA received after flushing the neighbour table: frtest3:~# ifconfig eth1 eth1: flags=4163 mtu 1500 inet6 2001:4641:0:29a:5054:ff:feff:306 prefixlen 64 scopeid 0x0 inet6 fe80::5054:ff:feff:306 prefixlen 64 scopeid 0x20 ether 52:54:00:ff:03:06 txqueuelen 1000 (Ethernet) RX packets 189795 bytes 87803043 (83.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 130406 bytes 11889749 (11.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 frtest3:~# ip -6 route fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev eth1 proto kernel metric 256 pref medium Then this will not immediately work, as you note: frtest3:~# ip route add default via 2001:db8:f00::1 dev eth1 RTNETLINK answers: No route to host But this will: frtest3:~# ip route add 2001:db8:f00::1/128 dev eth1 frtest3:~# ip route add default via 2001:db8:f00::1 dev eth1 frtest3:~# ip -6 ne sho 2001:4641:0:29a::1 dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE fe80::21b:21ff:fea7:98bc dev eth1 lladdr 00:1b:21:a7:98:bc router STALE 2001:db8:f00::1 dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE fe80::21b:21ff:fea7:98bc dev eth0 lladdr 00:1b:21:a7:98:bc router STALE frtest3:~# ip -6 route 2001:db8:f00::1 dev eth1 metric 1024 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev eth1 proto kernel metric 256 pref medium default via 2001:db8:f00::1 dev eth1 metric 1024 pref medium frtest3:~# traceroute6 vg.no traceroute to vg.no (2001:67c:21e0::16), 30 hops max, 80 byte packets 1 canardo-br0-666.ipv6.mork.no (2001:4641:0:29a::1) 0.354 ms 0.445 ms 0.530 ms 2 ti0036a400-lo0-0.ti.telenor.net (2001:4600:0:200::5d) 5.932 ms 7.537 ms 7.591 ms 3 ti0001c360-lo0-0.ti.telenor.net (2001:4600:0:100::23) 7.292 ms 7.488 ms 7.791 ms 4 ti0169a400-lo0-0.ti.telenor.net (2001:4600:0:200::62) 8.207 ms 8.218 ms 8.481 ms^C (The gateway used its real address as icmp6 source here, but that is beside the point) frtest3:~# ip -6 ne sho 2001:4641:0:29a::1 dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE fe80::21b:21ff:fea7:98bc dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE 2001:db8:f00::1 dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE fe80::21b:21ff:fea7:98bc dev eth0 lladdr 00:1b:21:a7:98:bc router STALE frtest3:~# ip -6 route 2001:db8:f00::1 dev eth1 metric 1024 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev eth1 proto kernel metric 256 pref medium default via 2001:db8:f00::1 dev eth1 metric 1024 pref medium > which is the point of the test AIUI. The test is pointless. There is absolutely no requirement that the gateway should be part of any larger on-link prefix or related to any of the configured host addresses in any way. This is trying to force IPv4 logic onto IPv6, where it doesn't fit. > That said, the code should be looking over all networks of the > interface, not only the first. "networks" is a meaningless concept in IPv6. You have addresses which can be on-link or off-link, and prefixes which are relevant for routing and address generation. But none of these maps directly to the IPv4 "network". Bjørn
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Igor Scheller, le mar. 12 juin 2018 11:28:58 +0200, a ecrit: > Imho it could be a better option to just configure the interface and > test if something is reachable? "something" is the problem. We do test for reachability of the mirror anyway. But again, checking that there actually is a route does make sense. It just needs to be properly checked. Your proposed change doesn't make it worse (and the dev part really is needed). Samuel
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Bjørn Mork, le mar. 12 juin 2018 10:52:30 +0200, a ecrit: > Huh? What is this? There is no "gateway must be in subnet" requirement > in IPv6. The gateway must only be reachable, which means that you must > be able to resolve the L2 address using ND. Before that, you need a route, which is the point of the test AIUI. That said, the code should be looking over all networks of the interface, not only the first. Samuel
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
On 6/10/18 7:25 PM, Samuel Thibault wrote: > Igor Scheller, le dim. 10 juin 2018 18:57:50 +0200, a ecrit: >> When I try to configure fe80::1 (next router) as a gateway in an IPv6 only >> network the installer stops with an "Unreachable gateway" error. >> >> Looking at netcfg-common.c:netcfg_gateway_reachable its checked by comparing >> bytes. Imho a better way would be to configure the interface and ping the >> gateway? > Well, the gateway has no obligation to respond to pings, so it's not a > proper way. > > Checking that the prefix matches however makes complete sense, and > should just work. Provided that the network prefix length is correct, > of course, but it has to be otherwise it's a configuration error. I > guess the problem is rather there. Well, the gateway may as well be link-local and not be in the assigned prefix. That's unfortunately a valid configuration. I wouldn't call fe80::1 "next router", though. It's not a well-known address. ff02::2 (all routers) would be, in a way. But alas. I guess the answer here is that if the gateway is in fe80::/10 the route needs to be added with the interface's name, just like pointopoint does it. The better setup is to use autoconfiguration and let the router announce itself. That's how most production IPv6 setups work because the standard calls for that. But I know that especially providers like Hetzner are notorious for requiring their users to use a hard-coded fe80::1 default gateway. (And ifupdown supports this correctly.) Kind regards Philipp Kern
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Igor Scheller, le dim. 10 juin 2018 18:57:50 +0200, a ecrit: > When I try to configure fe80::1 (next router) as a gateway in an IPv6 only > network the installer stops with an "Unreachable gateway" error. > > Looking at netcfg-common.c:netcfg_gateway_reachable its checked by comparing > bytes. Imho a better way would be to configure the interface and ping the > gateway? Well, the gateway has no obligation to respond to pings, so it's not a proper way. Checking that the prefix matches however makes complete sense, and should just work. Provided that the network prefix length is correct, of course, but it has to be otherwise it's a configuration error. I guess the problem is rather there. Samuel
Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway
Package: netcfg-static Severity: normal Tags: ipv6 When I try to configure fe80::1 (next router) as a gateway in an IPv6 only network the installer stops with an "Unreachable gateway" error. Looking at netcfg-common.c:netcfg_gateway_reachable its checked by comparing bytes. Imho a better way would be to configure the interface and ping the gateway? -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (150, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
