On 2009-11-10 12:06, William Herrin wrote:
> On Mon, Nov 9, 2009 at 5:35 PM, Brian E Carpenter
> <[email protected]> wrote:
>> 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
>>>> 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).
>> 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.)
>
> Hi Brian,
>
> I could swear we already did that. IIRC, that's why I grouped the
> ideas in Christian Vogt's Six/One Router with the map-encaps in the
> solutions summary document instead of splitting it off into its own
> section. Six/One Router obviously worked in a system strictly split
> between DFZ address space and user address space that distributed a
> map to the translators and detranslators but no one could demonstrate
> how it would work statelessly or without a strict split in light of
> the various DNS issues. I vaguely remember there was also a DNS server
> scope problem... ran afoul of some issues discussed in Paul Vixie's
> recent rant about "DNS lies."
Not disagreeing, my point is that we need a consensus version of
this in the (supporting text for the) recommendation.
Brian
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
