[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Source address selection insufficient?
I think that this is getting more complex than necessary.
It is true that routing is frequently asymmetric.
However, that is a very different statement from saying that connectivity
is asymettric. While the routing path among ISPs for a given address pair
(src, dst) may be different in the forward and reverse direction, it would
take a very strange situation for a pair to work one way, and not when
reversed. It would take an even stranger situation for there to be no pair
that worked in both directions.
As such, I think we ought to be able to assume that there exists (at any
given time) an address pair that is useable in both directions. (The
packets using that pair may not take the same path forward and backward,
but will use the same ingress / egress points on each end.
Situations where the connectivitiy / path changes are so fast that you can
not find such a pair probably need very different techniques (just as MANET
is looking for different techniques than MobileIP.)
Joel M. Halpern
At 01:37 PM 3/6/2004 +0100, Iljitsch van Beijnum wrote:
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 containing D/B.
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.)