Subject: [v6ops] IPv6 Enterprise issues (was: Apologies)

From: Erik Kline <[email-masked]>
Date: Mon, 9 May 2011 20:07:50 +0000

"""
The biggest problem right now are howto not do NAT when doing IPv6.
It is not an option to not run NAT in some form or another.
"""

Can you elaborate?

We have not found it necessary at all for the 10-20k+ corporate IPv6
users, but I'm fully prepared to believe that we see things
differently.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 9 May 2011 22:54:18 +0200

> users, but I'm fully prepared to believe that we see things

We are not really an ISP or a real enterprise, we are set to run a closed
network.

Consider it a sort of Internet light which interconnect lots of other
end-sites and other networks. The entire  RFC1918 space are used
several times over and by several of the network we interconnect with,
and some are running public IP addresses. Some of the networks are
even more closed than ours. Internet light with tons of NATs.
(closed don't really hang together with security, more with practical
solutions combined with the thought of NAT is nice)

Everyone also agree there is a need for communications to/from Internet,
but how?

It is _not_ an option to let everyone freely communicate to/from Internet in
any way. It sort of indirect mandate use of NAT or proxy services in one
form or  another. Forget the thought of changing that for the near term
future, we are set to run a _closed_ network.

Mail and DNS are the easy one, what about web traffic? streaming?
youtube etc... not so clear yet if we can do it with IPv6 at all.

Can we enable IPv6 for some of our customers? How do we give them
access to IPv4 _only_ services? Consider legacy software and hardcoded
IPv4 IP adresses... Maybe we can let some of our customer be IPv6 only?
Still, that don't lower the usage of IPv4 adresses.
Can we start using IPv6 on some part of our network, some of the
interconnect or VPNs? But guess what, we are also depending on ISPs
to deliver some of the links and not all of them support IPv6 at all....
and the list goes on.

Oh and the IPv4 shortage have already hit us hard.

We knew we would be running low on usable IPv4 adresses so we had started
the process towards RIPE to get a new block. But we ran low way faster than
planned combined with HD-ratio discussion which caused the process to get
new addresses to take longer. Problems....
The solution was to rearrange some tasks related to projects to get around
the HD-ratio discussion. So it also cost us resources both in manhour and
money.

But all of this just postpone what we know will hit us, we will run
out of usable
(public) IPv4 adresses.

My current project are to build an ISP-lite network isolated from the
rest to get
the outer edge of our network up'n'running, to see how we can build the rest
in one way or another. Try out some of the options and solutions safely.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Michael Smith <[email-masked]>
Date: Mon, 09 May 2011 20:54:33 +0000 (GMT)

On May 09, 2011, at 01:07 PM, Erik Kline <[email-masked]> wrote:

"""

Can you elaborate?

There are compliance models that require NAT (PCI amongst them) and a set corporate mindset that a "stateful firewall with NAT" is one key component to defense-in-depth.  Many security policies are written with a MUST for NAT, not a SHOULD.

We've had to carve out a portion of our /32 for "NAT", in as much as I terminate one set of addresses on the outside of my edge device and translate them into another set of my addresses.  It satisfies the auditors because the incoming session is inspected and rewritten.  It's also insane, but there are engineering needs and business needs, and monthly recurring revenue often trumps engineering decisions.

Mike

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 9 May 2011 22:57:29 +0200

On Mon, May 9, 2011 at 10:51 PM, Michael Smith <[email-masked]> wrote:
<snip>

> We've had to carve out a portion of our /32 for "NAT", in as much as I
> terminate one set of addresses on the outside of my edge device and
> translate them into another set of my addresses.  It satisfies the auditors
> because the incoming session is inspected and rewritten.  It's also insane,
> but there are engineering needs and business needs, and monthly recurring
> revenue often trumps engineering decisions.

What technical solution did you chose for that rewriting?
(I don't want to comment on the rest;)

-- 

Roger Jorgensen           |

---

From: Michael Smith <[email-masked]>
Date: Mon, 09 May 2011 21:01:01 +0000 (GMT)

On May 09, 2011, at 01:57 PM, Roger Jørgensen <[email-masked]> wrote:

We use FreeBSD and PF  All addresses and mappings are statically assigned.

Mike

---

From: Mark Smith <[email-masked]>
Date: Tue, 10 May 2011 06:56:26 +0930

On Mon, 09 May 2011 20:54:33 +0000 (GMT)

> We've had to carve out a portion of our /32 for "NAT", in as much as I terminate one set of addresses on the outside of my edge device and translate them into another set of my addresses.  It satis…

I expect DPI boxes are going to become more common for this task.
ISATAP could be used to hide the internal IPv6 topology. If hiding the
actual internal addresses is deemed necessary then specific application
proxies might be preferable because they'd also provide an application
use audit log, which is likely to also be required in that sort
of security context.

Regards,
Mark.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 9 May 2011 23:33:32 +0200

On Mon, May 9, 2011 at 11:01 PM, Michael Smith <[email-masked]> wrote:
> We use FreeBSD and PF.  All addresses and mappings are statically assigned.

Yeah thought so. My first attempt was going to be Linux but neither that or
FreeBSD is probably usable in the production environment for not only technical
reasons.
If I'm lucky my ASA box might help me, haven't yet got around to check
if it do...
only got it ~12hours ago:)

-- 

Roger Jorgensen           |

---

From: David Farmer <[email-masked]>
Date: Mon, 09 May 2011 18:40:18 -0500

> users, but I'm fully prepared to believe that we see things

While it is not necessary to do NAT with IPv6, there are enough 
addresses, and there are many good reason not to do NAT at all in IPv6. 
  The problem is we are requiring many enterprises to make a significant 
change in their network architecture and/or philosophy to migrate to 
IPv6, beyond the size of address they use.  With IPv4 many of them are 
using NAT, with IPv6 we are currently telling them they shouldn't be, 
this NAT to no-NAT transition will be a much bigger change for many of 
them, than the IPv4 to IPv6 transition.

This will be a hurdle preventing many enterprises from transitioning to 
IPv6 on a timely basis.  Furthermore, I believe it is unfortunate that 
we are asking people to more or less do a cold turkey transition from 
NAT in order to do IPv6.  Yes, their networks will probably be better 
for it eventually.  But, do they really see and believe what we are 
telling them?  There are many reasons that enterprises do NAT, some are 
more perception than reality, but the transition to IPv6 doesn't 
necessarily change those perceptions or even all the realities behind 
why they are doing NAT.

An example, as a non-smoker it is difficult for me to understand what it 
takes for a 2 pack a day smoker to quite their habit.  Isn't it equally 
difficult for an operator of a non-NATed network to really understand 
how big of a change it really is to go no-NAT?

Asking everyone to do a cold turkey transition from NAT, isn't 
necessarily going to facilitate a transition to IPv6, just like going 
cold turkey doesn't always work as a way for people to quite smoking. 
To help smokers quit, there is everything from nicotine substitutes, to 
twelve-step programs, peer or professional counseling, non-nicotine drug 
treatments, etc...  I believe we need to take a more sophisticated view 
of how NATed IPv4 enterprises are going to transition to IPv6, rather 
than just telling them to do a cold turkey transition from NAT.

Therefore, we need to be looking at what kinds of strategies, other than 
a cold turkey  transition from NAT, that a NATed IPv4 Enterprise network 
can use for its transition to IPv6.  Such as, Dual-Stack Web and other 
application proxies at the current NAT boundary, Dual-Stack public 
facing servers in the DMZ network, and maybe even NAT66.  (I open to 
other ideas too, I'd love to hear them.)

Windows7, which is starting to be used in a lot of enterprises, has a 
lot of IPv6 features and is creating demand for IPv6 internal to many 
enterprises.  But many enterprises are not ready for the philosophical 
leap to go to global public addresses inside their network. Are we going 
to tell them not to do IPv6?  Do NAT66?  Something else?

So, I think it boils down to a question; Which is more important to the 
v6ops community, killing NAT or transitioning to IPv6?  And, what if we 
can't do both at the same time?

Personally, I believe transitioning to IPv6, is the more important of 
the two issues.  I believe NAT will die a natural death, if we 
successfully transition the Internet to IPv6 and solve the renumbering 
problem for enterprises to change providers cleanly without renumbering 
their entire network infrastructure.

By not providing NAT66 we have eliminate the primary mechanism that many 
enterprises understand and use to avoid renumbering their network. 
Right or wrong, NAT is fundamental to the network architecture that a 
large number of enterprises use to operate their networks.  If we are 
not going to provide NAT66, then we better figure out a number of viable 
alternative for those that are not going to be able to do a cold turkey 
transition from NAT as part of their transition to IPv6.  Otherwise, I 
afraid that our current strategy of requiring a cold turkey transition 
from NAT, will at best delay, and at worst prevent, a transition to IPv6 
for much of the Internet, either would be unfortunate.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 10 May 2011 07:39:31 +0200

First of all, I do not believe NAT is the right thing todo, but that
don't change
the reality I and other do work under/with.

<snip>

> difficult for an operator of a non-NATed network to really understand how
> big of a change it really is to go no-NAT?

That an excellent way of looking at the NAT issue from "enterprise" side.

I am so very against NAT for many reasons, but that doesn't change the
reality I'm working under. And it is not so much a technical issue as a
educational issue, combined with a quite deep belief in NAT being good
for security.

<snip>
> Therefore, we need to be looking at what kinds of strategies, other than a
> cold turkey  transition from NAT, that a NATed IPv4 Enterprise network can
> use for its transition to IPv6.  Such as, Dual-Stack Web and other
> application proxies at the current NAT boundary, Dual-Stack public facing
> servers in the DMZ network, and maybe even NAT66.  (I open to other ideas
> too, I'd love to hear them.)

I do not like NAT66 or any other NAT related technology at all... but as I said,
might not have any chance to not do some sort of _address translation_.

Something as "simple" as changing the entire prefix for any given /64,
from 2001:db8:1234:5678::/64 to 2001:db8:8765:4321::/64 might even be
enough to solve the "we need NAT" issue for some enterprises.
Combine that rewrite with some sort of anti virus/trojaner/something scanner
device and I know some people would be happy:-)

-- 

Roger Jorgensen           |

---

From: Michael Newbery <[email-masked]>
Date: Tue, 10 May 2011 18:07:54 +1200

> the reality I and other do work under/with.

[snip]

> educational issue, combined with a quite deep belief in NAT being good

Then should not the correct response be to educate them?
"We need NAT"
No, you don't.

Because:
1. No NAT in IPv6
2. All the things that NAT does in IPv4 are done otherwise, and better, without NAT, in IPv6.

(Yes, I know there are some corner cases. Being a good geek and seeing both sides of the argument is counterproductive here. If you are arguing with someone who treats "NAT is Good" as an article of faith, then "There is no NAT in IPv6" is as far as you need to go in response. Anything else is just going to lead into dark paths of confusion).

The solution to faulty beliefs is education.

Should not the correct response of this WG to your request be information to counter the mistaken beliefs?

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 10 May 2011 08:15:23 +0200

On Tue, May 10, 2011 at 8:07 AM, Michael Newbery <[email-masked]> wrote:
<snip>
> The solution to faulty beliefs is education.

yes it is, but it might take time, what do we do in between?

-- 

Roger Jorgensen           |