[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSEC and NAT and the BIG PICTURE



Scott> I will counter Dan's comments by saying that NAT provides a working
Scott> mechanism which resolves a number of problems resulting from
Scott> short-sighted design/implementation decisions. Having risked angering
Scott> those who made the decisions, I will add that I recognize that they
Scott> simply did not foresee the Internet that we know today - I don't think
Scott> anyone did.

Scott,

It's okay.   There is a  peer-reviewed paper in the  recent
Jul/Aug issue of IEEE Network Magazine about the subject you are discussing.
(sorry to toot my horn, but i wrote the darn thing  .......)       

IMHO, this WG is not the place to discuss scalability issues with IP routing,
CIDR, or NAT.  IPSEC, again IMHO, should work with 'the state of how things
are' not, again IMHO, the state of how things could be and should have been
with regard to route scalability issues.   This issue  was, and continues,
to be a very difficult issue in the IETF.  

The facts are, Network Address Translation is here to stay for a long time,
there is no 'save the world' super-scaleable exterior routing protocol
on the reality radar screen that will be implemented in the near future.

IPSEC would do a 'very good thing' if flags, hooks, and glue were considered
for networks with NAT.   I have not read the recent RFCs, but I have always
assumed that IPSEC covered an encryption option that  provided for NAT
and other possible header modifications, protocol proxies, etc.

Funny, someone mentioned NAT was a kludge!  Hell, most of the Internet
development is a kludge of some sort :)  Having a kludgy internet is
a feature, not a bug, and part of the success of TCP/IP.


Best Regards,

Tim





Follow-Ups: References: