Gentlemen, Unless I am misunderstanding how ULA works I don't see how it addresses the 2nd issue I raised. It provides a private address space, but doesn't provide any means to relate that space to your public address space. I don't see any abstraction there.... just the possibility to maintain an additional space.
Example: I have a service that I publicly advertise on Network A, Host 1 (public address space). I provide that service on an internal device on Network B, Host 1 (private address space) but I want to move that service (either temporarily or permanently) to be provided on a different internal device Network B, Host 2 (private address space). I don't see how ULA helps with that. It allows me to have a private address space...but it doesn't provide any mapping of that space to the Public Address space... that's what NAT does. In this scenario with NAT, I only need maintain 1 address scheme on my internal network (the private one). My external address scheme only exists virtually on my firewalls external interface. When I want to switch which internal device is providing that service all I need do is logon to my firewall, change the NAT mappings to it and then cycle the active connections for the device...presto done...simple and easy. In the ULA scenario, I would need to maintain 2 separate address schemes on my private network... the ULA (private one) and the public one. I would have to manage those address schemes on the NIC of every single device that might need external access and I'd need to logon to those individual devices when I wanted to make changes. That REALLY is NOT an abstraction of the internal infrastructure... it's just an additional network placed on the internal infrastructure. It doesn't compare with the utility provided by NAT. Where I have only one network/address space to manage on my internal infrastructure. I have one device make any changes I want on, they happen simply and easily and they allow me to completely abstract my internal infrastructure.... even going so far as the port level. (Which, btw, can provide ALOT of utility if services outgrow a particular device and I want to split the ones it provides to different machines without changing anything about the external service address). As far as item #1 and firewalls being configured with a default rule of DENY ALL IN. That's pretty much standard configuration these days. However, I've already covered this and it doesn't address the issue I raised. Standard practice is to Deny ALL IN by default and then poke holes as needed. The issue comes in the "poking holes" process. This is where you see the most common mistakes... where the holes being poked are larger then necessary. For a specific example: Imagine an admin wanted to create a rule to ALLOW HTTP OUT ALL... to let all internal devices go out and do web browsing. By mistake they configure it to ALLOW HTTP IN/OUT ALL... not hard to do on some firewall interfaces. Your default DENY ALL IN rule doesn't help.... it's just been overridden by accident. NAT, however, DOES help....as none of those internal devices are publicly addressable unless they've been given a static 1:1 mapping. I really don't think you guys are thinking this through completely. Honestly, I think you are so intent on driving a stake in the heart of NAT that you don't recognize the VERY REAL utility NAT provides in some areas. That's a big part of the issue with RFC 4864.... it comes of as an advocacy piece rather as a straight informative piece. Finally I don't believe you would have a very successful time convincing a security auditor that ULA covers the PCI-DSS v1.2 Requirement 1.3.8, when they say use "Use network address translation (NAT)" that is PRECISELY what they want you to do. I've dealt alot with those type of audits. You are going to have a VERY tough sell that ULA is an acceptable "compensating control" for that. Bottom line is, that whether you like it or not you WILL be dealing with NAT in an IPv6 world. There will be too many people like me who demand it. Vendors will listen to those demands because there will be a market there for them. You can either try to exert some influence over the manner in which it is implemented, and possibly address some means of compensating for it.... or just try to pretend it's not going to happen and let the chips fall as they may. Christopher Engel -----Original Message----- From: james woodyatt [mailto:[email protected]] Sent: Monday, November 09, 2009 8:14 PM To: Brian E Carpenter; Chris Engel Cc: NAT66 HappyFunBall Subject: Re: [nat66] Necessity for NAT remains in IPv6 On Nov 9, 2009, at 16:34, Brian E Carpenter wrote: > Ah, you mean the utilisation of NAT covered by US Patent 5371852? Yes, the IBM cluster patent. I see that IBM issued an IPR disclosure to IETF for that patent, but has only promised to grant RAND licenses for VRRP usage. The more general application of the invention that Mr. Engel references appears not to be expressly declared. <http://www.ietf.org/ietf-ftp/IPR/ibm-rfc2338-rfc2787.txt> Yes, we are well and truly off topic now. ObTopic: the NAT66 draft doesn't help address either of the two concerns Mr. Engel raised, i.e. neither the high availability consideration, nor the issue with misconfigured NAT failure tending toward "closed" rather than "open" configurations. A misconfigured NAT66 middlebox, being a symmetric NAT, is just as likely to fail "open" as "closed" from his perspective. I'll leave it to the authors of the NAT66 draft to respond. -- james woodyatt <[email protected]> member of technical staff, communications engineering _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
