To address or NAT to address?

[Graham Klyne <GK at Dial.pipex.com>]

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
(GK at ACM.ORG)