[136551] in North American Network Operators' Group
Re: quietly....
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Feb 3 13:49:39 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9011F76964E89@PUR-EXCH07.ox.com>
Date: Thu, 3 Feb 2011 10:45:53 -0800
To: Matthew Huff <mhuff@ox.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
>=20
> Within similar function in Ipv6, there are a lot of companies, =
especially in the financial realm, that won't migrate off of ipv4.
>=20
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.
>=20
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
>=20
>=20
>=20
>=20
>=20
>> -----Original Message-----
>> From: Jay Ashworth [mailto:jra@baylink.com]
>> Sent: Thursday, February 03, 2011 11:29 AM
>> To: NANOG
>> Subject: Re: quietly....
>>=20
>> ----- Original Message -----
>>> From: "Jon Lewis" <jlewis@lewis.org>
>>=20
>>> 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.
>>=20
>>> 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.
>>=20
>> Precisely.
>>=20
>> 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.
>>=20
>>> People are going to want NAT66...and not providing it may slow down
>>> IPv6 adoption.
>>=20
>> You're using the future tense there, Jon; are you sure you didn't =
mean
>> to use the present? Or the past...?
>>=20
>> Cheers,
>> -- jra
>=20
