Operational challenges of no NAT

[Mark Smith]

On Sun, 31 Oct 2010 14:34:03 +1030
Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
wrote:

> On Fri, 29 Oct 2010 12:04:13 -0700
> "George Bonser" <gbonser at seven.com> wrote:
> 
> > > > This is all about paradigm shifts.  If you have never heard that
> > term
> > > used then look it up, your going to be dealing with a lot of them with
> > > IPv6.  I daresay that if a network manager cannot deal with these then
> > > he shouldn't be working in the high technology field at all in the
> > > first place, because high tech is full of them.
> > > 
> > > It's this sort of condescension that results in less than useful
> > > discussions.
> > > 
> > > Most folks simply aren't interested in "paradigm shifts" in utility
> > > infrastructure. The Internet is a tool like telephones and
> > electricity.
> > > Most businesses and IT shops are quite conservative. They will
> > actively
> > > resist 'innovation' that breaks the processes and systems their
> > > business relies on, even if those processes and systems are
> > sub-optimal
> > > from one perspective or another. NAT is something that folks use, are
> > > comfortable with, and largely understand the operational implications
> > > of (at least as they apply to themselves). It demonstrably works so
> > why
> > > should they break it?
> > > 
> > > The original poster described operational challenges of running a
> > > network without NAT. If you believe those operational challenges can
> > > be/are addressed in IPv6, describing how this is so would be useful.
> > > Sticking your fingers in your ears and saying "La la la IPv6 means you
> > > don't need NAT" isn't helping anyone.
> > > 
> > > Regards,
> > > -drc
> > > 
> > 
> > The one difficulty that is actually MORE complicated to address is the
> > one of using different source IPs for different types of traffic based
> > on origin of the traffic in my network.  For example, I could use
> > addresses in a single subnet for all of my servers of a particular type.
> 
> With IPv6, you can have individual addresses per *application* - if you
> move that application to another host within the subnet you move the
> address along with it. And if you want even more agility, you could
> have the application specific IPv6 address injected into your routing
> domain as a host route - i.e. anycast without the multiple
> application instances. For your scenario you'd reserve a /64 for all
> your application specific addresses, and then tell your partners to
> white list only this /64.
> 

If you're not comfortable running routing protocols on end-hosts you
could alternatively run static GRE or IP/IP tunnels to them from an edge
router(s) for these per-application host addresses, or use Mobile IPv6.

And if you want topology hiding, another option could be ISATAP over
RFC1918 IPv4 address space. Although the IPv4 addresses of the IPv4
"link layer" are exposed in the IPv6 ISATAP addresses, the
global unreachability and absence of global PTRs for private IPv4
addresses may provide the necessary topology obfuscation for both IPv4
and IPv6.


> "Transient addressing for related processes: Improved firewalling by
> using IPv6 and multiple addresses per host"
> http://www.cs.columbia.edu/~smb/papers/tarp.pdf
> 
> Isn't it magic how "too much" IPv6 address space and large subnets
> allows you to do things that are impossible to do in IPv4.
> 
> 
> > I could have a NAT pool for the Jones traffic and a NAT pool for the
> > Smith traffic.  I could configure the individual IPs on my edge device
> > and the remote site sees only a couple of IPs for each.  When I move a
> > program from one machine to the other or roll out an additional one, I
> > would simply edit the NAT transalation on my side and the other end sees
> > no change and I don't need to bother them with white listing.
> > 
> > If I were to use the same methodology for IPv6, each time I move or add
> > an address, it requires coordination with the other end.  And if the
> > other end is a major portal, multiply the additional work that I am
> > placing on them by the number of other such people like me and it just
> > doesn't scale for them.
> > 
> > The answer is going to be different subnets for each sort if traffic, I
> > think, and a change in thinking on the other end in order for them to
> > accept that.  When I move a machine or roll out a new one, an address
> > within the subnet might change or appear, but that will require no
> > changes on their side provided the white listing is done by /64.
> > 
> > This isn't a matter of competence.  It is a matter of having to redesign
> > a production architecture that is responsible for millions of dollars in
> > revenue in such a manner that it doesn't break AND overlaying that new
> > architectural paradigm over the existing v4 paradigm that must exist on
> > the same hardware at the same time and the old stuff must continue
> > working as it always has. This change in architecture impacts not only
> > the network engineering staff.  It also impacts the systems engineering
> > staff as they must develop new deployment mechanisms that mesh with the
> > network scheme and "just work" to the extent possible, that coexists
> > with the old model and doesn't break it.
> > 
> > And pointing all of this out is to illustrate one of the challenges that
> > has slowed v6 deployment in many operations.  A shop that operates in a
> > pretty lean fashion isn't keen on redesigning their revenue producing
> > architecture unless they really, really, have to.  We have accepted the
> > "new paradigm" and we are quite competent in our fields.  But do we want
> > to put a second engine in the vehicle while it is running down the road
> > without interrupting the operation of the first one?  If this were a
> > "green field" where we could roll it out from scratch and test ideas and
> > different architectures along the way, then yeah, it is a lot easier to
> > do that kind of work on the car when it is in the garage and up on the
> > lift, but in our case the operation must continue current operations
> > while the new paradigm is deployed so it must be thought out and put in
> > place step by step.
> > 
> > One of the important steps is in educating people we transact with on
> > how a change in how THEY do things is going to make life a lot easier
> > for both of us, such as moving away from host-based white listing in v4
> > to subnet-based white listing in v6.  Note that I am not addressing Joe
> > Blow switching to v6 in his home network or some small office of two
> > subnets a few cubicles and a printer.  This is addressed more at the
> > operational challenges of a data center with possibly thousands of
> > servers, dozens of customers and partners each with millions of users,
> > running an operation that the users of the service deem to be critical
> > in their daily routines.
> > 
> > And that condescending attitude is actually quite common so my skin has
> > thickened a bit in that area.  I see it many times as the person
> > expressing it can't appreciate my set of problems and it is coming from
> > their view of the world.  You try telling the AOLs, and Yahoos, and many
> > other places of the world that they have to change how they do things
> > and see how successful you are.  At some point you simply have to wait
> > until they are far enough down that path that they experience the same
> > issue and come to the same conclusion.  They aren't going to believe
> > just any Joe Blow on the internet who tells them that they believe they
> > best way to solve a problem is X because that solution may be from that
> > person's point of view.  They have to go through the same exercise on
> > their side and decide what is the best solution for THEM that also
> > scales with the myriad of people talking to them.  I am pretty confident
> > that it will be subnet-based access rather than host-based but right now
> > it is like explaining to a 10 year old how to merge a car in traffic.
> > They aren't quite ready to hear that yet but might appreciate what was
> > said when they get to driver's education class.
> > 
> > Sorry that this is such a long post but I believe people need to broaden
> > their perspective a bit in order to appreciate the many different
> > operational challenges to v6 migration and it isn't "simple".
> > 
> > 
> >