> At 09:15 30/11/99 -0500, Daniel Senie wrote:
>
> >> In any event, I've always personally been of the opinion that
> >> if applications don't work in the face of NAT, then the
> >> applications themselves are functionally deficient and should be
> >> fixed. :-)
> >
> >Indeed. While some in the IETF have stomped their feet and railed about
> >how bad NAT is architecturally (something I suspect most folks concede)
> >they've somehow believed it would be possible to offer a better solution
> >and get NAT eliminated before it's widely deployed. Reality: it's
> >extremely widely deployed, and must be taken into consideration when
> >designing protocols. Those, like Real, who find ways to make their
> >protocols work with NAT clearly will do better than those who do not.
>
> [...]
> >We are at a crossroads where architectural purity has intersected
> >operational reality.
>
> Some similar thoughts have been stirring in my sluggish brain...
>
> It seems to me that we may be able to recapture some aspects of end-to-end
> transparency at the application level if addressing issues are focused on
> host FQDNs, rather than IP addresses.
>
> - Application protocols that transfer addressing information as FQDNs
> rather than IP addresses don't get messed up by NATs.
>
> - FQDNs are (or can be) relatively stable over time, even if the IP address
> to which it refers may change.
>
> - FQDNs form an "address space" that can, for practical purposes, grow
> indefinitely.
>
> I don't claim this is a solution to all problems, just suggesting that
> application protocol design has a part to play.
>
> #g
>
> ------------
> Graham Klyne
> ([EMAIL PROTECTED])
>
FQDN's cause problems with security. DNS is not secure and it
is desireable to avoid contacting the DNS to establish whether or
not a given set of credentials are reliable for a given connection.
Authentication information is frequently encrypted and it is not
possible nor desireable for the NAT to be able to much with its
contents.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
