Home page logo

nanog logo nanog mailing list archives

Re: Where NAT disenfranchises the end-user ...
From: bmanning () vacation karoshi com
Date: Fri, 7 Sep 2001 18:16:52 +0000 (UCT)

Sez you.  As you design you app, please consider how many NATs the
packets must traverse and what each may do to your packets while in
flight (without telling you squat) before they reach the intended 
destination (and for that matter, how do you tell when you've arrived?)

NAT designers mess with MTU, headers, and even the data.  By the
time the packets "reach" the intended receipient, they're not even
mine anymore.  But that is a comforting thought. Plausable Deniability.
"No UrHonour, I never sent that. It did not come from my machine."

Again, NAT is a tool.  Where it makes sense to share fate, impose 
random policy, and (oh yeah) save some slots in Friend Bushes routing
table, NAT is your friend.

:Random Ob:
Flip NAT over, use RFC 1918 space as the "global" address space and
run everything else "inside" as private space.  This may be the "poison pill"
that solves the apparent routing table problems if the IRTF & IESG can't
solve the problems for us in time.

--bill (needing more sleep)

It seems a pretty simple argument to me.

Do I want as many people using (and maybe _buying_, what a concept!) 
my app as possible with the least amount of network clue and setup 
headaches, or do I want to eliminate most of the corporate, SOHO, 
cable, DSL, Linux population because I cant be bothered to develop my 
app to be NAT-friendly.


All the previous times this discussion has arisen here, I have 
concluded that "real" IPs should only be owned and used by folks with 
clue, everyone else gets a NATed IP. Discuss.


 > > |> True...  neither does a well-firewalled LAN.
 > There is a substantial difference between broken access and controlled
 > access.

 Yes, but there are plenty of apps that will not work if you do not leave
 open large, arbitrary ranges of udp ports.  This is fundamentally
 incompatible with most sane firewalls.  Or NAT.

 Why write a protocol that way?  Just to prove NAT sucks?


    No, because they were either written before NAT existed and
tried hard to conform to the end2end principles of Internet Architecture
or they were written after NAT existed and tried hard to conform to the
end2end principles of Internet Architecture.

    NAT violates the end2end principles of the Internet Architecture
by placing one or more policy abstraction layer(s) between the endpoints.

    That said, NAT is a tool in the tool box.  I'd like to think that
its worth the effort to try and recover true end2end.


jon_mansey () verestar com                      Chief Science Officer
Verestar Networks, Inc.                    http://www.verestar.com
1901 Main St.                                   tel (310) 382 3300
Santa Monica, California 90405                  fax (310) 382 3310

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]