On 21/07/2016 02:34, David Lamparter wrote:
> 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 <equi...@diac24.net> 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.)
Is this any worse than if the single default router in a traditional host
goes away, which will break all off-link packets until something happens?
I'm not saying it isn't a problem, but it doesn't sound like it's a new
problem that applies only in the multihomed case.
Brian
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
