[c-nsp] IPV6 RTBH on IOS

[Marco Marzetti]

Hello,

I am working on RTBH for IPv6 on IOS and i am stuck with the odd 
behavior of the OS.

Let's say that i have the following configuration on the router:

!
hostname R2
ipv6 unicast-routing
!
interface Gi1/0
  ipv6 address 2001::DB8::2/64
!
router bgp 64512
  bgp maxas-limit 30
  neighbor 2001:DB8::1 remote-as 64513
  !
  address-family ipv6
   neighbor 2001:DB8::1 activate
   neighbor 2001:DB8::1 send-community
   neighbor 2001:DB8::1 prefix-list AS64513_IN in
   neighbor 2001:DB8::1 route-map CUST_IN_V6 in
  exit-address-family
!
ipv6 route 100::/64 Null0
!
route-map CUST_IN_V6 permit 10
  match community BLACKHOLE
  set community no-export additive
  set local-preference 200
  set ipv6 next-hop 100::1
!
route-map CUST_IN_V6 permit 20
!
ipv6 prefix-list AS64513_IN permit 2001:db8:100::/48 le 128
!



Now let's say that R1 (the peer) is sending the following prefixes to R2 
via eBGP marked with community BLACKHOLE:
  - 2001:DB8:100::/48
  - 2001:DB8:100::1/128



The prefixes are received by R2 and next-hop is set to 100::1 as 
expected (because of the community)
R2#show bgp ipv6 unicast
BGP table version is 17, local router ID is 192.0.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - 
internal,
               r RIB-failure, S Stale, m multipath, b backup-path, f 
RT-Filter,
               x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

      Network          Next Hop            Metric LocPrf Weight Path
  *>  2001:DB8:100::/48
                        100::1                 100    200      0 64513 i
  *>  2001:DB8:100::1/128
                        100::1                 100    200      0 64513 ?


But, even if 100::1 is routed to Null0, the routing table shows that the 
next-hop for the eBGP prefixes is the link-local address of R1 (the 
peering router)
R2#show ipv6 route
IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
        B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
        I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
        EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - 
Destination
        NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
        OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l 
- LISP
S   100::/64 [1/0]
      via Null0, directly connected
C   2001:DB8::/64 [0/0]
      via GigabitEthernet1/0, directly connected
L   2001:DB8::2/128 [0/0]
      via GigabitEthernet1/0, receive
B   2001:DB8:100::/48 [20/100]
      via FE80::C801:37FF:FEB0:1C, GigabitEthernet1/0
B   2001:DB8:100::1/128 [20/100]
      via FE80::C801:37FF:FEB0:1C, GigabitEthernet1/0
L   FF00::/8 [0/0]
      via Null0, receive



And the same does FIB:
R2#show ipv6 cef 2001:DB8:100::1/128
2001:DB8:100::1/128
   nexthop FE80::C801:37FF:FEB0:1C GigabitEthernet1/0
R2#



So The prefix is reachable
R2#ping 2001:DB8:100::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:100::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms
R2#



The outcomes is that I cannot null-route traffic destined to a neighbor 
on the same router of the source of the attack.

Now, i understand that RFC2545 permits a router to use link-local for 
eBGP.
It precisely says:
" The link-local address shall be included in the Next Hop field if and
only if the BGP speaker shares a common subnet with the entity
identified by the global IPv6 address carried in the Network Address
of Next Hop field and the peer the route is being advertised to. "

But this is "less than optimal" and i wonder if there's a 
trick/kludge/whatever to amend that.
For instance IOS-XR is smart enough to stick to the specified next-hop 
if the use "set next-hop" within a route-policy.

So far the only thing that have come to my mind was to set ebgp-multihop 
(in the wrong hope that would have forced IOS to consider the neighbor 
as non-connected), but it didn't work.

And you can't even forward the prefixes to another router/exabgp and 
somehow receive them back because you'll end up in overwriting the 
originals.

Do you have any ideas?

-- 
Marco