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:
A:X-C:Y
A:X-D:Y
B:X-C:Y
B:X-D:Y
Ugh, is it just me or is the A:X notation (rather than X:A) very
counter-intuitive?
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
empty set.
:-(
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.)