- From: Edward Lewis <edlewis@arin.net>
- Date: Thu, 5 Dec 2002 18:33:31 -0500
- To: discuss@apps.ietf.org
This is a sloppy reply to something I saw below. I apologize to threaded mail readers that will misplace this message...;) >Graham> Where this all leads, I think, is that the worst thing about NAT is >Graham> that it hinders the deployment of new applications. I was on a call today where we went over the problems of adding DNSSEC to DNS in the face of what amounts to NATs. The following point was made: The problem that is appearing is not due to DNSSEC, nor due to DNS, nor really due to NAT. The problem is rooted in that DNS was not designed to run across NATs - and the implication is that forward progress (extensions) is hindered because of this. I'm not convinced that NATs 'hinder' the deployment of new applications, in the sense that 'hinder' means 'prevents,' or 'stops cold.' The presence of NAT does call for a more sophisticated protocol (okay, complicated), I'll grant you that. (I should add that I may be naive here.) I'm convinced that had DNS built in features to remotely manage answers from a cache (which is the crux of the problem - a cache sitting topologically on a NAT node) and had made error reporting more explicit, DNSSEC wouldn't be facing the problem de jure. So, I'm convinced that NAT hinders extension of existing (pre-NAT) applications. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer
Received on Thursday, 5 December 2002 18:38:12 UTC