On 2009-03-23 03:10, Scott Brim wrote:
> Brian E Carpenter allegedly wrote on 03 21 2009 4:07 PM:
>> So instead, you run NAT at every ISP connection. Your internal users get
>> NATted to an ISP prefix at whichever exit point their traffic happens
>> to reach, which automatically causes their return traffic to come through
>> the same ISP. That exit point is locally chosen by the local routing setup.
>> You don't need any worldwide coordination of the BGP4 advertisements,
>> because there aren't any expect the ISP's normal ones. Also, traffic
>> flows inside your network are localised, since traffic goes out and
>> returns through a (reasonably) local gateway.
>>
>> When one of these NATs goes down, active connections will be lost,
>> but IGP routing will switch users automatically to a different NAT
>> when they retry.
>
> If you allow your hosts to use multiple connection points into the
> Internet, and external routing changes so that the packets they send go
> out different connection points, their apparent source address can
> change.
True. I should have said 'when one of these NATs go down, or routing changes
such that a user's exit point changes, active connections will be lost.'
> One of the requirements for effective use of NAT and
> multihoming is that your hosts' peers need to handle this (via
> Multipath, HIP, MIP, SCTP or whatever). That is, you can't allow your
> hosts to use multiple connection points until everyone _else_ they talk
> to has been upgraded. How will you know when that is?
You won't. Active connections will fail in the scenario I described.
That is inconsistent with the goals defined in RFC3582, but it is
current reality in some places, and applications and/or users have to
deal with it.
(I never said I liked NAT, did I?)
Brian
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf