On Wed, 26 Aug 2015, Henning Rogge wrote:
I wonder if HNCP routers should apply all addresses/prefixes to its
local interfaces, but should check for an existing route to the HNCP
router that announce the prefix before providing it via DHCP or RA to
hosts.
Let me rephrase what I think you're saying and tell me if I'm correct:
Your worry is that HNCP will determine neighbors and speak HNCP well
enough, but the routing protocol thinks the link is so bad, that it's
effectively has partitioned the network (because this was the only link
connecting the two (now) parts), and since there might be two uplinks, you
want HNCP to detect this partition, and only hand out ISP1 prefixes on the
side where ISP1 works, and only ISP2 prefixes, on the ISP2 side that
works. Also, if the network is partitioned, you want prefixes no longer
reachable to be sent corresponding RAs with zero lifetime etc, to make
hosts no longer use them for new connections?
So one way of doing this would be for hnetd to check if the ISPx prefix
(for instance /56) is in the routing table, and if it isn't, it should
not use it to put addresses on interface etc, and if it goes away (at
least for any duration of time), stop using it.
I don't remember seeing this discussed anywhere, but it might very well be
something that should be done. I would imagine HNCP is reacting on ISP1
WAN link going down and stopping to use the ISP1 prefix, but if there is a
break within the homenet (routing protocol wise), nothing is done as long
as HNCP is up.
One way of solving this would be to create fate-sharing between HNCP and
the routing protocol. Ie, HNCP wouldn't do anything unless there is a
valid routing protocol adjacency with that neighbor (=fate sharing).
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
