[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 protocols
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
rehoming?

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 filtering,
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 still happen.

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.