IPV6 BGP and Neighbor Discovery

[ldpaynejr2]

My understanding of IPv6 may not be accurate, so if there are any incorrect statements, please correct them.

We have a requirement that prohibits FE80::/10 addresses from passing from end sites to the provider network.  FE80::/10 are the IPv6 link-local addresses.  Since link-local addresses are required Neighbor Discovery Protocol, this blocks those operations that are part of it. 

The sites use BGP with the provider network, so can IPv6 BGP work without link-local addresses?  Is Neighbor Discovery necessary for reachability between BGP peers?

[Marcin Latosiewicz]

(had to edit this post so it's a bit clearer, I indicated ff00::/8 as link-local adress, while in fact it's mcast)          

Link-local addresses are not routed, and meant to stay within same L2 domain (VLAN,p2p link,...)

Looking at routing from IOS router:

Spoke2#show ipv6 route FE80::A8BB:CDFF:FE00:6524
Routing entry for FE80::/10
  Known via "connected", distance 0, metric 0, type receive
  Route count is 1/1, share count 0
  Routing paths:
    receive via Null0
      Last updated 00:12:33 ago
Spoke2#show ipv6 cef FE80::A8BD:CDFF:FE00:6524
FE80::/10
  receive for Null0

While

Spoke2#show ipv6 interface | i FF:FE
  IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:6500
  IPv6 is tentative, link-local address is FE80::A8BB:CCFF:FE00:6500 [TEN]
  IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:6500

You do not need to worry about propagating your link local addressing elsewhere.

Message was edited by: Marcin Latosiewicz, typos, clarity

[ldpaynejr2]

Yes, I agree that the requirement is not necessary since link-local addresses aren't propagated; however, it's a requirement that my organization still has to meet.  We are required to add these two statements to our router at the perimeter of our network -

deny ipv6 fe80::/10 any log

deny ipv6 any fe80::/10 log

They have to be part of an ACL that is placed on the links to our ISP.

From what I've read, this would break Neighbor Discovery Protocol on those links, so the router would not be able to resolve the layer 2 address of the provider's router, and traffic doesn't get sent. 

[Harold Ritter]

Hi Larry,

I am not sure I understand the requirement. As you mentioned, LL addresses are used for neighbor discovery (ND). The only way around it would be to have static neighbors.

ipv6 neighbor 2001:db8::1 Ethetnet0/0

This would be equivalent to using static ARP entries.

Regards

[ldpaynejr2]

Thank you.  I think this is something that we can use.

The problem is that we have an explicit requirement to block all link-local addresses, and I'm trying to figure out what that breaks.  It breaks ND, but does that break everything since one of the functions of ND is equivalent to ARP (or am I wrong on that)?

[Marcin Latosiewicz]

(The below messgage is just to address the concern whether blocking LL breaks all ND, it does not tie into rest of BGP configuration) 

Larry,

Speaking of ND only... RFC (4861) only mandates that source IP is assigned address

http://tools.ietf.org/html/rfc4861#section-4.3

It does not mandate link-local, I have not read the updated RFC.

I did a simple test with two devices with assigned IP addresses.

Spoke2#ping vrf VRF 2001:db8::1 re 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001:DB8::1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 9/9/9 ms
Spoke2#
*Nov 27 13:27:43.246: IPv6-Fwd: Destination lookup for 2001:DB8::1 : i/f=Ethernet0/0, nexthop=2001:DB8::1
*Nov 27 13:27:43.246: IPv6-Fwd: SAS picked source 2001:DB8::FFFF for 2001:DB8::1 (Ethernet0/0)
*Nov 27 13:27:43.246: ICMPv6: Sent echo request, Src=2001:DB8::FFFF, Dst=2001:DB8::1
*Nov 27 13:27:43.246: IPV6: source 2001:DB8::FFFF (local)
*Nov 27 13:27:43.246:       dest 2001:DB8::1 (Ethernet0/0)
*Nov 27 13:27:43.246:       traffic class 0, flow 0x0, len 100+0, prot 58, hops 64, originating
*Nov 27 13:27:43.246: IPv6-Fwd: Created tmp mtu cache entry for 2001:DB8::FFFF 2001:DB8::1 1E000001
*Nov 27 13:27:43.246: IPv6-Fwd: Encapsulation postponed, performing resolution
*Nov 27 13:27:43.250: ICMPv6: Sent N-Solicit, Src=2001:DB8::FFFF, Dst=FF02::1:FF00:1
*Nov 27 13:27:43.250: IPV6: source 2001:DB8::FFFF (local)
*Nov 27 13:27:43.250:       dest FF02::1:FF00:1 (Ethernet0/0)
*Nov 27 13:27:43.250:       traffic class 224, flow 0x0, len 72+0, prot 58, hops 255, originating
*Nov 27 13:27:43.250: IPv6-Fwd: Sending on Ethernet0/0
*Nov 27 13:27:43.255: IPv6-Fwd: Destination lookup for 2001:DB8::FFFF : Local, i/f=Ethernet0/0, nexthop=2001:DB8::FFFF
*Nov 27 13:27:43.255: IPV6: source 2001:DB8::1 (Ethernet0/0)
*Nov 27 13:27:43.255:       dest 2001:DB8::FFFF (Ethernet0/0)
Spoke2#
*Nov 27 13:27:43.255:       traffic class 224, flow 0x0, len 72+14, prot 58, hops 255, forward to ulp
*Nov 27 13:27:43.255: ICMPv6: Received N-Advert, Src=2001:DB8::1, Dst=2001:DB8::FFFF
*Nov 27 13:27:43.255: IPv6-Fwd: Sending on Ethernet0/0
*Nov 27 13:27:43.255: IPv6-Fwd: Destination lookup for 2001:DB8::FFFF : Local, i/f=Ethernet0/0, nexthop=2001:DB8::FFFF
*Nov 27 13:27:43.255: IPV6: source 2001:DB8::1 (Ethernet0/0)
*Nov 27 13:27:43.255:       dest 2001:DB8::FFFF (Ethernet0/0)
*Nov 27 13:27:43.255:       traffic class 0, flow 0x0, len 100+14, prot 58, hops 64, forward to ulp
*Nov 27 13:27:43.255: ICMPv6: Received echo reply, Src=2001:DB8::1, Dst=2001:DB8::FFFF

M.

Message was edited by: Marcin Latosiewicz, edited for clarity.

[Harold Ritter]

Hi Marcin,

Good point about the BGP session.

Regards

[Harold Ritter]

Hi Larry,

The ACL you suggested would break the neighbor discovery (equivalent of ARP) and the duplicate address detection (DAD). The static ipv6 neighbor configuration would alleviate the need for the ND. DAD is not really required is you make sure that the addresses (yours and your SPs) are unique.

Regards

[Harold Ritter]

Hi Larry,

On a second thought. Although connectivity between the two routers will work without link-local addresses, the BGP prefixes will be installed in the RIB with the LLA as the next hop and connectivity will be broken. This is the default  behavior for a directly connected eBGP connection. One way to change that is to configure the session to be multihop (neighbor ebgp-multihop).

Regards

[Marcin Latosiewicz]

Do demonstrate Harold's point.

IPv6 BGP update without ebgp-multihop.

*Nov 27 18:06:15.484: BGP(1): 2001:DB8:2::1 rcvd UPDATE w/ attr: nexthop 2001:DB8:2::1 (FE80::A8BB:CCFF:FE00:C801), origin i, metric 0, merged path 65000, AS_PATH

after adding ebgp-multihop:

*Nov 27 18:09:34.036: BGP(1): 2001:DB8:2::1 rcvd UPDATE w/ attr: nexthop 2001:DB8:2::1, origin i, metric 0, merged path 65000, AS_PATH