ipv6 next-hop link-local

[Mark Smith]

Hi,

On Sun, 20 Feb 2011 15:17:01 -0800
"George Bonser" <gbonser at seven.com> wrote:

> > Specifically the topic at hand, using link-locals at an IXP, has some
> > benefits - and at the same time, serious operational drawbacks, like
> > "monitoring your eBGP peers in your NMS by IPv6 address" - now which
> of
> > the two IXPs I'm connected to is the fe80::ab:cd neighbour that just
> > went down?
> 
> And that is really the problem.  Link locals can get very confusing when
> a machine, even a host, has several interfaces.  If I have several vlan
> interfaces on a host and I have a packet to send to fe80::ab:cd ... on
> which interface will I find that neighbor?
> 
> Looking right now at a box in a data center.  Two different vlan
> interfaces on the same box.  One is:
> 
> inet6 addr: fe80::221:28ff:fe57:3412/64
> 
> and the other is:
> 
> inet6 addr: fe80::221:28ff:fe57:3412/64
> 
> Same netmask, same IP address, two different networks.  On which one
> will I find fe80:ab:cd?  I need to do ND on all of them until I find it,
> I suppose.
> 
> I have some machines with a half-dozen interfaces on them.  If I tried
> to use link-locals only, the kernel would probably be in Keystone Kops
> mode trying to figure out where to send stuff.
> 

In that case you (or the application) need to specify the interface.
For link local unicast or multicast traffic, the ifindex of the
interface to use is supplied in the sin6_scope_id field of the
sockaddr_in6 structure, passed to connect() or bind().

I do agree though, the ambiguity of link locals can be an issue, and
that is the trade off with using them. So the benefits of link locals
are (a) they're always there, regardless of whether global or ULA
addresses are also available or being deprecated, (b) they have a well
known prefix distinct from other types of addresses, and (c) they're not
reachable from off-link destinations. The drawback is their ambiguity on
multi-homed hosts or routers.

Fundamentally, for non-link local addresses, the subnet number is used
to distinguish the outbound/inbound interface when the prefix is the
same. I've thought it could be useful to have link locals with
properties similar to ULAs - there is a randomly selected link-local
subnet/link identifier (probably using all of the bits between
fe80::/10 and /64, with all zeros reserved for existing link local
interoperability), chosen by the first node attached to the link. When
subsequent nodes attach to the link they query see if a link-local
subnet has already been chosen, and use that for their link-local
addresses. If not, they choose one. This first attached node is the
"link local subnet seed node", similar to how Appletalk seed routers
worked. The valid and preferred lifetimes of these unique link locals
would be quite large (the default RFC4861 lifetimes of 1 week and 4
weeks might be fine), and if the original seed node disappeared,
another one could take over as the seed for the chosen subnet number. I
think this would be a reasonable way to get rid of the ambiguity issue,
while still retaining the other link local benefits.

Regards,
Mark.


> If I were making the rules, link local would only mean "I don't have
> enough information to build a 'real' IP address so I am using this
> placeholder in the meantime.  Once a "real" address is configured, the
> link-local would be dropped. 
> 
> Bottom line is that link local is fine where you have one interface.  It
> gets to be a pain when you have many.
> 
>