Chris Engel wrote: > 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. I don't think NAT causes many problems when used in this manner - to map specific hosts with specific, well-known, services, to specific external addresses. The alternative would be to use a tunnel, which has its own problems, and it's a case of choosing the lesser of two evils. Which is better depends on specific circumstances.
But that kind of NAT has almost nothing in common with the kind of NAT you cite below: > 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. You seem to be arguing that NAT is a way to solve the problem that firewalls have poor configuration interfaces. That strikes me as a bit like using a cannon to try to swat a fly - you're doing so much collateral damage in the process that the fly becomes irrelevant. And the argument that NAT helps here is completely bogus, because while there are indeed cases where a NAT "just happens" to do the right thing, there are also numerous cases where it "just happens" to do the wrong thing. You want to call attention to the former cases while ignoring the latter ones. > 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. It's clear that you haven't thought this through completely. Either that or you're so intent on driving a stake into the Internet's ability to evolve and support new applications that you don't recognize the VERY REAL utility the Internet provides outside of existing transport protocols and the few applications that you care about. And you're so committed to this view that the Internet should always stay the same as it is now, that you react adversely to RFC 4864 or anything else that tries to make the Internet more useful or more broadly applicable. > 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. There's lots of ignorance in the world. IETF's job is to explain how to make the Internet work well, not to propagate ignorance or to give it more credibility than it deserves. > 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. Too many people who are bent on crippling the Internet. Keith
_______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
