On 2009-04-09 06:50, Dan Wing wrote:
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]
>> On Behalf Of Christian Huitema
>> Sent: Monday, April 06, 2009 9:17 AM
>> To: Scott Brim
>> Cc: NAT66
>> Subject: Re: [nat66] RSIP and NAT66
>>
>>> Excerpts from Christian Huitema on Sun, Apr 05, 2009
>>> 10:10:37PM -0700:
>>>> My point is that if we want site multi-homing, we cannot
>>>> do without
>>>> engineering this routing symmetry. If we leave it to chance, then
>>>> future network administrators will observe maddening
>>>> failure modes,
>>>> and we will have done them a great disservice. Just sticking NAT
>>>> devices at various network edges is, for me, equivalent to leaving
>>>> it to chance.
>>> What failure modes? IP routing will be as deterministic
>>> (ahem) as it
>>> is now. E2E session continuity is at risk, but session
>>> continuity in
>>> the face of massive routing changes is not, as far as I know, a goal
>>> in NAT66. The only truly difficult scenario is the one Fred Baker
>>> described where traffic could yoyo back and forth. I could
>>> see using
>>> routing headers.
>> The failure mode happens in the 4-ways criss-cross scenario,
>> which I described in a previous message:
>> <http://www.ietf.org/mail-archive/web/nat66/current/msg00200.html>.
>
> The first thing that struck me is that if the hosts in a network
> are only doing client-initiated connections -- for example because
> of a separate security policy -- that network avoids the 4-ways
> criss-cross complication. That said, I believe I have a solution:
>
> The 4-way criss-cross should be solvable by providing two ULAs to
> every host -- one ULA for each NAT66 egress. The host would then
> reply (send a TCP SYN+ACK) using the same ULA as the incoming
> request (TCP SYN). The enterprise network could do source-based
> routing to steer the reply traffic towards the NAT66 associated
> with the ULA, preventing a criss-cross. This is similar
> to Dave Thaler's SAF approach using virtual interfaces he
> presented in 6AI.
>
> This retains address independance but it does complicate the
> enterprise's network because each host gets "n" ULAs, where
> "n" is the number of ISPs.
Which would destroy one of the nice points about ULAs, i.e. no
need to touch them when you add or drop an ISP.
It seems to me that we need to solve the exit selection problem,
and in a broader context than just NAT66.
Brian
Brian
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
