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])
