On Jun 10, 2011, at 3:37 AM, Iljitsch van Beijnum wrote:
On 10 jun 2011, at 12:27, Iljitsch van Beijnum wrote:
RFC 4760:
An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute.
Sorry, this is stupid. I should have read beyond "LOCAL".
So it depends a little, but I still don't see any implementation leeway in RFC 2545:
3. Constructing the Next Hop field
A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop.
The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field.
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.
In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16).
I read that as: If the peer is directly connected and the next hop is local, there is the option of sending both the global unicast address and the link local address for the directly connected link. In all other cases, you must send only the global unicast address of the next hop. That sounds like not using link local in the general case and having it available as an option in the directly adjacent case. Owen