SixXS::Sunset 2017-06-06

tunnel working, but subnet routing not working.
[us] Shadow Hawkins on Thursday, 16 October 2014 18:06:20
I have a debian system which is running AICCU 2007.01.15-console-linux by Jeroen Massar. The machine is behind an old WRT-54G router providing NAT. The tunnel works fine, and I can ping6 google.com from the machine running aiccu. I can also access a webserver running on the machine using its ipv6 address. I got a Routed /64 Subnet from SixXS, which is enabled. I am running radvd version: 1.9.1. Here is my /etc/radvd.conf: interface br0 { AdvSendAdvert on; prefix 2001:4830:1600:850a::/64 { }; }; The interface is br0, because that's the interface my box connects to the router through. Here is the interface info: bminton:~# ifconfig br0 Link encap:Ethernet HWaddr aa:00:04:00:0a:04 inet addr:192.168.1.9 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:225124 errors:0 dropped:0 overruns:0 frame:0 TX packets:243644 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:41343463 (39.4 MiB) TX bytes:151989214 (144.9 MiB) dummy0 Link encap:Ethernet HWaddr 9a:ed:e8:e5:13:23 inet addr:75.75.183.132 Bcast:75.75.183.255 Mask:255.255.255.0 inet6 addr: fe80::98ed:e8ff:fee5:1323/64 Scope:Link UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:90 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:18252 (17.8 KiB) dummy0:0 Link encap:Ethernet HWaddr 9a:ed:e8:e5:13:23 inet addr:192.168.1.226 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 eth0 Link encap:Ethernet HWaddr aa:00:04:00:0a:04 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:225412 errors:0 dropped:0 overruns:0 frame:0 TX packets:280077 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:44658777 (42.5 MiB) TX bytes:153860692 (146.7 MiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:119263 errors:0 dropped:0 overruns:0 frame:0 TX packets:119263 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:40852453 (38.9 MiB) TX bytes:40852453 (38.9 MiB) sixxs Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet6 addr: fe80::4830:1600:50a:2/64 Scope:Link inet6 addr: 2001:4830:1600:50a::2/64 Scope:Global UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1 RX packets:344 errors:0 dropped:0 overruns:0 frame:0 TX packets:497 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:49300 (48.1 KiB) TX bytes:518951 (506.7 KiB) Forwarding is turned on: bminton:~# sysctl net.ipv6.conf.default.forwarding net.ipv6.conf.default.forwarding = 1 bminton:~# sysctl net.ipv6.conf.all.forwarding net.ipv6.conf.all.forwarding = 1 bminton:~# cat /proc/sys/net/ipv6/conf/default/forwarding 1 bminton:~# cat /proc/sys/net/ipv6/conf/all/forwarding 1 ip6tables and iptables are allowing forwarded traffic: bminton:~# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 22 Chain FORWARD (policy ACCEPT) target prot opt source destination dtc-xen-fw all -- 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain dtc-xen-fw (1 references) target prot opt source destination ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 50/sec burst 5 DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 100/sec burst 5 DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 Chain dtc-xen-in (0 references) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 reject-with icmp-port-unreachable tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: UPDATE seconds: 300 hit_count: 10 name: DEFAULT side: source mask: 255.255.255.255 reject-with icmp-port-unreachable ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 5/sec burst 5 DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 10/sec burst 5 DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x04 limit: avg 5/sec burst 5 DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x04 Chain fail2ban-ssh (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 bminton:~# ip6tables -L -n Chain INPUT (policy DROP) target prot opt source destination DROP all ::/0 ::/0 rt type:0 segsleft:0 ACCEPT icmp ::/0 ::/0 ACCEPT tcp ::/0 ::/0 tcp dpt:443 ACCEPT tcp ::/0 ::/0 tcp dpt:80 ACCEPT tcp ::/0 ::/0 tcp dpt:53 ACCEPT udp ::/0 ::/0 udp dpt:53 ACCEPT tcp ::/0 ::/0 tcp dpt:123 ACCEPT udp ::/0 ::/0 udp dpt:123 ACCEPT tcp ::/0 ::/0 tcp dpt:11371 ACCEPT tcp ::/0 ::/0 tcp dpt:11370 ACCEPT all ::/0 ::/0 state RELATED,ESTABLISHED ACCEPT icmpv6 ::/0 ::/0 Chain FORWARD (policy ACCEPT) target prot opt source destination DROP all ::/0 ::/0 rt type:0 segsleft:0 Chain OUTPUT (policy ACCEPT) target prot opt source destination DROP all ::/0 ::/0 rt type:0 segsleft:0 ACCEPT icmpv6 ::/0 ::/0 On the client (a Raspberry Pi running Raspbian), I have: root@raspberrypi:~# cat /proc/sys/net/ipv6/conf/eth0/accept_ra 1 root@raspberrypi:~# sysctl net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra = 1 root@raspberrypi:~# ifconfig eth0 Link encap:Ethernet HWaddr b8:27:eb:8a:75:e8 inet addr:192.168.1.165 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2001:4830:1600:850a:ba27:ebff:fe8a:75e8/64 Scope:Global inet6 addr: fe80::ba27:ebff:fe8a:75e8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1541 errors:0 dropped:0 overruns:0 frame:0 TX packets:1041 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:132437 (129.3 KiB) TX bytes:131304 (128.2 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) However, I can't get external ipv6 connectivity: root@raspberrypi:~# ping6 -c 3 ipv6.google.com PING ipv6.google.com(iad23s06-in-x03.1e100.net) 56 data bytes --- ipv6.google.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2006ms There are no firewall rules on the client: root@raspberrypi:~# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination root@raspberrypi:~# ip6tables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Monitoring with tcpdump shows (on the gateway): bminton:~# tcpdump -i any -vv ip6 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 14:01:56.289412 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:4830:1600:850a:ba27:ebff:fe8a:75e8 > iad23s06-in-x03.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 1 14:01:56.289412 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:4830:1600:850a:ba27:ebff:fe8a:75e8 > iad23s06-in-x03.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 1 14:01:56.289458 IP6 (hlim 63, next-header ICMPv6 (58) payload length: 64) 2001:4830:1600:850a:ba27:ebff:fe8a:75e8 > iad23s06-in-x03.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 1 14:01:56.316669 IP6 (hlim 58, next-header ICMPv6 (58) payload length: 64) iad23s06-in-x03.1e100.net > 2001:4830:1600:850a:ba27:ebff:fe8a:75e8: [icmp6 sum ok] ICMP6, echo reply, seq 1 14:01:56.316718 IP6 (hlim 57, next-header ICMPv6 (58) payload length: 64) iad23s06-in-x03.1e100.net > 2001:4830:1600:850a:ba27:ebff:fe8a:75e8: [icmp6 sum ok] ICMP6, echo reply, seq 1 And on the client: root@raspberrypi:~# tcpdump -i any -vv ip6 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 14:02:50.856317 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:4830:1600:850a:ba27:ebff:fe8a:75e8 > iad23s08-in-x06.1e100.net: [icmp6 sum ok] ICMP6, echo request, seq 1 14:02:55.861732 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ba27:ebff:fe8a:75e8 > fe80::a800:4ff:fe00:a04: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::a800:4ff:fe00:a04 source link-address option (1), length 8 (1): b8:27:eb:8a:75:e8 0x0000: b827 eb8a 75e8 14:02:55.862340 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::a800:4ff:fe00:a04 > fe80::ba27:ebff:fe8a:75e8: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::a800:4ff:fe00:a04, Flags [router, solicited] 14:03:00.871273 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::a800:4ff:fe00:a04 > fe80::ba27:ebff:fe8a:75e8: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::ba27:ebff:fe8a:75e8 source link-address option (1), length 8 (1): aa:00:04:00:0a:04 0x0000: aa00 0400 0a04 14:03:00.871651 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::ba27:ebff:fe8a:75e8 > fe80::a800:4ff:fe00:a04: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::ba27:ebff:fe8a:75e8, Flags [solicited] After browsing the forum, I found a similar question where the user was using the tunnel instead of the routed subnet, but that doesn't seem to be the case.
tunnel working, but subnet routing not working.
[us] Shadow Hawkins on Thursday, 16 October 2014 21:05:19
after reading another message in the forum, I solved the problem: bminton:~# ip -6 address add 2001:4830:1600:850a::/64 dev br0 bminton:~# ifconfig br0 br0 Link encap:Ethernet HWaddr aa:00:04:00:0a:04 inet addr:192.168.1.9 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link inet6 addr: 2001:4830:1600:850a::/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:302062 errors:0 dropped:0 overruns:0 frame:0 TX packets:335559 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:50713247 (48.3 MiB) TX bytes:238616807 (227.5 MiB) and on the client: pi@raspberrypi ~/src/hockeypuck $ ping6 -c 1 google.com PING google.com(iad23s08-in-x01.1e100.net) 56 data bytes 64 bytes from iad23s08-in-x01.1e100.net: icmp_seq=1 ttl=57 time=26.6 ms --- google.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 26.655/26.655/26.655/0.000 ms
tunnel working, but subnet routing not working.
[ch] Jeroen Massar SixXS Staff on Thursday, 16 October 2014 21:18:33
ip -6 address add 2001:4830:1600:850a::/64 dev br0
That is never correct. What you are doing there is adding a subnet anycast address For any host in that /64 it will be the local host where packets for that prefix are being routed to. You likely want to change that address into 2001:4830:1600:850a::1.
tunnel working, but subnet routing not working.
[us] Shadow Hawkins on Saturday, 18 October 2014 04:35:52
Jeroen Massar wrote:
> ip -6 address add 2001:4830:1600:850a::/64 dev br0 That is never correct. What you are doing there is adding a subnet anycast address For any host in that /64 it will be the local host where packets for that prefix are being routed to. You likely want to change that address into 2001:4830:1600:850a::1.
It didn't look like an anycast to me... all the final bits are zero, not one. Am I missing something?
tunnel working, but subnet routing not working.
[ch] Jeroen Massar SixXS Staff on Saturday, 18 October 2014 06:12:43
It didn't look like an anycast to me... all the final bits are zero, not one. Am I missing something?
The link pointing to the wikipedia article describing that the lowest address in a subnet is the subnet anycast address? :)
tunnel working, but subnet routing not working.
[us] Shadow Hawkins on Saturday, 18 October 2014 16:27:02
From the RFC:
The motivation for reserving the highest addresses from each subnet rather than the lowest addresses, is to avoid conflicting with some existing official and unofficial uses of the low-numbered addresses in a subnet. For example, these low-numbered addresses are often used for the ends of a point-to-point link, for tunnel endpoints, for manually configured unicast addresses when a hardware token is not available for the network interface, and even for manually con[qoufigured static addresses for the routers on a link.
from the Wikipedia article:
The lowest address within each subnet prefix (the interface identifier set to all zeroes) is reserved as the "subnet-router" anycast address.[1] Applications may use this address when talking to any one of the available routers, as packets sent to this address are delivered to just one router.
so that's probably what you were thinking. I believe I tried it with the ::1 but I may not have.
tunnel working, but subnet routing not working.
[ch] Jeroen Massar SixXS Staff on Saturday, 18 October 2014 16:39:55
Oops wrong RFC, that one is about special addresses in the subnet which are taken from the highest portion. This is the correct definition RFC2373 2.6.1 Required Anycast Address The Subnet-Router anycast address is predefined. Its format is as follows: | n bits | 128-n bits | +------------------------------------------------+----------------+ | subnet prefix | 00000000000000 | +------------------------------------------------+----------------+ The "subnet prefix" in an anycast address is the prefix which identifies a specific link. This anycast address is syntactically the same as a unicast address for an interface on the link with the interface identifier set to zero. Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets which they have interfaces. The subnet-router anycast address is intended to be used for applications where a node needs to communicate with one of a set of routers on a remote subnet. For example when a mobile host needs to communicate with one of the mobile agents on its "home" subnet.

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker