Subject: Re: NAT Not Needed To Make Renumbering Easy

From: [email-masked] (Noel Chiappa)
Date: Sun, 25 Oct 2009 13:42:29 -0400 (EDT)

> From: Sabahattin Gucukoglu <[email-masked]>

    > in particular: we need a simple way to express host relationships
    > inside an organisation that is independent of external homing.  

Well, it would really help if we had more namespaces available to name
things in. Oh, wait...

	Noel

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 26 Oct 2009 02:43:17 +0000

> Well, it would really help if we had more namespaces available to name

It needn't be so bad.  There are basically two solutions:

1.  We rely on everybody to instantly fall in love with NND+SAC,  
taking care of the "Network" layer.  We devise a language, syntax,  
rules or whatever it is to describe nodes inside a variable-length  
prefix assigned by an RIR, that people who ought to know better can  
write their firewall rules and their DHCP server configurations and  
their management tools and whatever with.  This happens at the  
"Application" layer, and applies the simplicity of rehoming (or maybe  
even multihoming) to every situation where the primary prefix is the  
only variable.  Since it performs its duties on a presumably  
infrequent basis, the implementation does not have to be at all low- 
level.

Or:

2.  We give up all hope of avoiding NAT, even point-to-point NAT, and  
either devise the ultimate NAT-PMP replacement to make the application  
layer know about the deception happening (or write an API overload  
that makes the same thing happen in sockets) or rewrite or adjust all  
protocols, or replacements for protocols, so that they don't have to  
know or care about translation.

I'm for 1, though perhaps somebody could explain why the latter option  
in 2 is infeasible and/or principally violates good protocol design  
(encryption, performance loss and all that notwithstanding).  Did FTP  
really need to be so damned inconvenient to run behind a NAT?

Cheers,
Sabahattin