[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Source address selection insufficient?
On 8-mrt-04, at 20:13, Erik Nordmark wrote:
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.
If you need that level of address agility underneath the transport
you need to modify the hosts at both ends.
Any level of address agility greater than 0 requires this.
Once you modify the hosts at both ends why not also provide connection
Sure. But how does this relate to the problem at hand currently?
(There seems to be a large class of connection rehoming mechanisms
that can live with source locator rewriting instead of ingress
but that's the subject of a different email.)
Unfortunately we still have to deal with the packets that can't be
rewritten and I'm not sure if expecting all routers to be upgraded to
support this is reasonable.
I agree that source based routing and relaxed filtering both work.
What is tricky is the middle between the small and the large; too small
a site to be able to convince the ISPs to relax ingress filtering
and too large a site for source based routing to be trivial.
For mid-sized sites the "use a default only" policy wouldn't be ideal,
but it should at least make sure there is always a working path. For
small sites the default-only policy has the disadvantage that only one
external link will be used for outgoing traffic, but in a site that has
several routers and subnets, different routers/subnets could use
different external connections so rudimentary load balancing would
The main problem of this approach is the fact that unfortunate source
address choices lead to blocked packets/sessions because of ingress
filtering. However, mechanisms to overcome this problem can largely be
implemented unilaterally, especially for outgoing sessions.