When enabling forwarding for IPv6 on interface, in the routing table local appears new route. It like route to local ip but with all host bits set to 0. Example: -------------------------------------------------- # cat /proc/sys/net/ipv6/conf/eth0/forwarding 0 # ip -6 addr add 2001:db8:1:1::5/64 dev eth0 # ip -6 route show table local ... local 2001:db8:1:1::5 via :: dev lo proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295 ... # echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding # ip -6 route show table local ... local 2001:db8:1:1:: via :: dev lo proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295 local 2001:db8:1:1::5 via :: dev lo proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295 ... -------------------------------------------------- After enabling forwarding, route "2001:db8:1:1:: via :: dev lo" is added. No matter, forwarding is enabled before or after adding of address, this route is "on" with forwarding and "off" without it. Such behavior causes problems with /127 network masks. For example: -------------------------------------------------- # echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding # ip -6 addr add 2001:db8:1:1::5/127 dev eth0 # ip -6 route add default via 2001:db8:1:1::4 RTNETLINK answers: Invalid argument -------------------------------------------------- But if we disable forwarding (and strange route) when adding needed route, we will succeed. -------------------------------------------------- # echo 0 > /proc/sys/net/ipv6/conf/eth0/forwarding # ip -6 route add default via 2001:db8:1:1::4 # echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding -------------------------------------------------- Default route remains in the table after enabling forwarding and it is doing in work. But in this case we still can not access 2001:db8:1:1::4, because it is routed to loopback: -------------------------------------------------- # ping6 -c 1 2001:db8:1:1::4 PING 2001:db8:1:1::4(2001:db8:1:1::4) 56 data bytes 64 bytes from 2001:db8:1:1::5: icmp_seq=1 ttl=64 time=0.114 ms -------------------------------------------------- We get reply from self interface. This was tested on x86 and x86_64 with 2.6.30 kernel and some previous versions on ArchLinux (2.6.30 x86 and x86_64), Ubuntu (2.6.28-15-generic x86_64) and gentoo (2.6.30-gentoo-r5 x86_64).
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Sat, 17 Oct 2009 10:42:01 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=14427 > > Summary: ipv6 forward cause strange route > Product: Networking > Version: 2.5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IPV6 > AssignedTo: yoshfuji@linux-ipv6.org > ReportedBy: green@msu.ru > Regression: No > > > When enabling forwarding for IPv6 on interface, in the routing table local > appears new route. It like route to local ip but with all host bits set to 0. > Example: > -------------------------------------------------- > # cat /proc/sys/net/ipv6/conf/eth0/forwarding > 0 > # ip -6 addr add 2001:db8:1:1::5/64 dev eth0 > # ip -6 route show table local > ... > local 2001:db8:1:1::5 via :: dev lo proto none metric 0 mtu 16436 advmss > 16376 hoplimit 4294967295 > ... > # echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding > # ip -6 route show table local > ... > local 2001:db8:1:1:: via :: dev lo proto none metric 0 mtu 16436 advmss > 16376 hoplimit 4294967295 > local 2001:db8:1:1::5 via :: dev lo proto none metric 0 mtu 16436 advmss > 16376 hoplimit 4294967295 > ... > -------------------------------------------------- > After enabling forwarding, route "2001:db8:1:1:: via :: dev lo" is added. No > matter, forwarding is enabled before or after adding of address, this route > is > "on" with forwarding and "off" without it. > Such behavior causes problems with /127 network masks. For example: > -------------------------------------------------- > # echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding > # ip -6 addr add 2001:db8:1:1::5/127 dev eth0 > # ip -6 route add default via 2001:db8:1:1::4 > RTNETLINK answers: Invalid argument > -------------------------------------------------- > But if we disable forwarding (and strange route) when adding needed route, we > will succeed. > -------------------------------------------------- > # echo 0 > /proc/sys/net/ipv6/conf/eth0/forwarding > # ip -6 route add default via 2001:db8:1:1::4 > # echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding > -------------------------------------------------- > Default route remains in the table after enabling forwarding and it is doing > in > work. But in this case we still can not access 2001:db8:1:1::4, because it is > routed to loopback: > -------------------------------------------------- > # ping6 -c 1 2001:db8:1:1::4 > PING 2001:db8:1:1::4(2001:db8:1:1::4) 56 data bytes > 64 bytes from 2001:db8:1:1::5: icmp_seq=1 ttl=64 time=0.114 ms > -------------------------------------------------- > We get reply from self interface. > > This was tested on x86 and x86_64 with 2.6.30 kernel and some previous > versions > on ArchLinux (2.6.30 x86 and x86_64), Ubuntu (2.6.28-15-generic x86_64) and > gentoo (2.6.30-gentoo-r5 x86_64). >
Hello. This is not a bug but a feature of IPv6 called "subnet anycast address." The address is automatically assigned on routers. References: RFC 2526: Reserved IPv6 Subnet Anycast Addresses RFC 3627: Use of /127 Prefix Length Between Routers Considered Harmful --yoshfuji Andrew Morton wrote: > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Sat, 17 Oct 2009 10:42:01 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=14427 >> >> Summary: ipv6 forward cause strange route >> Product: Networking >> Version: 2.5 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: IPV6 >> AssignedTo: yoshfuji@linux-ipv6.org >> ReportedBy: green@msu.ru >> Regression: No >> >> >> When enabling forwarding for IPv6 on interface, in the routing table local >> appears new route. It like route to local ip but with all host bits set to >> 0. >> Example: >> -------------------------------------------------- >> # cat /proc/sys/net/ipv6/conf/eth0/forwarding >> 0 >> # ip -6 addr add 2001:db8:1:1::5/64 dev eth0 >> # ip -6 route show table local >> ... >> local 2001:db8:1:1::5 via :: dev lo proto none metric 0 mtu 16436 >> advmss >> 16376 hoplimit 4294967295 >> ... >> # echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding >> # ip -6 route show table local >> ... >> local 2001:db8:1:1:: via :: dev lo proto none metric 0 mtu 16436 advmss >> 16376 hoplimit 4294967295 >> local 2001:db8:1:1::5 via :: dev lo proto none metric 0 mtu 16436 >> advmss >> 16376 hoplimit 4294967295 >> ... >> -------------------------------------------------- >> After enabling forwarding, route "2001:db8:1:1:: via :: dev lo" is added. No >> matter, forwarding is enabled before or after adding of address, this route >> is >> "on" with forwarding and "off" without it. >> Such behavior causes problems with /127 network masks. For example: >> -------------------------------------------------- >> # echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding >> # ip -6 addr add 2001:db8:1:1::5/127 dev eth0 >> # ip -6 route add default via 2001:db8:1:1::4 >> RTNETLINK answers: Invalid argument >> -------------------------------------------------- >> But if we disable forwarding (and strange route) when adding needed route, >> we >> will succeed. >> -------------------------------------------------- >> # echo 0 > /proc/sys/net/ipv6/conf/eth0/forwarding >> # ip -6 route add default via 2001:db8:1:1::4 >> # echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding >> -------------------------------------------------- >> Default route remains in the table after enabling forwarding and it is doing >> in >> work. But in this case we still can not access 2001:db8:1:1::4, because it >> is >> routed to loopback: >> -------------------------------------------------- >> # ping6 -c 1 2001:db8:1:1::4 >> PING 2001:db8:1:1::4(2001:db8:1:1::4) 56 data bytes >> 64 bytes from 2001:db8:1:1::5: icmp_seq=1 ttl=64 time=0.114 ms >> -------------------------------------------------- >> We get reply from self interface. >> >> This was tested on x86 and x86_64 with 2.6.30 kernel and some previous >> versions >> on ArchLinux (2.6.30 x86 and x86_64), Ubuntu (2.6.28-15-generic x86_64) and >> gentoo (2.6.30-gentoo-r5 x86_64). >> > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
I wrote: > This is not a bug but a feature of IPv6 called "subnet anycast > address." The address is automatically assigned on routers. > > References: > RFC 2526: Reserved IPv6 Subnet Anycast Addresses > RFC 3627: Use of /127 Prefix Length Between Routers Considered Harmful I should say "Subnet-router anycast address" and RFC3513: Internet Protocol Version 6 (IPv6) Addressing Architecture". Sorry for confusion. --yoshfuji
Reply-To: pekkas@netcore.fi On Tue, 3 Nov 2009, YOSHIFUJI Hideaki wrote: >> RFC 2526: Reserved IPv6 Subnet Anycast Addresses >> RFC 3627: Use of /127 Prefix Length Between Routers Considered Harmful > > I should say "Subnet-router anycast address" and > RFC3513: Internet Protocol Version 6 (IPv6) Addressing > Architecture". FWIW, please note that commercial vendors haven't implemented this very extensively, and there's also some recent activity arguing this is not very useful: http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-00 We'll likely get better idea how folks react to this during the next week's IETF.
>> RFC 3627: Use of /127 Prefix Length Between Routers Considered Harmful Consider reopening bug. Because it is not more INVALID. Request for Comments: 6547 RFC 3627 to Historic Status Request for Comments: 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links
Can you verify the problem still exists on 3.2 or later ?
Sorry, missed last comment. Tested now on Arch linux 3.10.2-1 kernel. Looks like nothing is changed.
Hmpf, I thought that had been fixed with https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2bda8a0c8af5294b869da1efd2c2b9a562f50dcf. I'll have a look.
Oh, shit! I have tested on other prefix length. /127 is OK now. Thank you!
No problem! ;) I tested on net-next and really wondered why 3.10 should behave differently.