It does strike me as a little beside the point as to whether NAT is a "firewall technology" or a "router technology". In practice, the line between those devices is a little blurred these days anyways. Many devices advertised as "routers" have some basic packet filtering capabilities built in to them and almost all firewall devices (as opposed to personal FW software) are capable of doing some routing. Pretty much all those devices are capable of implementing NAT as well.
However, I personally don't see alot of difference between the statements "NAT is bad because it has the capability to break many protocols/applications" and "Packet Filtering is bad because it has the capability to break many protocols/applications". The bottom line is that there should be NO EXPECTATION that every application/protocol has connectivity from EVERY end point TO EVERY end point on the NET. In fact, wasn't part of the original DARPA specification that the NET remain significantly useful even in the face of massive disruption to it, with whole sections of nodes dropping out? Once you put your packets across some-one else's network boundary, you shouldn't assume a mandate that they MUST be delivered. It's the CHOICE of the person who's boundary you are trying to cross into to determine what to do with them. That NAT CAN (and even DOES) do harm. Sure I'll buy that. However the exact same thing can be said of firewall rules. It's failure to acknowledge the counter-argument that seems problematic.... NAT (just like FW rules) CAN (and even DOES) do benefit as well. I guess the difference that I've seen argued is that with FW rules you CAN open them up where appropriate to let traffic through. However I don't see NAT being any different then that under IPv6...you CAN choose not to deploy it if the situation warrants or impliment a workaround where neccesary. It's up to you individually to judge what's most appropriate for your environment. There is a far cry between having a REQUIREMENT that you deploy in my mind and having the OPTION that you deploy. Christopher Engel -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Brian E Carpenter Sent: Wednesday, November 11, 2009 3:33 AM To: Brian E Carpenter Cc: Roger Marquis; [email protected] Subject: Re: [nat66] Necessity for NAT remains in IPv6 Oops, sorry, went too fast there But Cisco do teach people how to fix problems with router NATs: http://ciscostudy.blogspot.com/2006_02_10_archive.html Regards Brian On 2009-11-11 21:29, Brian E Carpenter wrote: > On 2009-11-11 19:05, Roger Marquis wrote: >> Keith Moore wrote: >>>> Can you tell us what network gear passes SCTP without NAT but drops >>>> it when NAT is enabled, or is this a rhetorical argument? >>> any IP router. >> Any router? Router? When was the last time anyone implemented NAT >> on a router? NAT is a firewall technology, not a router technology. > > I'm not an expert on all products, but Google quickly found me this: > > http://www.cisco.com/en/US/docs/security/asa/asa80/asdm60/user/guide/f > wmode.html > > "This chapter describes how the firewall works in each firewall mode. > To set the mode at the CLI, see the "Setting Transparent or Routed > Firewall Mode at the CLI" section on page 3-4. > > This chapter includes the following sections: > > *Routed Mode Overview > > *Transparent Mode Overview > > Routed Mode Overview > > In routed mode, the security appliance is considered to be a router > hop in the network. It can use OSPF or RIP (in single context mode). > Routed mode supports many interfaces. Each interface is on a different > subnet. You can share interfaces between contexts. > > This section includes the following topics: > > *IP Routing Support ..." > > Brian > > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
