NAT v6->v4 and v4->v6 (was Re: WG Action: Conclusion of IP Version 6 )

The IETF thinking for the last 10+ years (and I include
myself in this) had been that dual stack was the answer and
most things would be converted to dual stack before we ran
out of v4.

Well, it has not happen.

There is still very little v6 deployment and we will be
running out of v4 space soon (instantiate soon by your
particular prediction of the day you won't be able to get
space from your RIR, either because there is no more or
because you do not qualify any longer).

Given the above, it is clear that we are gong to see devices
(which might be dual stack *capable*) that will be deployed
and provisionned with *v6-only*...

At the edge of the network, where we have devices by the
millions and where address space is a critical issue and
dual-stack is a non starter, this is already under way...

It is also becoming apparent that:

- the "core internet" (ie the web and any
infrastructure server) will take a long time to move to v6
and/or dual stack.

- new v6-only edges will have to communicate with it. So we
need v6->v4 translation in the core

- legacy v4 PCs (think win95 up to win XP) using RFC1918
addresses behind a home gateway  will never be able to
upgrade to an IPv6-only environment. So if we provision the
home gateway with v6-only (because there will be a point
where we do not have any global v4 addresses left for it)
those legacy PCs are going to need a double translation,
v4->v6 in the home gateway and then v6 back to v4 in the
core. Note: a double private v4->private v4->global v4
translation would work too, but if you are running out of
private space as well, this is also a non-starter...

- there are a number of internal deployment cases where net
10 is just not big enough, thus the idea to use v6 to glue
several instances of private space together as a 'super net
10'. For this to work, legacy devices that cannot upgrade to
v6 need to go through a translation v4->v6.

So, no, NAT v4->v6 or v6-v4 does not solve world hunger
but solve very real operational problems.

    - Alain.





----- Original Message -----
From: Jari Arkko <jari.arkkopiuha.net>
To: Durand, Alain
Cc: Randy Bush <randypsg.com>; nanognanog.org
<nanognanog.org>
Sent: Fri Sep 28 00:25:11 2007
Subject: Re: WG Action: Conclusion of IP Version 6 (ipv6)

Randy, Alain,

>
>     o nat-pt with standardized algs for at least dns,
smtp, http, sip, and
>     rtp
>
>
> -->> This is on my top 3 hot topics. And make it
works both way, v4 to
> v6 and v6 to v4.
> And also don’t call it NAT-PT. That name is dead.

For what it is worth, this is one of the things that I want
to do. I don't want to give you an impression that NAT-PT++
will solve all the IPv6 transition issues; I suspect dual
stack
is a better answer. But nevertheless, the IETF needs to
produce a revised spec for the translation case. Fred and
I are organizing an effort to do this.

Jari

> It is also becoming apparent that:
> 
> - the "core internet" (ie the web and any
infrastructure 
> server) will take a long time to move to v6 and/or dual
stack.
> 
> - new v6-only edges will have to communicate with it.
So we 
> need v6->v4 translation in the core

Some companies have implemented MPLS in the core, therefore
they can
easily add IPv6 services by configuring 6PE on a couple of
PE routers in
each PoP. Beyond the PoP, in the customer's network, they
can do pure
IPv6 if that is what they want.

> - legacy v4 PCs (think win95 up to win XP) using
RFC1918 
> addresses behind a home gateway  will never be able to

> upgrade to an IPv6-only environment. So if we provision
the 
> home gateway with v6-only (because there will be a
point 
> where we do not have any global v4 addresses left for
it) 
> those legacy PCs are going to need a double
translation, 
> v4->v6 in the home gateway and then v6 back to v4 in
the 
> core.

Not if they use an application layer proxy in their gateway.
It's not
too late to specify this as a standard function for an IPv6
Internet
gateway device. Also, the "v6 back to v4"
conversion could be handled in
an information provider's data center (Google, CNN) not in
the core.

> So, no, NAT v4->v6 or v6-v4 does not solve world
hunger but 
> solve very real operational problems.

Agreed. Just about every possible transition technique will
solve real
operational problems and we should not be purists about
this. Whether
the IETF has a specification for it or not, people will
build and deploy
NAT and ALGs among other things.

In addition, this transition comes at a time when we have
the technology
that allows virtually anyone (high school kids) to build
some kind of
network functionality on top of Linux or BSD. If that is
useful, anyone
can freely implement this including the manufacturers of
Internet
gateway devices who often use Linux or BSD as the foundation
of their
boxes.

Back in 1994 we started to see exponential growth of the
Internet
because the barrier to entry suddenly became much lower. It
was
financially feasible to buy a bunch of modems, terminal
server, Bay or
Cisco routers and a bunch of Linux/BSD servers. The
technology was
available cheap enough to encourage many people to take the
business
risk. In the interim, technology has advanced somewhat and I
expect to
see a flurry of devices as soon as IPv4 exhaustion reaches
the general
press.

--Michael Dillon

Hi Alain,

On Fri, 28 Sep 2007 08:45:58 -0400
"Durand, Alain" <Alain_Durandcable.comcast.com> wrote:

> The IETF thinking for the last 10+ years (and I include
myself in this) had been that dual stack was the answer and
most things would be converted to dual stack before we ran
out of v4.
> 
> Well, it has not happen.
> 
> There is still very little v6 deployment and we will be
running out of v4 space soon (instantiate soon by your
particular prediction of the day you won't be able to get
space from your RIR, either because there is no more or
because you do not qualify any longer).
> 

I don't think it has happened because in the past there
hasn't been a
compelling reason to. End-users haven't seen any benefit, so
they
haven't asked for it, and service providers (who of course
provide
services to those end-users) haven't been able to justify
the investment,
because their end-users/customers haven't been asking for
it.

If IPv4 addressing runs out, and the only way to grow the
Internet is
to implement IPv6, then the service providers who've made
the IPv6
investment provide access to more services i.e. both IPv4 +
IPv6 based,
will win customers from their competing service providers.

I think the loss of customers to competitors would create a
compelling
reason for service providers to introduce and migrate to
IPv6, and I
think a "better Internet experience" (I've been
around Internet
marketing people too long) i.e IPv4+IPv6 visible content
would be the
compelling reason for customers to move to service providers
who're
providing access to both protocols.

> Given the above, it is clear that we are gong to see
devices (which might be dual stack *capable*) that will be
deployed and provisionned with *v6-only*...
> 
> At the edge of the network, where we have devices by
the millions and where address space is a critical issue and
dual-stack is a non starter, this is already under way...
> 
> It is also becoming apparent that:
> 
> - the "core internet" (ie the web and any
infrastructure server) will take a long time to move to v6
and/or dual stack.
> 
> - new v6-only edges will have to communicate with it.
So we need v6->v4 translation in the core
> 

MPLS as well as the IETF softwires techniques (the MPLS
model without using MPLS i.e. tunnel from ingress to egress
via
automated setup tunnels - gre, l2tp, or native IPv4 or IPv6)
can or
will shortly be able to be used to tunnel IPv6 over IPv4 or
vice versa.
softwires in effect treats the non-native core
infrastructure as an
NBMA layer 2.

The advantage of these techniques verses dual stack is that
they push
the complexity of dual stack to the network ingress and
egress devices. 

Dual stack isn't all that complicated, however when you
think about
running two forwarded protocols, two routing protocols or an
integrated
one supporting two forwarded protocols, having two
forwarding
topologies that may not match in the case of dual routing
protocols,
and having two sets of troubleshooing methods and tools, I
think the
simplicity of having a single core network forwarding
protocol and
tunnelling everyting else over it becomes really attractive.
The price is
the tunnel overhead of course, however, processing wise that
price is only paid
at the edges, making it scalable, and in the core, the
bandwidth cost
of the tunnel overhead is minimal, because the network core
typically
has all the high bandwidth links. 

> - legacy v4 PCs (think win95 up to win XP) using
RFC1918 addresses behind a home gateway  will never be able
to upgrade to an IPv6-only environment. So if we provision
the home gateway with v6-only (because there will be a point
where we do not have any global v4 addresses left for it)
those legacy PCs are going to need a double translation,
v4->v6 in the home gateway and then v6 back to v4 in the
core. Note: a double private v4->private v4->global v4
translation would work too, but if you are running out of
private space as well, this is also a non-starter...
> 

While it probably won't be a huge amount, getting rid of
forwarding
based on end-node IPv4 destination address out of the core
will help
with this a bit. I wonder if anybody has done a study as to
how much
public IPv4 address space is consumed by infrastructure
addressing.

> - there are a number of internal deployment cases where
net 10 is just not big enough, thus the idea to use v6 to
glue several instances of private space together as a 'super
net 10'. For this to work, legacy devices that cannot
upgrade to v6 need to go through a translation v4->v6.
> 

I'm guessing you might be in part talking about your cable
modem
management problem that I've seen an IPv6 presentation of
yours about.

Is it really necessary to have global reachability to all
your
customer's CPE for management purposes across the whole of
your
network? Would it be possible to have e.g. 3 large
management regions,
each with their own instance of network 10, and then make
the
infrastructure robust enough that there'd be much bigger
problems with
your network if the need to remotely manage one group of CPE
from
another management region became necessary?

> So, no, NAT v4->v6 or v6-v4 does not solve world
hunger but solve very real operational problems.
>

I suppose we have to weigh up whether the NAT can of worms
is worth
openning again with IPv6 to solve operational problems, and
losing the
chance to have the benefits of end-to-end principle back
again for all
the end-users of the Internet. I've experienced and seen too
many cases
where the hidden costs of NAT became unhidden. In those
instances,
"throwing" public address space at the problem
would have instantly
destoyed the problem NAT was causing. In IPv4 we have to be
a bit
careful doing that these days, in the future, with IPv6, we
don't.

Regards,
Mark.

>     - Alain.
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: Jari Arkko <jari.arkkopiuha.net>
> To: Durand, Alain
> Cc: Randy Bush <randypsg.com>; nanognanog.org
<nanognanog.org>
> Sent: Fri Sep 28 00:25:11 2007
> Subject: Re: WG Action: Conclusion of IP Version 6
(ipv6)
> 
> Randy, Alain,
> 
> >
> >     o nat-pt with standardized algs for at least
dns, smtp, http, sip, and
> >     rtp
> >
> >
> > -->> This is on my top 3 hot topics. And
make it works both way, v4 to
> > v6 and v6 to v4.
> > And also don’t call it NAT-PT. That name is
dead.
> 
> For what it is worth, this is one of the things that I
want
> to do. I don't want to give you an impression that
NAT-PT++
> will solve all the IPv6 transition issues; I suspect
dual stack
> is a better answer. But nevertheless, the IETF needs
to
> produce a revised spec for the translation case. Fred
and
> I are organizing an effort to do this.
> 
> Jari
> 


-- 

        "Sheep are slow and tasty, and therefore must
remain constantly
         alert."
                                   - Bruce Schneier,
"Beyond Fear"

> MPLS as well as the IETF softwires techniques (the MPLS
model without
> using MPLS i.e. tunnel from ingress to egress via
automated setup
> tunnels - gre, l2tp, or native IPv4 or IPv6) can or
will shortly be
> able to be used to tunnel IPv6 over IPv4 or vice versa.
softwires in
> effect treats the non-native core infrastructure as an
NBMA layer 2.
> 
> The advantage of these techniques verses dual stack is
that they push
> the complexity of dual stack to the network ingress and
egress
> devices.
> 
> Dual stack isn't all that complicated, however when you
think about 
> running two forwarded protocols, two routing protocols
or an
> integrated one supporting two forwarded protocols,
having two
> forwarding topologies that may not match in the case of
dual routing
> protocols, and having two sets of troubleshooing
methods and tools, I
> think the simplicity of having a single core network
forwarding
> protocol and tunnelling everyting else over it becomes
really
> attractive.

huh?  and your tunnels do not have *worse* congruency
problems than dual
stack?  gimme a break.

randy

On Sat, 29 Sep 2007 14:45:23 -1000
Randy Bush <randypsg.com> wrote:

> > MPLS as well as the IETF softwires techniques (the
MPLS model without
> > using MPLS i.e. tunnel from ingress to egress via
automated setup
> > tunnels - gre, l2tp, or native IPv4 or IPv6) can
or will shortly be
> > able to be used to tunnel IPv6 over IPv4 or vice
versa. softwires in
> > effect treats the non-native core infrastructure
as an NBMA layer 2.
> > 
> > The advantage of these techniques verses dual
stack is that they push
> > the complexity of dual stack to the network
ingress and egress
> > devices.
> > 
> > Dual stack isn't all that complicated, however
when you think about 
> > running two forwarded protocols, two routing
protocols or an
> > integrated one supporting two forwarded protocols,
having two
> > forwarding topologies that may not match in the
case of dual routing
> > protocols, and having two sets of troubleshooing
methods and tools, I
> > think the simplicity of having a single core
network forwarding
> > protocol and tunnelling everyting else over it
becomes really
> > attractive.
> 
> huh?  and your tunnels do not have *worse* congruency
problems than dual
> stack?  gimme a break.
> 

I do not understand what you mean.

The tunnelled traffic takes the same ingress-to-egress path
through the
core that it would if the core natively supported the
tunnelled payload
protocol.

This is the basic BGP/MPLS model, using IPv4, IPv6, GRE or
L2TP as the
encapsulation, instead of MPLS. 

Regards,
Mark.

-- 

        "Sheep are slow and tasty, and therefore must
remain constantly
         alert."
                                   - Bruce Schneier,
"Beyond Fear"

On Sun, 30 Sep 2007 10:54:34 +0930
Mark Smith <nanog85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org&
gt; wrote:

> On Sat, 29 Sep 2007 14:45:23 -1000
> Randy Bush <randypsg.com> wrote:
> 
> > > MPLS as well as the IETF softwires techniques
(the MPLS model without
> > > using MPLS i.e. tunnel from ingress to egress
via automated setup
> > > tunnels - gre, l2tp, or native IPv4 or IPv6)
can or will shortly be
> > > able to be used to tunnel IPv6 over IPv4 or
vice versa. softwires in
> > > effect treats the non-native core
infrastructure as an NBMA layer 2.
> > > 
> > > The advantage of these techniques verses dual
stack is that they push
> > > the complexity of dual stack to the network
ingress and egress
> > > devices.
> > > 
> > > Dual stack isn't all that complicated,
however when you think about 
> > > running two forwarded protocols, two routing
protocols or an
> > > integrated one supporting two forwarded
protocols, having two
> > > forwarding topologies that may not match in
the case of dual routing
> > > protocols, and having two sets of
troubleshooing methods and tools, I
> > > think the simplicity of having a single core
network forwarding
> > > protocol and tunnelling everyting else over
it becomes really
> > > attractive.
> > 
> > huh?  and your tunnels do not have *worse*
congruency problems than dual
> > stack?  gimme a break.
> > 
> 
> I do not understand what you mean.
> 
> The tunnelled traffic takes the same ingress-to-egress
path through the
> core that it would if the core natively supported the
tunnelled payload
> protocol.
> 
> This is the basic BGP/MPLS model, using IPv4, IPv6, GRE
or L2TP as the
> encapsulation, instead of MPLS. 
> 

It's also the RFC1772 BGP encapsulation model (section
"A.2.3
Encapsulation"), with the difference being the end-node
traffic
sources and sinks are the ingress and egress peers, rather
than
an AS worth of them. The model isn't very new at all.
 

> Regards,
> Mark.
> 
> -- 
> 
>         "Sheep are slow and tasty, and therefore
must remain constantly
>          alert."
>                                    - Bruce Schneier,
"Beyond Fear"


-- 

        "Sheep are slow and tasty, and therefore must
remain constantly
         alert."
                                   - Bruce Schneier,
"Beyond Fear"

On Sat, 29 Sep 2007 15:37:50 -1000
Randy Bush <randypsg.com> wrote:

> > The model isn't very new at all.
> 
> no it isn't.  many of us remember atm-1, so atm-2 is no
big surprise.
> 

I'd argue it's not the quite same situation. From what I
understand of
the way ATM/IP was deployed (ATM core, IP routers at the
edge with
direct IP adjacencies over ATM PVCs), the ATM topology
wasn't visible
to the IP layer. The IP layer then wasn't able to make
informed path
decisions for IP traffic, yet it had no choice but to take
responsibility for choosing those forwarding paths, because
that's it's
function.

The model we're talking about seems to me to be that old
model on
it's head. The devices at the edge of the core network are
fully aware
of the underlying topology of the core network so they can
make
informed forwarding decisions. The tunnelling encapsulation
only serves
the purpose of transporting protocols/payloads, that aren't
native in
the core, from edge-to-edge. The tunnelling function doesn't
try to
control or have to take responsibility for the selecting
paths taken
across the core.

Regards,
Mark.

-- 

        "Sheep are slow and tasty, and therefore must
remain constantly
         alert."
                                   - Bruce Schneier,
"Beyond Fear"

On Sun, 30 Sep 2007 10:41:01 +0200
Per Heldal <heldaleml.cc> wrote:

> On Sun, 2007-09-30 at 11:40 +0930, Mark Smith wrote:
> > The model we're talking about seems to me to be
that old model on
> > it's head. The devices at the edge of the core
network are fully aware
> > of the underlying topology of the core network so
they can make
> > informed forwarding decisions. The tunnelling
encapsulation only serves
> > the purpose of transporting protocols/payloads,
that aren't native in
> > the core, from edge-to-edge. The tunnelling
function doesn't try to
> > control or have to take responsibility for the
selecting paths taken
> > across the core.
> 
> This is just is a slight move of the core/edge
boundary. Core switching
> capabilities (MPLS) have been added to edge devices
which were pure
> terminal-devices from an ATM-perspective. The
MPLS-cloud is just as
> obscure as ATM to a non-MPLS-speaking IP-device. 
> 

No it isn't. The MPLS control plane runs IP routing
protocols, so even
if an upstream device isn't capable of MPLS forwarding, it
still has
visibility to the network topology information both
propagated across
and within the MPLS domain. For conventional IP forwarding,
MPLS is a
forwarding optimisation, not a forwarding replacement. 

Regards,
Mark.

-- 

        "Sheep are slow and tasty, and therefore must
remain constantly
         alert."
                                   - Bruce Schneier,
"Beyond Fear"