NAT66 was Re: using "reserved" IPv6 space
On 7/16/12, Owen DeLong <owen@delong.com> wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls & asymmetric routing? Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall? Lee
In message <CAD8GWsswFwnPKTfxt=squUmZofs3_-yriHY8o4Gt3W9+x6fVUQ@mail.gmail.com>, Lee writes:
On 7/16/12, Owen DeLong <owen@delong.com> wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls & asymmetric routing?
Traffic goes where the routing protocols direct it. NAT doesn't help this and may actually hinder as the source address cannot be used internally to direct traffic to the correct egress point. Instead you need internal routers that have to try to track traffic flows rather than making simple decisions based on source and destination addresess. Applications that use multiple connections may not always end up with consistent external source addresses.
Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall?
It can be and it can be easier to debug without NAT mangling addresses. The only thing helpful NAT66 does is delay the externally visible source address selection until the packet passes the NAT66 box. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
If you are running an HA pair, why would you care which box it went back through? -Grant On Monday, July 16, 2012, Mark Andrews wrote:
In message <CAD8GWsswFwnPKTfxt= squUmZofs3_-yriHY8o4Gt3W9+x6fVUQ@mail.gmail.com <javascript:;>>, Lee writes:
On 7/16/12, Owen DeLong <owen@delong.com <javascript:;>> wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
being
able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls & asymmetric routing?
Traffic goes where the routing protocols direct it. NAT doesn't help this and may actually hinder as the source address cannot be used internally to direct traffic to the correct egress point.
Instead you need internal routers that have to try to track traffic flows rather than making simple decisions based on source and destination addresess.
Applications that use multiple connections may not always end up with consistent external source addresses.
Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall?
It can be and it can be easier to debug without NAT mangling addresses.
The only thing helpful NAT66 does is delay the externally visible source address selection until the packet passes the NAT66 box.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org<javascript:;>
In message <CAPiURgV+E-FLg_dkKq97P1OkhBWuZGiRVQd1GvY-Uh=09omREQ@mail.gmail.com>, Grant Ridder writes:
If you are running an HA pair, why would you care which box it went back through?
-Grant
It still doesn't change the arguement. You still need to have flow based routers or you may choose the wrong egress point and if you need NAT66 you have 4+ upstream connections though two of them may be tunnels. You also need a protocol to keep the HA pair state tables in sync. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Think HA pairs in Pittsburgh, Dallas, and San Jose. Now imagine each has different upstream connectivity and the backbone network connecting all the corporate sites lives inside those firewalls. The real solution to this is to move the backbone outside of the firewalls and connect the internal networks via VPNS that ride the external backbone and can be routed over the internet safely when a backbone link fails. However, this still requires some interesting effort in terms of source address selection, routing, etc. in order to avoid triangle routing out of the firewall in Pittsburgh resulting in a return trying to come in via Dallas or San Jose. I think in IPv6, as firewall vendors begin ot mature their products, we'll either see a departure from stateful inspection, or, more likely an ability to set up HA clusters across diverse geography where state tables are kept in sync across the WAN. Owen On Jul 16, 2012, at 7:56 PM, Grant Ridder wrote:
If you are running an HA pair, why would you care which box it went back through?
-Grant
On Monday, July 16, 2012, Mark Andrews wrote:
In message <CAD8GWsswFwnPKTfxt= squUmZofs3_-yriHY8o4Gt3W9+x6fVUQ@mail.gmail.com <javascript:;>>, Lee writes:
On 7/16/12, Owen DeLong <owen@delong.com <javascript:;>> wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
being
able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls & asymmetric routing?
Traffic goes where the routing protocols direct it. NAT doesn't help this and may actually hinder as the source address cannot be used internally to direct traffic to the correct egress point.
Instead you need internal routers that have to try to track traffic flows rather than making simple decisions based on source and destination addresess.
Applications that use multiple connections may not always end up with consistent external source addresses.
Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall?
It can be and it can be easier to debug without NAT mangling addresses.
The only thing helpful NAT66 does is delay the externally visible source address selection until the packet passes the NAT66 box.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org<javascript:;>
On Mon, 16 Jul 2012 21:31:42 -0700, Owen DeLong said:
Think HA pairs in Pittsburgh, Dallas, and San Jose.
Now imagine each has different upstream connectivity and the backbone network connecting all the corporate sites lives inside those firewalls.
The real solution to this is to move the backbone outside of the firewalls and connect the internal networks via VPNS that ride the external backbone and can be routed over the internet safely when a backbone link fails.
Wouldn't this be even easier if you gave each machine involved multiple addresses, one ULA and one external? This isn't IPv4 anymore, you can stick multiple addresses on an interface. :)
On Jul 16, 2012, at 10:20 PM, valdis.kletnieks@vt.edu wrote:
On Mon, 16 Jul 2012 21:31:42 -0700, Owen DeLong said:
Think HA pairs in Pittsburgh, Dallas, and San Jose.
Now imagine each has different upstream connectivity and the backbone network connecting all the corporate sites lives inside those firewalls.
The real solution to this is to move the backbone outside of the firewalls and connect the internal networks via VPNS that ride the external backbone and can be routed over the internet safely when a backbone link fails.
Wouldn't this be even easier if you gave each machine involved multiple addresses, one ULA and one external? This isn't IPv4 anymore, you can stick multiple addresses on an interface. :)
Not really... Doesn't help with the situation where you go from host->Firewall A-> web server on the external internet and the response goes web server->Firewall B-> X (Firewall B has no state table entry for the session). Owen
Op 17 jul 2012, om 04:56 heeft Grant Ridder het volgende geschreven:
If you are running an HA pair, why would you care which box it went back through?
Because it could be/is a stateful firewall and the backup will drop the traffic. (FreeBSD CARP) Cheers, Seth
-Grant
On Monday, July 16, 2012, Mark Andrews wrote:
In message <CAD8GWsswFwnPKTfxt= squUmZofs3_-yriHY8o4Gt3W9+x6fVUQ@mail.gmail.com <javascript:;>>, Lee writes:
On 7/16/12, Owen DeLong <owen@delong.com <javascript:;>> wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
being
able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls & asymmetric routing?
Traffic goes where the routing protocols direct it. NAT doesn't help this and may actually hinder as the source address cannot be used internally to direct traffic to the correct egress point.
Instead you need internal routers that have to try to track traffic flows rather than making simple decisions based on source and destination addresess.
Applications that use multiple connections may not always end up with consistent external source addresses.
Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall?
It can be and it can be easier to debug without NAT mangling addresses.
The only thing helpful NAT66 does is delay the externally visible source address selection until the packet passes the NAT66 box.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org<javascript:;>
On 7/16/12, Grant Ridder <shortdudey123@gmail.com> wrote:
If you are running an HA pair, why would you care which box it went back through?
You wouldn't. But if you've got an HA pair at site A and another HA pair at site B.. Lee
-Grant
On Monday, July 16, 2012, Mark Andrews wrote:
In message <CAD8GWsswFwnPKTfxt= squUmZofs3_-yriHY8o4Gt3W9+x6fVUQ@mail.gmail.com <javascript:;>>, Lee writes:
On 7/16/12, Owen DeLong <owen@delong.com <javascript:;>> wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
being
able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls & asymmetric routing?
Traffic goes where the routing protocols direct it. NAT doesn't help this and may actually hinder as the source address cannot be used internally to direct traffic to the correct egress point.
Instead you need internal routers that have to try to track traffic flows rather than making simple decisions based on source and destination addresess.
Applications that use multiple connections may not always end up with consistent external source addresses.
Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall?
It can be and it can be easier to debug without NAT mangling addresses.
The only thing helpful NAT66 does is delay the externally visible source address selection until the packet passes the NAT66 box.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org<javascript:;>
On 7/16/12, Mark Andrews <marka@isc.org> wrote:
In message <CAD8GWsswFwnPKTfxt=squUmZofs3_-yriHY8o4Gt3W9+x6fVUQ@mail.gmail.com>, Lee writes:
On 7/16/12, Owen DeLong <owen@delong.com> wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls & asymmetric routing?
Traffic goes where the routing protocols direct it. NAT doesn't help this and may actually hinder as the source address cannot be used internally to direct traffic to the correct egress point.
_source_ address + 'used internally'?? I like policy based routing about as much as the more opinionated members of this list like NAT :)
Instead you need internal routers that have to try to track traffic flows rather than making simple decisions based on source and destination addresess.
Applications that use multiple connections may not always end up with consistent external source addresses.
In the general case, sure. At work, the only time your external source address changes is when something quits working and you're automatically failed over to the working firewall (ha pair).
Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall?
It can be and it can be easier to debug without NAT mangling addresses.
Yes, there are times when NAT isn't the appropriate solution. I'm not religious about it.. just saying there's times when NAT is the simplest/easiest solution. Regards, Lee
On Jul 16, 2012, at 6:55 PM, Lee wrote:
On 7/16/12, Owen DeLong <owen@delong.com> wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6.
NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls & asymmetric routing?
1. Share state across the firewalls or go with stateless firewalls. 2. Move the firewalls close enough to the end hosts to avoid this problem, Keep the asymmetric routing outside the perimeter. 3. Very creative source address selection mechanisms. 4. LISP (if you must).
Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall?
That depends on whose life you are trying to make easy. If you asked the application developers or the people that have to build all the problematic ALGs that creates a need for, I'd bet they would have a different opinion than the guy configuring the firewall. In terms of overall problems created, cost to the community, increased insecurity, and the other costs associated with a NAT-based solution, I'd say that it is a net loss to use NAT and a net gain to avoid it. From the perspective of the firewall administrator alone without a broader view of the total consequences, toxic pollution of the internet seems like a good idea. Owen
I have almost one hundred FWs. Some physical. Some virtual. Various vendors. Your point is spot on. -Hammer- "I was a normal American nerd" -Jack Herer On 7/16/2012 8:55 PM, Lee wrote:
On 7/16/12, Owen DeLong <owen@delong.com> wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being able to eliminate NAT. NAT was a necessary evil for IPv4 address conservation. It has no good use in IPv6. NAT is good for getting the return traffic to the right firewall. How else do you deal with multiple firewalls & asymmetric routing?
Yes, it's possible to get traffic back to the right place without NAT. But is it as easy as just NATing the outbound traffic at the firewall?
Lee
participants (7)
-
-Hammer- -
Grant Ridder -
Lee -
Mark Andrews -
Owen DeLong -
Seth Mos -
valdis.kletnieks＠vt.edu