Re: [ga] Re: and if we addressed the problem at its real root? (was Re: Names Council Resolution on Reform)
----- Original Message -----
From: "Dassa" <email@example.com>
Sent: Monday, August 05, 2002 3:18 PM
Subject: RE: [ga] Re: and if we addressed the problem at its real root? (was
Re: Names Council Resolution on Reform)
> |> -----Original Message-----
> |> From: firstname.lastname@example.org [mailto:email@example.com]
> |> On Behalf Of todd glassey
> |> Sent: Tuesday, August 06, 2002 2:37 AM
> |> To: Vittorio Bertola; Sandy Harris; J-F C. (Jefsey) Morfin
> |> Cc: firstname.lastname@example.org; vint cerf
> |> Subject: [ga] Re: and if we addressed the problem at its
> |> real root? (was Re: Names Council Resolution on Reform)
> |> However - A simple solution based on NAT and Search
> |> Engines, which did not exist when DNS was formulated or
> |> evolved, is easily fielded. And if they ( the Search Engines
> |> and NAT) had existed at the time that DNS was setup, then
> |> its my opinion that DNS would look much different. instead
> |> of like the stand-alone embedded address resolution system
> |> it is today.
> You might like to study NAT and the problems that exist with it's use
> before you go touting it off as part of any solution involving DNS.
I have a better one. I have a set of gateways up, and running in my lab
with a couple of WAN-channel simulators on it; The system ha several
load generating systems ad it emulates essentially a tunnel-forwarded
infrastructure at an OC3 throughput without any real issue. In fact after
some more work I will be filing this with the IETF as a practical
endorsement of the Internet-II architetcure.
The issues come into managing NAT gateways and the pain involved, not in
whether the tunnel headers can be effectively rewritten and tracked and that
is identical to the way DNS was managed 10 years ago. Just give it a year or
two and tools for managing the NAT topology and translations will also be
> breaks a lot of DNS related communications at the application level.
...but since this is because those technologies were never built to use a
NAT client, embedding a NAT infrastructure that looks just like a DNS
calling model to the Client cures most of these breakages, and for those
that it doesn't, they are easily rewritten... and hence - this also becomes
no problem. Personally my take is that the developers will rebuild them with
a NAT gateway infrastructure too!
Don't let simple issues stop you from the bigger achievement. There is
nothing technical that cannot be accomplished - its all a matter of the cost
of ownership and after some period of evolution, the NAT model will work
just fine... Whether you personally buy in or not.
Take care -
> Darryl (Dassa) Lynch.
> This message was passed to you via the email@example.com list.
> Send mail to firstname.lastname@example.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html
This message was passed to you via the email@example.com list.
Send mail to firstname.lastname@example.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html