On 2009-11-10 04:43, William Herrin wrote:
> On Mon, Nov 9, 2009 at 10:42 AM, William Herrin <[email protected]> wrote:
>> On Mon, Nov 9, 2009 at 3:56 AM, Brian E Carpenter
>> <[email protected]> wrote:
>>> On 2009-11-09 21:42, Darrel Lewis (darlewis) wrote:
>>>>> An argument has been made, and I don't intend to endorse it, that
>>>>> stateless NAT66 would be a fine solution to the problems of
>>>> you have the entire route-scaling problem in a nutshell.
>>> That's if you want session survivability. If you sacrifice
>>> that requirement, the outer address can be PA. That's probably the
>>> strongest argument against this as a way forward, if you get over
>>> NAT hatred.
>> Which is all well and good in the client case, but in the server case
>> requires both semantics in the DNS system which are not compatible
>> with current practice (i.e. applications must be aware of and actually
>> use the TTL) and try-next-address semantics which are different from
>> the current sockets API defaults (should try the next address with the
>> first SYN retransmit but shouldn't give up on attempts to any address
>> until one of them succeeds).
>
> Correction: the latter is a client issue, so it's not all well and
> good in the client case either.
Without being sure that I agree with you completely, Bill, I think
presenting a complete argument about these issues is very much
part of the architectural analysis that we need to back up
the final recommendation. We need an analysis for each of the
major classes of solution, and stateless NAT66 is one of them.
(NAT44 is hopelessly constrained by history and address space,
so doesn't seem to be a serious option anyway, IMHO.)
Brian
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
