On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote:
> On 21/07/2016 01:13, Lorenzo Colitti wrote:
> > On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter <[email protected]> wrote:
> > 
> >> - it's a bit unclear how an address/prefix's "source" next-hop is kept
> >>   in association.  The simplistic approach of adding a "PA source ipv6
> >>   address" for each of a host's configured addresses falls flat when
> >>   more than 1 router advertises the same prefix, so I implemented it as
> >>   a list -- however, my hack never removes entries off that.  It should
> >>   possibly have a copy of the PA's valid time?
> >>
> > 
> > The way I thought of doing this would be to alternatively/additionally keep
> > a pointer from the default router that announced a given prefix (which does
> > have the link-local address of the router) to each address that was
> > configured from that prefix. That way, when an address goes away you can
> > scan the FIB and find another router to associate with that prefix.
> > 
> > As for lifetimes expiring, you would need to have somewhere to keep dummy
> > zero-lifetime default routes. It might be possible to do this in the FIB
> > itself by adding a special entry that doesn't ever match anything, or has
> > an infinite metric, or a different type...
> 
> Please tell us ASAP if there is anything we should add to
> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2
> or thereabouts.

I do see some trouble in use-cases where more than one actual router
(actual = not counting extra link-local addresses on the same router) is
present on a link, advertising the same prefix to hosts.  (This is
reasonably likely in homenet scenarios, maybe less in enterprise.)

If the host only tracks a maximum of one RA source LL for a
prefix/address, but the router with that LL happens to not be the one
actually used (e.g. preference, router gone, more specific route from
RIO, whatever else) then the functionality is lost.  It's particularly
bad if the one RA source LL is the one prefix was first seen from (and
then, worst-case, never updated).

(The neccessary precondition / assumption being broken there is that the
test "was prefix X announced by router Y" doesn't report false
negatives.  I haven't applied brain to false positives yet.)


-David

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to