[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: failure detection
Paul Jakma wrote:
But SAS is inherently tied in with routing. Let it do its magic.
According to which RFC? ;-)
The source address selection is influenced by which interface is used (I
think RFC 3484 says that), but I know of no text in an RFC that ties the
source address selection to the first hop router being used.
Ie, you mean the case of:
Where the SOHO router is just a normal SOHO "router" (ie a wee DSL
router) doing ye normal forward-by-destination, the host is shim6'ing?
You want to cover the case where the router is 'dumb' and still have
things work, regardless of which ISP it forwards to?
Things that come to mind:
1. A dual connection SOHO DSL router likely would have to support
source-prefix routing anyway, to allow non-shim6 IP to work
Yes, draft-huitema already points this out.
The other possibility for SOHO:
In which case the /host/ must pick which router to send to. In which
case everything is under its control - shim6 can easily leave source
unspecified. IP output then does SAS using routing information as
normal, picks a prefix and uses a source route to send it to the right
But here is where the out-of-the-box behavior of the hosts doesn't match
your expectations. The host will pick a source address that is
appropriate for the network interface, but apart from that there isn't
any correlation between the source address and the 1st hop router it is
But we also need to capture the slightly larger case where there might
be a handful of routers in the site, thus the host might not be directly
attached to the border routers.
draft-huitema suggests different approaches for doing this, and the
simplest one for multiple border routers is to have the border routers
setup tunnels between themselves so that they can pass packets to an
exit that is appropriate for the source address. In the case of the
border routers being on the same link, they can discover each other
automatically, but manual configuration might be needed when such
discovery isn't possible.
This could be combined with some automatic protocol by which the border
routers can inform the interior routers of which prefixes have failed,
and the interior routers can advertise that in their RAs. (Something
like an extension to RFC 2894 "router renumbering protocol" could be
made to work.)
However, such a protocol requires some security configuration, otherwise
anybody on the Internet could use this to reconfigure the RAs your
interior routers send.
Thus I don't think we can assume that some such, not yet invented
mechanism for propagating information from border routers to interior
routers, exist. This leads me to conclude that we can't assume that
source address selection can solve the ingress filtering interaction.
In both the single and multiple border router cases, the host will need
to pick a source address before the packet leaves the host. The
source-based routing in the border router(s) ensure that when both paths
are working, the packet will leave on an exit where it doesn't get
However, when there is a failure then presumably the border routers will
send packets up the exits they know are working; in any case, after a
failure towards ISP1 packets with the source address from ISP1's prefix
will not make it through (either they are sent out the exit to ISP1 and
experience the failure, or they are sent out the exit to ISP2 and are
ingress filtered away).
As a result, the host must be prepared to try sending packets with
different source addresses.
Well, I've run an IPv4 site with PA prefixes and ISPs which did ingress
filtering, unspecified addresses + source routing works nicely..
Did it work without any manual configuration of the host?
I think that is the crux of the matter; we can automate this for the
single SOHO router case by adding a "failed" notion to the prefixes in
the RAs. But slightly larger networks would require a secure way for
border routers to inform interior routers, which I think requires
configuring some security somewhere.