On Dec 27, 2011, at 3:28 PM, Glen Kent wrote:
It seems ISIS and OSPFv3 use the link local next-hop in their route advertisements.
We discussed that SLAAC doesnt work with prefixes > 64 on the ethernet medium (which i believe is quite, if not most, prevalent). If thats the case then how are operators who assign netmasks > 64 use ISIS and OSPF, since these protocols will use the link local address?
The global unicast prefix length is independent of the link local prefix length. Technically, link local is fe80::/10, though many implementations erroneously treat it as fe80::/64. In most cases, since the 54 bits between fe80 and the IID are almost always 0, this error has no impact.
I had assumed that nodes derive their link local address from the Route Advertisements. They derive their least significant 64 bytes from their MACs and the most significant 64 from the prefix announced in the RAs.
No, nodes derive their link local address from the reserved prefix fe80::/10 and their EUI-64 IID based on their MAC address. They then use that link local address to send out an RS message in order to get global unicast prefixes from the RAs received in response. Owen
Glen
On Tue, Dec 27, 2011 at 6:25 AM, Glen Kent <glen.kent@gmail.com> wrote:
Sven,
also various bgp implementations will send the autoconfigure crap ip as the next-hop instead of the session ip, resulting in all kinds of crap in your route table (if not fixed with nasty hacks on your end ;) which doesn't exactly make it easy to figure out which one belongs to which peer all the more reason not to use that autoconfigure crap ;)
As per RFC 2545 BGP announces a global address as the next-hop. Its only in one particular case that it advertises both global and link local addresses.
So, i guess, BGP is not broken.
Its only RIPng afaik that mandates using a link local address.
Glen