On Feb 3, 2011, at 8:46 AM, Matthew Huff wrote: > There is also another reason for NAT44 or NAT66 in the corporate world that > has been missed in these conversations. It is very common to NAT44 when > connected via extranets to another company via an b2b provider such as TNS or > BTRadianz. Not everything goes over the net. NAT44 (especially "twice-nat") > is used for a number of reasons including limiting of exchange of routing > information, routing of different services in different directions via NAT, > or to prevent having to contact the other side when a server changes. For > example if we are natting one of our FIX servers then the internal machine > can change as long as the NAT is updated. This is far simpler than having to > get the changes externally especially at some big bank. Also some companies > bring internet routes into their core (I still don't know why). In order to > route web/email to them via the internet and protocols such as FIX via an > extranet, twice-nat is required. > > Within similar function in Ipv6, there are a lot of companies, especially in > the financial realm, that won't migrate off of ipv4. > In IPv6, the simpler solution is to allocate a /64 to groups of machines that serve such a function. If you need to move the group, you can simply move the entire prefix.
> NAT is used for a reason, not just because "we don't know better". Yes, we > know it breaks certain apps, especially p2p ones. In a corporate view, that > is a feature, not a bug. We neither want, nor will allow individual desktops > to become peers. Only a limited number of dedicated servers have external > visibility, and that's the way it's going to stay regardless of ipv6 ideology. > Actually, there are better alternatives to NAT in IPv6 for just about every reason, so, yeah, the desire for NAT in IPv6 really does boil down to "we don't know better yet". You can break p2p just as quickly without NAT using policy. NAT doesn't provide policy, it just limits your ability to choose your own policy. Owen > > > > > >> -----Original Message----- >> From: Jay Ashworth [mailto:j...@baylink.com] >> Sent: Thursday, February 03, 2011 11:29 AM >> To: NANOG >> Subject: Re: quietly.... >> >> ----- Original Message ----- >>> From: "Jon Lewis" <jle...@lewis.org> >> >>> There's an awful lot of inertia in the "NAPT/firewall keeps our hosts >>> safe from the internet" mentality. Sure, a stateful firewall can be >>> configured allow all outbound traffic and only connected/related >>> inbound. >> >>> When someone breaks or shuts off that filter, traffic through the NAPT >>> firewall stops working. On the stateful firewall with public IPs on >>> both sides, everything works...including the traffic you didn't want. >> >> Precisely. >> >> This is the crux of the argument I've been trying, rather ineptly, >> to make: when it breaks, *which way does it fail*. NAT fails safe, >> generally. >> >>> People are going to want NAT66...and not providing it may slow down >>> IPv6 adoption. >> >> You're using the future tense there, Jon; are you sure you didn't mean >> to use the present? Or the past...? >> >> Cheers, >> -- jra >
