1.
White
Paper
Service
Provider
Transition
to
IPv6:
NAT,
NAT64,
6RD,
DS-­‐LITE
and
Carrier
Grade
IPv6
Email:
fred@fredbovy.com

2. Service
Provider
Transition
to
IPv6
2
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
Table
of
Contents
1
Introduction:
Transition
Technologies
Needed
for
Decades
........................................
3
2
Dual-­‐Stack
..................................................................................................................
3
3
Network
Address
Translation
.....................................................................................
3
3.1
Network
Address
Translation
from
NAT
to
NPT6
................................................................................
3
3.1.1
IPv4
to
IPv4
Translation:
NAT
or
NAT44
..................................................................................................
3
3.1.2
IPv6
to
IPv6
Translation:
NAT66
to
NPT6
................................................................................................
4
3.1.3
Network
Address
Translation
from
NAT-­‐PT
to
NAT464
....................................................................
5
3.1.4
IPv4
to
IPv4
Translation:
Double
NAT
or
NAT444
...............................................................................
5
4
Tunneling
...................................................................................................................
8
4.1
IPv4
in
IPv6
Tunneling
+
NAT
(LSN):
DS-­‐Lite
.........................................................................................
8
4.2
IPv6
in
IPv4
Tunneling
...................................................................................................................................
10
4.2.1
IPv6
in
IPv4
Static
Tunnels
...........................................................................................................................
10
4.2.2
IPv6
in
IPv4
Automatic
Tunnels
.................................................................................................................
10
4.3
IPv6
in
IPv4
MPLS
Tunneling
......................................................................................................................
12
5
Carrier
Grade
IPv6
(CGv6)
.........................................................................................
12
5.1
Network
Address
Translation
.....................................................................................................................
12
5.2
Tunneling.
............................................................................................................................................................
12

3. Service
Provider
Transition
to
IPv6
3
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
1 Introduction:
Transition
Technologies
Needed
As
connected
devices
become
more
pervasive,
available
IPv4
addresses
decline
and
soon
will
be
completely
depleted.
IPv6
has
been
around
for
more
than
10
years
and
supported
by
most
operating
systems
and
network
vendors.
Despite
this,
most
service
providers
and
companies
have
not
transitioned
to
this
next
generation
Internet
protocol.
As
a
consequence,
more
time
is
needed
to
allow
a
smooth
transition
to
IPv6.
Because
of
this,
you
may
need
to
support
mixed
IPv4
and
IPv6
networks
for
a
few
more
years.
Maximum
performance,
security,
and
other
benefits
will
be
achieved
once
the
transition
to
IPv6
is
complete.
Meanwhile,
features,
performance,
and
security
will
have
to
be
compromised
in
order
to
support
IPv4
nodes
and
applications.
There
are
three
transition
methods:
-­‐ Dual-­‐stack
-­‐ Network
Address
Translation
(NAT44,
NAT64,
DNS64,
NAT444,
NAT464)
-­‐ Tunneling
(6rd,
DS-­‐Lite,
6PE,
6VPE)
This
paper
discusses
each.
2 Dual-­‐Stack
Dual-­‐stack
is
the
preferred
transition
method.
All
workstation
and
server
operating
systems
(Windows,
MAC,
Linux)
come
configured
as
dual-­‐stack
by
default.
When
a
host
needs
to
transmit
a
packet,
it
sends
a
DNS
Request
to
get
an
address.
If
the
DNS
reply
includes
both
IPv6
and
IPv4
addresses,
it
will
prefer
the
IPv6.
The
only
drawback
of
this
method
is
the
duplicated
effort
to
maintain
IPv4
and
IPv6
concurrently.
Also,
you
must
apply
the
same
level
of
security
to
both
protocols
or
you
may
risk
that
IPv4
will
be
used
to
discover
the
nodes
and
IPv6
will
be
used
to
breach
security
if
the
IPv6
security
is
not
as
strong
as
IPv4
security.
3 Network
Address
Translation
When
the
Internet
community
became
concerned
about
IPv4
address
depletion,
they
created
workarounds.
These
workarounds
included
classless
interdomain
routing
(CIDR)
or
variable-­‐length
subnet
masking
(VLSM)
to
save
addresses,
Dynamic
Host
Configuration
Protocol
(DHCP)
for
better
address
management,
and
Network
Address
Translation
(NAT).
3.1 Network
Address
Translation
from
NAT
to
NPT6
3.1.1 IPv4
to
IPv4
Translation:
NAT
or
NAT44
Introduced
in
the
mid-­‐90s
to
support
private
addressing,
NAT
and
NAT44
extended
the
life
of
IPv4
by
making
people
think
that
address
depletion
would
no
longer
be
an
issue.
However,
NAT
also
introduced
some
side
effects—both
good
and
bad.
RFC2993
discusses
the
architectural
implications,
advantages,
and
problems
of
NAT.

4. Service
Provider
Transition
to
IPv6
4
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
On
one
hand,
NAT
broke
the
end-­‐to-­‐end
IP
model.
Applications
that
must
be
supported,
like
DNS
or
FTP,
require
NAT
software
updates
(application
layer
gateway
[ALG]).
For
more
details
about
ALG,
see
RFC2663:
NAT
Terminology
and
Considerations.
When
an
inside
host
must
be
reachable
from
an
outside
public
space,
it
consumes
a
public
address
and
a
static
translation
must
be
configured.
Some
users
see
this
as
a
security
feature.
IPv4
firewalls
usually
do
NAT,
but
a
NAT
router
is
not
a
firewall!
Stateful
NAT
is
a
bottleneck,
a
single
point
of
failure,
and
can
be
the
target
of
denial
of
service
(DoS)
attacks.
On
the
other
hand,
with
NAT
and
private
addresses,
users
are
not
constrained
by
public
addresses
(address
independence).
NAT
also
permits
obscuring
the
end
user
network.
Hiding
topology
and
hosts
makes
some
people
think
that
NAT
is
an
important
security
feature.
For
these
reasons,
some
architects
will
not
consider
a
network
design
without
NAT!
RFC6092
provides
recommendations
for
implementing
security
in
an
IPv6
network.
This
document
also
differentiates
between
actual
security
and
the
features
of
NAT
gateways.
3.1.2 IPv6
to
IPv6
Translation:
NAT66
to
NPT6
With
the
introduction
of
IPv6
and
its
128-­‐bit
addresses,
NAT
was
no
longer
needed
to
provide
a
unique
address
to
Internet
users
and
the
end-­‐to-­‐end
IP
model
was
restored.
Larger
address
space
was
a
main
driver
for
IPv6.
The
introduction
of
NAT66
into
IPv6
was
a
frustration
for
IPv6
proponents.
In
addition
to
its
well-­‐known
problems,
NAT66
broke
the
security
implemented
by
IPSec
by
changing
the
IPv6
header.
But
proponents
of
NAT
did
not
like
that
NAT
benefits
were
missing
from
IPv6
and
also
argued
that
NAT
could
solve
the
multihoming
issue.
After
much
discussion
and
an
RFC
to
document
everything,
the
IETF
rejected
the
proposed
NAT66
drafts.
RFC5902
discusses
the
pros
and
cons
of
NAT66.
It
tries
to
justify
the
request
for
NAT66:
« 2. What is the problem?
The discussions on the desire for IPv6 NAT can be summarized as
follows. Network address translation is viewed as a solution to
achieve a number of desired properties for individual networks:
avoiding renumbering, facilitating multihoming, making configurations
homogenous, hiding internal network details, and providing simple
security. »
RFC4864
explains
IPv6
solutions
to
the
NAT66
claimed
benefits
without
requiring
any
address
translation.
NAT
supporters
were
not
deterred.
They
responded
by
developing
a
simplified
stateless
NAT66
that
was
renamed
Network
Prefix
Translation
or
NPT6,
which
was
approved
in
RFC6296.

5. Service
Provider
Transition
to
IPv6
5
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
3.1.3 Network
Address
Translation
from
NAT-­‐PT
to
NAT464
3.1.3.1 NAT-­‐PT
(RFC2766)
For
transitioning
to
IPv6,
Network
Address
Translator-­‐Protocol
Translator
(NAT-­‐PT)
was
the
first
protocol
translation
method
implemented
by
Cisco
IOS.
NAT-­‐PT
equates
to
NAT64
+
NAT46
+
ALG.
NAT64
is
the
NAT
translation
initiated
by
the
IPv6
side,
and
NAT46
was
initiated
by
the
IPv4
side.
NAT-­‐PT
was
the
answer
for
all
the
cases,
but
it
consumed
many
resources
and
IOS
running
NAT-­‐PT
was
process
switching
with
the
very
low
performances
we
know.
Use
of
NAT-­‐PT
is
now
deprecated
(RFC4966).
3.1.3.2 NAT64/DNS64
3.1.3.2.1 What
is
the
problem
we
want
to
solve?
Workstations
run
dual-­‐stack
by
default.
Equipment
using
Windows,
MAC
OS,
and
Linux
operating
systems
is
set
up
with
dual
stack
by
default.
It
is
not
difficult
to
upgrade
a
workstation
if
it
runs
an
old
operating
system
without
dual
stack.
From
the
initialization
side,
IPv6
support
is
not
the
problem.
On
the
other
hand,
it
may
be
more
difficult
to
upgrade
an
application
to
support
IPv6.
3.1.3.2.2 DNS64
(RFC6147)
NAT64
relies
on
DNS64
to
manage
the
DNS
request
and
send
a
reply
to
the
source
with
an
IPv6
prefix
built
from
the
IPv4
address
received
from
the
target
node.
DNS64
first
sends
a
request
for
a
AAAA
prefix.
If
it
receives
an
error,
it
then
tries
to
ask
an
A
prefix.
Then
if
it
receives
an
answer,
DNS64
converts
it
to
a
AAAA
IPv6
prefix.
This
IPv6
address
is
built
using
a
NAT64
well-­‐known
prefix
(64:FF9B::/96)
followed
by
the
IPv4
address
coded
as
an
IPv6
address.
The
A
record
with
193.45.5.1
address
will
be
converted
to
the
AAAA
record
with
64:FF9B::193.45.5.1
or
64:FF9B::C12D:501
address.
3.1.3.2.3 Stateless
or
Stateful
NAT64
The
packet
from
the
source
is
routed
to
the
NAT64
box
using
the
normal
IPv6
routing.
The
NAT64
box
translates
the
IPv6
packet
to
an
IPv4
packet
and
sends
it
to
the
target.
It
also
performs
the
opposite
when
the
answer
comes
back
from
the
IPv4
host.
NAT64
can
be
stateless
(see
RFC6052)
or
stateful
(see
RFC6145,
RFC6146
and
RFC6052).
Stateless
means
that
an
IPv4
address
is
needed
for
each
translated
IPv6
address.
Stateful
is
required
if
multiple
IPv6
addresses
must
map
to
the
same
IPv4
address.
3.1.4 IPv4
to
IPv4
Translation:
Double
NAT
or
NAT444
NAT
at
the
CPE
has
already
permitted
to
IPv4
to
last
for
20
more
years
and
now
the
ISPs
are
starting
to
use
NAT
one
more
time
at
the
next
level
with
NAT444.
NAT444
refers
to
double
NAT,
where
NAT44
is
performed
a
first
time
by
the
CPE
at
the
customer’s
site
and
then
a
second
time
by
the
service
provider.
Carrier-­‐grade
NAT
(CGN)
and
large-­‐
scale
NAT
(
LSN)
refer
to
NAT
running
at
the
service
provider
instead
of
the
CPE.

6. Service
Provider
Transition
to
IPv6
6
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
Figure
1.
NAT
444
A
device
in
a
customer
network
might
send
a
packet
to
an
Internet
destination
with
a
source
address
of
10.1.1.1.
The
CPE
NAT
translates
the
source
address
to,
for
example,
172.16.1.1
with
accompanying
port
mapping.
At
the
LSN,
the
source
address
is
translated
to
the
public
IPv4
address,
say
201.15.83.1
again
with
port
mapping,
and
the
packet
is
routed
to
the
destination.
Responding
packets
to
201.15.83.1
are
routed
to
the
service
provider’s
aggregate
IPv4
address,
then
to
the
appropriate
LSN,
which
translates
the
destination
address
back
to
172.16.0.1
and
forwards
the
packet
to
the
corresponding
CPE
NAT,
which
translates
the
destination
address
to
10.1.1.1.
This
looks
simple,
but
this
design
is
not
without
issues.
One
issue
is
scalability.
Behind
the
CPE,
the
customer
may
be
running
many
devices.
Each
device
may
generate
many
data
streams.
There
is
not
yet
enough
production
experience
to
know
the
upper
boundaries
of
how
many
customer
networks
a
single
LSN
can
manage,
either
in
terms
of
performance
or
in
terms
of
mapping
steams
to
a
single
public
IPv4
address.
Also,
it
becomes
impossible
to
track
a
user
using
its
IP
address.
If
a
new
application
requires
an
ALG,
it
must
be
installed
by
the
SP.
Another
issue
is
the
possibility
of
address
overlaps
between
the
customer’s
network
and
the
private
addresses
used
by
the
service
provider.
For
example,
if
the
provider
uses
addresses
out
of
the
172.16.0.0/12
block
between
the
LSN
and
the
CPE
NAT,
and
the
customer
addresses
his
network
out
of
the
same
block,
uniqueness
between
the
two
zones
is
lost
and
packets
might
be
misrouted.
Insuring
that
customers
use
non-­‐
conflicting
address
ranges
can
be
an
administrative
headache
for
the
provider.

7. Service
Provider
Transition
to
IPv6
7
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
Figure
2.
Firewall
Blocks
Packets
with
Private
Source
Address
Yet
another
issue
occurs
when
a
customer
wants
to
send
packets
to
another
customer
behind
the
same
LSN.
Filtering
policies
in
firewalls,
router
ACLs,
and
even
servers
often
block
packets
from
outside
the
network
that
have
private
source
addresses.
To
circumvent
this
problem,
packets
must
pass
through
the
LSN
so
that
their
source
addresses
can
be
translated
to
a
public
address
and
then
switched
back
through
the
LSN
to
the
destination.
LSN
resources
are
consumed
even
though
the
packets
are
not
going
to
a
destination
beyond
the
LSN.
A
proposed
solution
to
these
problems
is
to
reserve
a
block
of
the
remaining
public
IPv4
space
as
an
“ISP
shared
address”
space.
Because
the
address
block
would
be
reserved
for
use
in
NAT444
architectures,
the
same
addresses
can
be
used
behind
different
LSNs
the
same
way
RFC1918
addresses
are
used
for
private
networks.
Because
the
address
would
not
be
RFC1918
addresses,
they
would
not
conflict
with
the
private
addresses
in
any
customer
network.
Also
because
they
are
not
RFC1918
addresses,
filtering
policies
will
not
block
them.
Packet
flows
between
customers
behind
the
same
LSN
will
not
have
to
pass
through
the
LSN.
Another
solution
is
to
use
IPv6
on
the
CPE
NAT-­‐to-­‐LSN
link;
this
is
NAT464.
It
will
go
in
the
good
direction
with
IPv6
between
the
customer
and
the
service
provider.

8. Service
Provider
Transition
to
IPv6
8
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
3.1.4.1 NAT464
A
problem
with
this
design
is
that
now
the
CPE
must
perform
NAT46
address
translation
instead
of
NAT44.
This
design
will
require
upgrading
all
the
CPEs,
which
is
an
expensive
solution.
Figure
3.
NAT464
4 Tunneling
There
are
a
few
choices
for
encapsulating
IPv4
in
IPv6,
IPv6
in
IPv4,
or
IPv6
in
MPLS
IPv4.
4.1 IPv4
in
IPv6
Tunneling
+
NAT
(LSN):
DS-­‐Lite
Because
all
customers
will
not
migrate
at
once
to
IPv6,
a
big
problem
for
service
providers
is
supporting
RFC1918
IPv4
customers
after
the
backbone
has
migrated
to
IPv6.
Dual
Stack
Lite
(DS-­‐Lite)
solves
this
with
IPv4
in
IPv6
tunneling
and
NAT44.
Another
problem
is
that
all
the
applications
will
not
migrate
to
IPv6
at
once
either
and
the
clients
will
need
to
run
IPv4
and
dual-­‐stack
for
a
while
to
access
the
IPv4
servers.
DS-­‐Lite
will
permit
this.
DS-­‐Lite
uses
the
IPv6
source
address
of
the
tunnel
with
the
IPv4
source
address
and
the
source
port
number
to
identify
each
tunnel
source
endpoint.
Without
this,
there
would
be
no
way
to
differentiate
two
overlapping
customers
using
the
same
RFC1918
private
address.

9. Service
Provider
Transition
to
IPv6
9
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
Figure
4.
DS-­‐Lite
IPv4
in
IPv6
Tunnel
Figure
5.
DS-­‐Lite
=
IPv4
in
IPv6
Tunnel
+
LSN

10. Service
Provider
Transition
to
IPv6
1
0
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
Figure
7.
IPv6
Routed
Directly.
IPv4
Routed
to
LSN.
4.2 IPv6
in
IPv4
Tunneling
IPv6
in
IPv4
was
the
first
overlay
tunnel
used
during
the
transition
to
IPv6.
The
first
experimental
IPv6
network,
the
6BONE,
was
created
from
overlay
tunnels
connecting
IPv6
islands
across
the
IPv4
Internet.
IPv6
in
IPv4
tunnels
can
be
statically
or
automatically
configured.
4.2.1 IPv6
in
IPv4
Static
Tunnels
For
IPv6
in
IPv4
static
tunnels
or
6in4
static,
you
must
configure
the
tunnel
source
and
destination
IPv4
addresses.
This
is
the
least
unsecure
option
as
you
can
control
the
source
and
destination
of
the
tunnel.
If
possible,
use
IPSec
to
secure
these
tunnels.
4.2.2 IPv6
in
IPv4
Automatic
Tunnels
With
automatic
tunnels,
you
don’t
need
to
configure
the
IPv4
destination
of
the
tunnel.
Automatic
tunnels
also
provide
IPv6
addressing.
Teredo
and
Intra-­‐Site
Automatic
Tunnel
Addressing
Protocol
(ISATAP)
automatic
tunnels
are
not
intended
for
service
providers
and
are
not
discussed
here.
4.2.2.1 6to4:
The
Origin
(RFC3056)
The
first
popular
automatic
tunnels
were
6to4.
These
tunnels
solved
two
problems:
IPv6
addressing
and
automatic
destination
tunnel
configuration.
They
provided
the
reserved
IPv6
prefix—2002::/16.
Following
this
prefix
was
the
6to4
gateway
public
IPv4
address.
This
way,
the
destination
IPv4
address
of
the
tunnel
was
coded
in
the

11. Service
Provider
Transition
to
IPv6
1
1
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
destination
IPv6
address.
For
instance,
if
a
6to4
gateway
public
IPv4
address
was
193.2.4.5,
the
IPv6
site
that
would
be
reachable
from
this
6to4
gateway
would
use
the
prefix
2002:193.2.4.5::/48
or
2002:c102:405::/48.
Microsoft
provided
6to4
relays
on
the
Internet
using
the
IPv4
anycast
address
192.88.99.1
for
anyone
using
6to4
to
have
access
to
the
IPv6
Internet
from
IPv4.
For
ISPs,
the
biggest
problem
with
6to4
is
the
lack
of
flexibility
due
to
the
fixed
2002::/16
prefix.
6to4
also
lacks
basic
security
features
(RFC3964).
6to4
is
now
deprecated.
4.2.2.2 6rd:
The
Next
Generation
(RFC5969)
Free
Telecom,
a
French
ISP,
customized
the
code
of
a
6to4
platform
to
accept
any
ISP
prefix
instead
of
2002::/16
and
provided
instant
IPv6
access
to
their
customers.
They
provided
the
relays
to
access
the
IPv6
Internet
and
called
this
6rd
for
IPv6
Rapid
Deployment.
6rd
became
the
de
facto
standard
for
service
providers
with
an
IPv4
backbone
to
provide
IPv6
service
to
their
customers.
6rd
was
implemented
in
Cisco
IOS
Software
Release
15.1(3)T
and
is
documented
in
RFC5969.
Figure
6.
6rd,
6to4
with
a
Customized
Prefix

12. Service
Provider
Transition
to
IPv6
1
2
Fred
Bovy
Transitionn
to
IPv6
22/08/11
2:03
PM
fred@fredbovy.com
Fred
Bovy
EIRL
–
Ipv6
For
Life!
©
2012
4.3 IPv6
in
IPv4
MPLS
Tunneling
For
service
providers
with
an
IPv4
MPLS
backbone,
the
transition
methods
are
IPv6
Provider
Edge
Router
(6PE)
and
IPv6
VPN
Provider
Edge
Router
(6VPE).
6PE
is
for
the
transport
of
IPv6
on
top
of
MPLS
IPv4.
6VPE
adds
the
support
of
IPv6
in
MPLS-­‐VPN.
The
VRF
can
be
dual-­‐stack.
Both
are
stable,
efficient,
and
scalable
methods
to
provide
IPv6
services
over
an
IPv4
MPLS
backbone.
While
6PE
and
6VPE
are
important
transition
methods
for
service
providers,
they
are
not
discussed
in
this
white
paper.
5
Carrier
Grade
IPv6
(CGv6)
CGv6
is
the
Cisco
solution
to
support
service
providers
during
the
transition
to
IPv6.
CGv6
runs
on
a
dedicated
carrier-­‐grade
service
engine
on
the
CRS-­‐1.
CGv6
is
also
available
on
Cisco
ASR
9000
with
IOS-­‐XR
and
Cisco
ASR
1000
with
Cisco
IOS-­‐XE
Software.
5.1 Network
Address
Translation
CGv6
supports
double
NAT444
where
NAT44
is
performed
at
the
CPE
and
again
at
the
service
provider.
CGv6
also
supports
Address
Family
Translation
or
IVI,
which
represents
the
Roman
numerals
for
4
(IV)
and
6
(VI);
in
other
words,
NAT46
and
NAT64.
5.2 Tunneling.
CGv6
supports
6rd
and
DS-­‐Lite.
For
more
information
about
the
Cisco
CGv6
solution,
visit
http://www.cisco.com/go/cgv6
and
http://www.ccmi.com/IPv6/Cisco_CGv6.pdf
Fred BOVY, CCIE #3013
fred@fredbovy.com