subnet prefix length > 64 breaks IPv6?

Owen DeLong owen at delong.com
Tue Jan 3 17:45:03 CST 2012


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 at 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




More information about the NANOG mailing list