> > > Le 27 oct. 2010 à 22:48, Roger Marquis a écrit : > > > As long as consumers and security experts continue > demanding v4-style > > (stateful) NAT in IPv6 efforts to kill it and/or proclaim > it dead are > > greatly exaggerated, at best. > > I agree that, if a NAT66 is combined with a FW, stateful > NAT66 seems more logical than stateless. > > > > In the real world we recognize that IPv6 is and will continue to go > > nowhere until working NAT64 and NAT66 implementations are available. > > As is, this statement is much too general to be defendable: > IPv6 has already gone somewhere, and will continue, at least > for many residential customers (Free in France, SoftBank in > japan, Comcast trials in the US...) > > > > That's not opinion but simple, objective, agenda-free observation. > > Apparently, you know customers that want NAT66 (in addition > to their stateful FWs) because they want IPv6 asap, and find > they need IPv6 address translation for this. Then, describing > in detail at least one of their configurations, and for which > use they need IPv6 asap, would be a very useful contribution. > (So far, we have statements that such customers exist, but > technical descriptions of what they want to do are IMHO badly > missing.) > > > Regards, > RD > >
Remi, I wont pretend to answer for Roger, but I'll answer for myself. Perhaps it will give you an idea of exactly what we are using NAT for today, and what we want it (or an appropriate substitute) to accomplish for us in future. Firstly, we are an Enterprise ourselves and a SaaS provider. Therefore we maintain or own corporate Enterprise Network as well as an environment for hosting our SaaS applications. We don't anticipate any immediate need for IPv6 and indeed adoption of it will entail some significant costs for us. Regardless, we recognize the importance of IPv6 in terms of growth of the internet (from our perspective the SOLE advantage it providers over IPv4 is allowing more people to connect to the internet) and it make sense to us to start establishing plans to support connectivity with IPv6 only addresses in future. Ideally in the very long term, I'd prefer to run IPv6 natively as well...not because I see any inherent advantage in IPv6 over IPv4 for us...but because it makes sense to deal with as few protocols as you can get away with. However, we have some functions that NAT44 currently provides us that we will still need to have met in future..... 1) Simple Security: We have a variety of devices on our networks, including servers, workstations, printers, scanners, etc. The vast majority of these devices will never and should never expect INBOUND connections, though a fair number of them may need some OUTBOUND connectivity. We have all the standard security devices/controls one would normal expect from an Enterprise of our nature, including Statefull Inspection Firewalls on all of our network boundaries. Yet we understand full well that reliance on single points of failure for security is foolhardy and that robust security entails multiple layers of compensating controls. Simply put, without NAT, if my SI Firewall filters fail (say due to misconfiguration) then I have hundreds of devices of all types potentially exposed to INBOUND attacks from beyond the network perimeter. With MANY:1 NAT, all those devices avoid exposure since an external attacker has no way to address INBOUND connections to them. THAT has value to us. 2) Infrastructure Abstraction: Since we also provide various services that expect external connections INBOUND (appropriately hardened, filtered, and placed in DMZ's). We have a need to maintain consistent unchanging external advertisements of those services. Furthermore those advertisements need to be the IP addresses since...a) We cannot predict that all applications connecting to said services are capable of supporting higher level referrals, b) Even with those that support DNS, there are many issues involved with caching, propagation and the simple fact that the host (or some intermediary) controls DNS resolution that make reliance on DNS undesirable, c) In many cases, our clients or business partners make explicit holes in their own firewalls for connectivity to such services, changing the IP address assigned to said advertisement would necessitate a process of contacting each of these and arranging to have them MANUALLY adjust their FW filters accordingly. Using static NAT mappings of internal IP:Port to external IP:Port for these services on our network boundaries allows us to change around the internal architecture in whatever manner we wish, use whatever internal addressing scheme makes sense to us and maintain consistent external advertisement of services. It also allows us to accomplish this by generally making changes on a very few number of (NAT) devices, which obviously has simplified management benefits. 3) Centralized Control: Like many Enterprise organizations. We desire to maintain some control, management and monitoring over the various tools our employees utilize to perform their work when representing us. There are many different mechanisms which aid in said task, including things like local and group policy enforcements, etc. NAT actually has some role here as well, due to the vary fact that it does certain classes of applications (P2P) more difficult to function without some intervention on IT's part. Essentially from a filtering perspective it's not practical to block OUTBOUND connectivity from a workstation to any arbitrary address out on the internet (DENY OUT ALL). Now if my filters can recognize the specific application generating such traffic they can seek to block it. However this is very often not practical due to the frequency with which new applications are released and the increasingly common practice of application developers to hide their applications traffic by encapsulating it in well known "allowed" protocols and ports (i.e. HTTP on Port 80) in an effort to thwart filters. NAT does tend to break the end-user to end-user connectivity of such apps...or at the very least forces them to use well known, statically addressed intermediaries which I CAN black-hole/filter against. Though not a perfect solution, it does provide value to us. 4) Privacy: At the network level, NAT helps shield end user/end device addresses from one another and makes it more difficult (not impossible, just more difficult) to track their activity and profile them and the infrastructure they come from. This has some value to us. I hope this provides you with at least some insight of some of the goals which we need to support, both now and in the future. Note I'm not at all opposed to IPv6... I'm just opposed to forcing everyone into a One Size Fits ALL deployment scenario for IPv6. I'm sure that organizations like mine WILL EVENTUALLY find vendors willing to provide us with statefull NAT66 devices that meet our needs regardless of RFC's or the IETF. Simply due to the fact that those needs/desires are not going to go away...and too many companies like mine are going to be throwing too much money on the table for such solutions for vendors to ignore it. I'd just prefer that some standards exist for how those solutions might work. In my view, that would make it easier for everyone involved, including guys like Keith... to understand and predict how they might behave. Christopher Engel Network Infrastructure Manager SponsorDirect [email protected] www.SponsorDirect.com p(914) 729-7218 f (914) 729-7201 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
