Deploying VLAN per user with IP unnumbered schema using Linux as access server we face with following problem: BIRD's kernel protocol does not learn routes with nexthop, that resolves trought another route (recursive routes). This is reproducable for both IPv4 and IPv6. ---------------------------------------------------------- While for IPv4 this has minimal impact, as typically customer gets its /32 ip address and entire LAN part of the customer connection uses addresses from RFC1918 and NAT. For IPv6 this becomes more complicated: - there is no NAT in such view as with IPv4, (ok) - as with IPv4 customer gets one IPv6 address on its WAN interface (ok) - customer gets additional IPv6 block with 64 long prefix for its LAN interface (fail) So for typical IPv6 deplyment with IP unnumbered schema we need: # ip -6 route add fd11::2/128 dev vlan10 proto static src fd11::1 # ip -6 route add fd22::/64 dev vlan10 via fd11::2 proto static src fd11::1 # birdc 'show route filter { if proto = kernel254 then accept; reject; }' BIRD 1.3.9 ready. fd11::2/128 dev qinq22.226 [kernel254 12:57] * (10) Last route MUST be advertised using dynamic routing protocol (BGP in our case). Example of such routes for both IPv4 and IPv6 is: ------------------------------------------------------------------ # ip -4 route add 192.168.1.2/32 dev vlan10 proto static src 192.168.1.1 # ip -4 route add 10.0.1.0/24 dev vlan10 via 192.168.1.1 proto static src 192.168.1.1 # birdc 'show route filter { if net = 10.0.1.0/24 then accept; reject; }' BIRD 1.3.9 ready. # ip -6 route add fd8e:579a:623c:826a::2/128 dev vlan10 proto static src fd8e:579a:623c:826a::1 # ip -6 route add fd8e:579a:623c:ffff::/64 dev vlan10 # birdc 'show route filter { if net = fd8e:579a:623c:ffff::/64 then accept; reject; }' Kernel protocol configuration --------------------------------------- protocol kernel kernel254 { persist no; scan time 120; learn yes; device routes no; kernel table ipt_main; import filter { # Import only 'static' routes if krt_source != ipp_static then reject; accept; }; export all; } Workaround ----------------- Use static protocol with routes not learned from kernel. protocol static static254 { route fd8e:579a:623c:ffff::/64 drop; } Any ideas about solution/other workarouns for this problem are welcome. -- SP5474-RIPE Sergey Popovich