On Fri, 5 May 2006 02:18:12 -0400 (EDT), der Mouse
<mouse@Rodents.Montreal.QC.CA> wrote:

> > NATs proliferated despite the IETF; the RFCs were to document what
> > was out there.  To be sure, the IETF is philosophically opposed to
> > NATs.
> 
> Not very, in practice; they've published things like RFC 3235, and I
> see no push to eliminate the various kludges that make NAT work (for
> sufficiently loose values of "work", of course).  Perhaps I'm just
> missing it, but it seems to me that if anything, being NAT-friendly is
> considered a good thing in protocol design these days.
> 
I agree, but that doesn't contradict my earlier statement.  Like it or
not, NATs are very real.  Some classes of protocol that do not function
through NATs simply will not be deployed.  Alternatively, they'll be
deployed with (often poorly-designed0 vendor-proprietary extensions that
don't interoperate.  

I'll give just one example; there are many more.  Most business-grade
hotels in the US provide high-speed Internet.  It's rare to find global
addresses in use in such places, but business travelers are major users of
IPsec VPNs.  Does the IETF (a) make IPsec NAT-compatible (for VPNs; there
are deeper issues for non-VPN uses of IPsec); or (b) write off that market
and by extension much of the user base for IPsec?

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb