[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Source address selection insufficient?
On 3-mrt-04, at 6:29, Erik Nordmark wrote:
/-- ( A ) ---( ) --- ( C ) --\
X (site X) ( IPv6 ) (Site Y) Y
\-- ( B ) ---( ) --- ( D ) --/
This has 4 locator pairs:
Ugh, is it just me or is the A:X notation (rather than X:A) very
The set of locator pairs that work when sending out from site X
might be A:X-C:Y and B:X-D:Y
but the set of locator pairs that work when sending from site Y might
be the other two: A:X-D:Y and B:X-C:Y.
What you are saying is that X wants to reach Y over either the path
A->C (1) or the path B->D (2), while in the other direction the path is
D->A (3) or C->B (4). The address permutations in the packets are then
as follows (!I means ingress filtered):
address pair X->Y direction Y->X direction
A/C (1) (3) !I
A/D (2) !I (3)
B/C (1) !I (4)
B/D (2) (4) !I
Thus the intersection of the two ingress filtering constraints is the
This means our address agility mechanisms must support packet flow
where the src/dst addresses in packets in one direction don't
correspond to the src/dst addresses in opposite direction. In the above
example X may send out packets with A/C while Y responds with packets
Unfortunately this still breaks all non-address agile protocols, most
notably current TCP and UDP but also many proposed solutions in their
compatible or negotiation phase.
This can happen due to normal routing as far as I can tell.
Am I missing something?
The only way this can happen during "normal" routing is when the two
destination addresses for a correspondent are routed differently. When
this isn't the case (for instance, when a default route is in effect)
the problem should only occur when there are outages but current TCP
and UDP are dead in the water in that case anyway. We have to look at
the possibilities of setting up new sessions (with a multihoming
solution in effect) under these circumstances, though.
I guess this means that trying different source addresses CAN be
sufficient but it's far from ideal because it can't live together with
existing traffic engineering techniques.
But maybe the problem isn't as bad as it would seem at first glance:
for small sites, source address based routing is fairly trivial and it
provides decent overal traffic engineering (although individual streams
may suffer) while only larger sites are going to run BGP in order to do
traditional traffic engineering anyway, and presumably, those sites are
in the position to get ingress filtering relaxed. (We need to document
this very well at some point because this is still imcompatible with
ingress filtering further downstream.)