Operational challenges of no NAT

[George Bonser]

> > 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.
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".