This document discusses IPv6 transition mechanisms. It describes the drivers for IPv6 adoption due to IPv4 address exhaustion and growing demand. It then covers some of the challenges of migration, including updating systems like DNS servers, billing, security, and support systems. It also outlines some transition technologies like dual stack, 6RD tunneling, DS-Lite, and NAT64. Specifically, it discusses using NAT444/LSN to mitigate IPv4 exhaustion in the short term but notes the challenges it poses for applications and user control. It provides a Junos configuration example of NAT444 LSN topology and configuration.

1. IPv6:
Transi-on
mechanisms
Nicolai
van
der
Smagt
Network
Design
Engineer
Infradata
Netherlands
BV
nicolai@infradata.nl

2. The
obligatory
slide:
IPv6
drivers
! Internal
driver:
IPv4
address
space
exhaus-on
! Today
there’s
no
more
global
(IANA)
address
space
available
! RIPE
and
ARIN
have
just
a
couple
of
/8’s
leP,
APNIC
is
down
to
its
last
/8
! Service
providers
are
hoarding
IPv4
addresses,
but
those
will
not
last
forever
! External
driver:
Demand
for
IPv6
access
and
content
! End-­‐users
are
asking
for
IPv6
access,
and
this
growing
demand
for
IPv6
access
forces
content
owners
to
be
reachable
over
IPv6
! World
IPv6
day
successful
! “World
IPv6
launch”
date
approaching
(6-­‐6-­‐2012)
! Google,
Facebook,
YouTube,
Yahoo,
Bing
and
others
start
to
announce
AAAA
records
globally
! Access
providers
such
as
XS4All
extend
IPv6
service
! “You’re
the
only
one
asking
for
it”
will
not
suffice
much
longer

3. IPv6
migra6on:
The
hard
part
! Bear
in
mind
that
network
migra-on
may
be
the
easy
part
of
an
IPv6
migra-on
strategy…
! DNS
Servers
! Provisioning
systems
! Metered
billing
systems
! Security
systems
and
policies
! Address
assignment
systems
(Radius/DHCP)
! Accoun-ng
systems
! Lawful
intercept
! Tracing/logging
! Support
systems
(fault,
inventory,
performance
management)
! Tes-ng
equipment
and
networks
(lab)
! Test
procedures
! Yellow
s-ckies
on
the
side
of
terminal
in
NOC

4. IPv6
migra6on:
Strategies
! Conserva-ve:
! Retain
IPv4
paradigm
as
much
and
as
long
as
possible:
! ….
! ….
! ….
! Progressive:
! Deploy
IPv6
progressively
and
get
rid
of
IPv4
as
soon
as
commercially
possible:
! ….
! ….
! ….

5. IPv6
migra6on:
Technologies
! Help
mi-gate
IPv4
address
exhaus-on
! NAT444/LSN
(Large
Scale
NAT)
! Help
IPv6
deployment
! Dual
stack
! 6RD
(IPv6
Rapid
Deployment)
and
other
tunneling
techniques
! Mi-gate
IPv4
address
exhaus-on
and
help
IPv6
deployment
! DS-­‐Lite
(Dual
stack
Lite)
! NAT64

6. IPv4
address
exhaus6on:
NAT444
LSN
-­‐
Large-­‐Scale
NAT
! NAT444
LSN
enables
the
SP
to
use
private
IPv4
space
for
customer
assignment,
thus
reducing
the
need
for
public
IPv4
addresses
! NAT444
LSN
adds
a
layer
of
NAT
(Network
Address
Transla-on)
on
the
edge
of
the
SP
network.
Customer
traffic
is
subject
to
this
layer
of
NAT
! NAT444
LSN
doesn’t
really
help
IPv6
adop-on,
it
only
delays
the
inevitable
! Unfortunately,
NAT444
LSN
provides
unique
challenges:
! RFC
1918
space
(private
IP
space)
collisions
! End-­‐user
internal
space
and
SP
space
could
collide
! End-­‐user
to
end-­‐user
communica-ons
need
to
be
hairpinned
through
LSN
box
! Using
NAT
breaks
applica-ons,
dual-­‐layer
NAT
exacerbates
these
problems:
! ALGs
are
necessary
! Even
with
ALGs
applica-ons
break
! Forensic
logging
is
more
complex,
geo-­‐loca-on
breaks,
etc.
! NAT
space
is
shared;
policing
required
! NAT
layer
is
an
extra
point-­‐of-­‐failure
in
the
network
(network
state
→
vulnerable
for
DoS
aiacks)
! End-­‐user
control
over
port-­‐forwarding
is
limited,
and
complex
from
security
point
of
view
(there’s
the
PCP
draP)

7. IPv4
address
exhaus6on:
PCP
-­‐
Port
Control
Protocol
! PCP
is
upcoming
technology
(IETF
draP)
designed
to
address
the
problem
that
end
users
have
no
control
over
LSN
! PCP
enables
applica-ons
to
receive
incoming
connec-ons
over
a
NAT444
connec-on
! Instead
of
working
around
NAT
like
other
traversal
techniques
(like
STUN),
PCP
enables
an
explicit
dialog
between
applica-ons
and
the
NAT
! PCP
can
be
seen
as
a
carrier-­‐grade
evolu-on
of
UPnP-­‐IGD
and
NAT-­‐PMP

8. IPv4
address
exhaus6on:
NAT444
LSN
ISP
RFC1918
IPv4
network
Wireless
device
is
provisioned
with
private
IPv4
Two
levels
of
NAT
break
applica-ons
expec-ng
incoming
connec-ons
NAT
NAT
RFC1918
IPv4
in
the
customer
networks
IPv4
Impact:
! Double
NAT
! Applica-ons
that
cannot
adapt
will
break
! Liile
end
user
control
over
LSN
(port
forwards)
! NAT
entails
risk
for
scalability
and
availability

9. NAT444
LSN
Junos
config
example
-­‐
topology
10.0.0.0/8
CPE
CPE
CPE
CPE
9.0.0.2
9.0.0.1
128.0.0.1/24
129.0.0.2/24
NAT
pool:
+-­‐-­‐-­‐+
;
129.0.0.0/24
CGN
●
●

10. NAT444
LSN
Junos
config
example
part
1
interfaces
{
ge-­‐1/3/5
{
descrip-on
“***
inside
***”;
unit
0
{
family
inet
{
service
{
input
{
service-­‐set
sset2;
}
output
{
service-­‐set
sset2;
}
}
address
9.0.0.1/24;
}
}
}
ge-­‐1/3/6
{
descrip-on
“***
outside
***”;
unit
0
{
family
inet
{
address
128.0.0.1/24;
}
}
}
sp-­‐5/0/0
{
descrip-on
“***
mul-service
DPC
***”;
unit
0
{
family
inet;
}
}
}
Interfaces

11. NAT444
LSN
Junos
config
example
part
2
services
{
nat
{
pool
p1
{
address
129.0.0.0/24;
port
automa-c
random-­‐alloca-on;
}
rule
r1
{
match-­‐direc-on
input;
term
t1
{
from
{
source-­‐address
{
10.0.0.0/16;
10.1.0.0/16;
}
}
then
{
translated
{
source-­‐pool
p1;
transla-on-­‐type
{
source
dynamic;
}
}
}
}
}
}
service-­‐set
sset2
{
nat-­‐rules
r1;
interface-­‐service
{
service-­‐interface
sp-­‐5/0/0;
}
}
}
NAT

12. NAT444
LSN
Junos
config
example
part
3
services
{
ids
{
rule
r1
{
match-­‐direc-on
input;
term
t1
{
then
{
session-­‐limit
{
by-­‐source
{
maximum
1000;
}
}
}
}
}
}
applica-ons
{
applica-on
custom_hip
{
protocol
tcp;
des-na-on-­‐port
80;
inac-vity-­‐-meout
300;
}
}
Protec6on

13. IPv6
deployment:
6RD
! 6rd
enables
an
IPv6
host
to
reach
an
IPv6
server
via
an
IPv4
only
network
! Similar
to
many
other
tunneling
mechanisms
before
it
! It
doesn’t
really
help
you
with
IPv4
to
IPv6
migra-on
! 6rd
doesn’t
help
an
IPv4
host
who
cannot
obtain
a
public
IP
address
reach
the
IPv4
internet
! Either
host
s-ll
needs
to
have
a
public
IPv4
address
! So
where’s
the
value?
! 6RD
is
useful
only
when
Time-­‐To-­‐Market
of
IPv6
deployment
is
of
cri-cal
importance
! 6RD
enables
IPv6
services
before
the
edge
network
has
been
made
IPv6
aware
! 6RD
is
moving
towards
the
end
of
its
lifecycle
and
new
IPv6
deployments
should
use
more
structural
solu-ons

14. IPv6
deployment:
6RD
IPv6
host
RG
Web
server
IPv6
server
Impact:
• End
users
can
buy
IPv6
service
without
network
changes
• A
“quick
fix”
that
may
weaken
focus
on
the
real
issues
• Customers
will
think
you’re
retarded
for
providing
tunnelled
service
(it’s
2012!!)
Tunneled
IPv6
Public
IPv6
internet
IPv4
internet

15. IPv6
deployment:
Dual
stack
! Dual
stack:
Run
IPv4
and
IPv6
service
simultaneously
on
the
same
network
! Is
the
best
way
to
deploy
IPv6
service
from
technical
point
of
view
(na-ve,
end-­‐to-­‐end
connec-vity,
DNS
decides
which
stack
to
use)
! But
it
doesn’t
help
against
IPv4
address
exhaus-on
! CAPEX
hungry:
Network
resources
(memory),
possible
hardware
upgrades
! OPEX
hungry:
OA&M
complexity

16. Dual
stack
IPv6
deployment:
Dual
stack
IPv4
&
IPv6
ISP
network
Wireless
device
is
provisioned
with
IPv4
&
IPv6
CPE
are
provisioned
with
global
IPv4
&IPv6
Requires:
! Full
IPv6
access
network
! IPv6
ready
back
office
! IPv6
CPE
IPv6
IPv4

17. IPv6
deployment:
DS-­‐lite
LSN
! DS-­‐lite
provides
the
end
user
with
simultaneous
v4
and
v6
service
! And
it
enables
SP
to
use
a
single-­‐stack
IPv6
network
! And
it
solves
the
problem
of
IPv4
address
exhaus-on
! ..
So
what’s
the
catch?
! Some
of
the
disadvantages
of
NAT444
LSN
apply
to
DS-­‐lite
LSN
! RG
needs
to
be
DS-­‐lite
aware
(hopefully
via
firmware
upgrade)
! Hardly
any
commercial
deployment
today,
RG
soPware
can
be
immature

18. IPv6
deployment:
DS-­‐lite
LSN
ISP
IPv6
network
Dual
stack
wireless
device
provisioned
only
with
IPv6
CPE
are
provisioned
only
with
IPv6
IPv4
&
IPv6
Requires:
! IPv6
access
network
! DS-­‐Lite
aware
IPv6
CPE
v4inv6
tunnel
IPv6
traffic
flows
directly
AFTR
The
IPv4
NAT
func-on
is
moved
from
CPE
to
SP
network:
Only
one
level
of
NAT
IPv6
IPv4

19. DS-­‐Lite
LSN
Junos
config
example
-­‐
topology
Internet
AFTR
concentrator
NAT
Home
router
128.0.0.1
129.0.0.1
2001:0:0:2::1
10.0.0.2
10.0.0.1
IPv4
host
ISP
IPv6
cloud
network
B4
2001:0:0:1::1
IPv4-­‐in-­‐IPv6
soPwire
Host

20. DS-­‐Lite
LSN
Junos
config
example
part
1
interfaces
{
ge-­‐3/1/0
{
descrip-on
“***
Outside
***”;
unit
0
{
family
inet
{
address
128.0.0.2/24;
}
}
}
ge-­‐3/1/5
{
descrip-on
“***
Inside
***”;
unit
0
{
family
inet;
family
inet6
{
service
{
input
{
service-­‐set
sset;
}
output
{
service-­‐set
sset;
}
}
address
2001:0:0:2::1/48;
}
}
}
}
sp-­‐0/0/0
{
unit
0
{
family
inet;
family
inet6;
}
}
}
Interfaces

21. DS-­‐Lite
LSN
Junos
config
example
part
2
services
{
nat
{
pool
p1
{
address
129.0.0.1/32;
port
{
automa-c;
}
}
rule
r1
{
match-­‐direc-on
input;
term
t1
{
from
{
source-­‐address
{
10.0.0.0/16;
}
}
then
{
translated
{
source-­‐pool
p1;
transla-on-­‐type
{
napt-­‐44;
}
}
syslog;
}
}
}
}
}
NAT

22. DS-­‐Lite
LSN
Junos
config
example
part
3
soPwire
{
soPwire-­‐concentrator
{
ds-­‐lite
ds1
{
soPwire-­‐address
2001::1;
mtu-­‐v6
1460;
}
rule
r1
{
match-­‐direc-on
input;
term
t1
{
then
{
ds-­‐lite
ds1;
}
}
}
}
service-­‐set
sset
{
syslog
{
host
local
{
services
any;
}
}
soPwire-­‐rules
r1;
nat-­‐rules
r1;
interface-­‐service
{
service-­‐interface
sp-­‐0/0/0.0;
}
}
SoXwires

23. IPv6
migra6on:
What
about
content?
! Most
SPs
see
IPv6
content
availability
as
a
shared
responsibility
for
access
providers
and
content
providers:
! Access
providers
should
provide
a
means
to
get
to
IPv4-­‐only
content
on
IPv6
networks
! Content
providers
should
provide
content
owners
the
means
to
make
content
v6
aware
! NAT64
is
a
solu-on
for
access
to
the
“long
tail”
of
IPv4-­‐only
content,
for
content
_and_
access
providers
! Access
providers
can
setup
Address
Family
Transla-ng
Routers
(AFTR)
using
NAT64/
DNS64
to
provide
access
to
IPv4
content
to
their
na-ve
IPv6
speaking
end
users
! Content
providers
can
use
NAT64
in
front
of
their
load
balancing
(basically
you
end
up
with
IPv4
load
balancers
with
IPv6
VIP)
to
enable
IPv6
access
to
content
in
their
network
that
is
s-ll
IPv4
only

24. IPv6
transla6on:
NAT64/DNS64
! NAT64/DNS64
is
used,
when
the
network
is
IPv6,
but
we
s-ll
need
to
access
IPv4
content
! Disadvantage:
DNS64
won’t
help
with
numerical
IP
address
access
like
hip://66.102.13.99/
! Transla-on,
so
ALGs
are
needed
! Will
need
to
be
in
place
for
a
long
-me
(decades?
-­‐
IPv4
long
tail)
! Assumes
that
no
IPv4
service
to
end
users
is
available
anymore
! Today,
would
need
to
be
applied
to
lion’s
share
of
traffic
! Hardly
any
commercial
deployment
today
! “Endgame”

25. IPv6
only
service
IPv6
transla6on:
NAT64/DNS64
ISP
IPv6
network
Wireless
device
provisioned
only
with
IPv6
CPE
are
provisioned
only
with
IPv6
NAT64
! No
IPv4
devices
! No
IPv4
applica-ons
! No
IPv4
roaming
IPv4
IPv6
Requires:
! IPv6
access
network
! All
customers
devices
and
applica-ons
MUST
support
IPv6

26. IPv6
transla6on:
NAT64/DNS64
! DNS64
maps
“real”
IPv4
addresses
to
IPv6
addresses
from
a
specific
NAT64
range
! This
NAT64
range
is
routed
to
the
NAT64
AFTR
(Address
Family
transla-ng
Router)
! DNS64
needs
to
run
on
DNS
server,
or
host,
or
network
element
Network
DNS
Where’s
www.infradata.pl
?
Network
IPv4
Network
IPv6
Internet
IPv6
Internet
DNS
It’s
at
N/w
IPv6
Network
IPv4

27. IPv6
only
service
IPv6
transla6on:
NAT64
load
balancing
Wireless
device
provisioned
only
with
IPv6
CPE
are
provisioned
only
with
IPv6
NAT64
IPv4
IPv6
Requires:
! IPv6
access
network
! All
customers
devices
and
applica-ons
MUST
support
IPv6
ISP
IPv6
network
Content
IPv6
network
! No
IPv4
devices
! No
IPv4
applica-ons
! No
IPv4
roaming

28. NAT64
Junos
config
example
-­‐
topology
IPv6
network
Host
1
2001:
DB8::1
IPv4
network
Host
2
192.0.2.1
Name
server
(with
DNS64)
NAT64
ge-­‐1/3/5
ge-­‐1/3/6
R2

29. NAT64
Junos
config
example
part
1
interfaces
{
ge-­‐1/3/5
{
descrip-on
"***
Inside
***";
unit0
{
family
inet;
family
inet6
{
service
{
input
{
service-­‐set
sset3;
}
output
{
service-­‐set
sset3;
}
}
address
2001:DB8::1/64;
}
}
}
ge-­‐1/3/6
{
descrip-on
"****
Outside
****";
unit
0
{
family
inet
{
address
192.0.1.1/16;
}
}
}
Interfaces

30. NAT64
Junos
config
example
part
1
-­‐-­‐
CONTINUED
-­‐-­‐
sp-­‐5/0/0
{
services-­‐op-ons
{
syslog
{
host
local
{
services
any;
log-­‐prefix
XXXXXXXX;
}
}
unit
0
{
family
inet;
family
inet6;
}
}
Interfaces

31. NAT64
Junos
config
example
part
2
services
{
nat
{
pool
src-­‐pool-­‐nat64
{
address
203.0.113.0/24;
port
automa-c;
}
rule
nat64
{
match-­‐direc-on
input;
term
t1
{
from
{
source-­‐address
{
2001:DB8::0/96;
}
des-na-on-­‐address
{
64:FF9B::/96;
}
}
then
{
translated
{
source-­‐pool
src-­‐pool-­‐nat64;
des-na-on-­‐prefix
64:FF9B::/96;
transla-on-­‐type
{
source
dynamic;
des-na-on
sta-c;
}
}
}
}
}
}
}
NAT

32. NAT64
Junos
config
example
part
3
services
{
service-­‐set
sset3
{
syslog
{
host
local
{
services
any;
log
prefix
XXXSVC-­‐SETYYY;
}
}
nat-­‐rules
nat64;
interface-­‐service
{
service-­‐interface
sp-­‐5/0/0;
}
}
}
Service
set

33. IPv6
migra6on:
Strategies
! Conserva-ve:
! Retain
IPv4
paradigm
as
much
and
as
long
as
possible:
! NAT
444
LSN
to
baile
IPv4
exhaus-on
! When
na-ve
IPv6
becomes
a
must-­‐have,
deploy
IPv6
in
dual
stack
fashion,
core
to
edge
to
ensure
a
gradual
introduc-on
! Finally
transi-on
to
na-ve
IPv6,
and
deploy
NAT64
for
access
to
legacy
v4
content
! Progressive:
! Deploy
IPv6
progressively
and
get
rid
of
IPv4
as
soon
as
commercially
possible:
! Deploy
IPv6
network,
in
edge-­‐to-­‐core
fashion
to
speed
up
IPv6
service
delivery
! Deploy
DS-­‐lite
LSN
IPv4
service
over
na-ve
v6
network,
phasing
out
na-ve
IPv4
service
and
figh-ng
v4
exhaus-on
at
the
same
-me
! Eventually
transi-on
to
IPv6
only,
with
NAT64
for
access
to
legacy
v4
content
! Preferred
approach:
! Future-­‐proof
early
on
! Less
NAT
to
worry
about
(single
versus
double
NAT)
! Sa6sfy
IPv6
service
demand
early
on
! Avoids
dual
stack
scalability
and
OA&M
complexi6es

34. IPv6
migra6on:
Product
offerings
! Juniper
provides
support
for
LSN,
DS-­‐LITE
and
NAT64
on
their
MX
product
line
(needs
MS-­‐DPC
card,
some
inline
MPC
support
is
roadmap
item)
! A10
networks
has
support
for
LSN,
DS-­‐lite
and
NAT64
(-­‐load
balancing)
in
their
AX
product
line
! Cisco
supports
LSN
on
their
CRS
product
line
(requires
CGSE
card)
! Alcatel
Lucent
support
LSN
and
DS-­‐lite
on
the
7750
SR
product
line
(requires
MS-­‐ISA
card)

35. IPv6
migra6on:
Juniper
! MX-­‐series
routers
support
inline
transla-on
technologies
via
MS-­‐DPC
card
(capable
of
providing
many
other
services
as
well)
! These
are
numbers
for
NAT64,
NAT44
numbers
are
marginally
beier
! Max.
throughput
18
Gb/s
per
MS-­‐DPC
on
Junos
11.2
! Max.
8M
concurrent
sessions
per
MS-­‐DPC
on
Junos
11.2
! Up
to
250k
new
NAT
sessions
per
second
(“ramp-­‐up
rate”)
per
MS-­‐DPC
on
Junos
11.2
! Industry
leader
in
ALG
support:
! BOOTP,
DCE
RPC
and
DCE
RPC
portmap,
Exec,
FTP,
H.323,
ICMP,
IIOP,
Login,
NetBIOS,
NetShow,
RealAudio,
RPC
and
RPC
portmap,
RTSP,
Shell,
SNMP,
SQLNet,
TFTP,
Traceroute,
WinFrame
and
SIP

36. IPv6
migra6on:
A10
Networks
AX-­‐series:
! 64-­‐bit
SMP
capable,
linear
scaling
! 128M
concurrent
sessions
max.
on
AX5200
(up
to
3
NAT
sessions
per
single-­‐
port
L4
session
may
be
required)*
! Up
to
1.5M
new
NAT
sessions
per
second
on
AX5200
! Supports
LSN
with
Full-­‐cone
NAT,
hairpinning
for
P2P
reachability,
ALGs
for
FTP,
RTSP,
IPSEC,
PPTP/GRE
! High-­‐end
model
AX5200
=
$200k
list
price
! All
AX
models
provide
full
transla-on
features
*
Full-­‐cone
NAT
and
P2P
hairpinning
require
1
extra
session

37. IPv6
migra6on:
Cisco
! CRS-­‐series
routers
support
inline
transla-on
technologies
(LSN)
via
CGSE
card
on
CRS-­‐1
and
CRS-­‐3
! ASR
9000
not
yet
supported,
supposedly
roadmap
/
same
with
NAT64
and
DS-­‐Lite
! Max.
throughput
10
Gb/s
per
CGSE
on
IOS-­‐XR
3.9.1
! Max.
20M
concurrent
sessions
per
CGSE
on
IOS-­‐XR
3.9.1
! Up
to
1M
new
NAT
sessions
per
second
(“ramp-­‐up
rate”)
per
CGSE
on
IOS-­‐XR
3.9.1
! List
price
=
$120k
/
CGSE
+
MSC
(Modular
Services
Card,
required)

38. IPv6
migra6on:
Alcatel
Lucent
To
support
inline
transla-on
and
other
services,
a
MS-­‐ISA
card
is
required
The
following
numbers
are
for
NAT44
(NAT64
not
available):
! Max.
throughput
10
Gb/s
per
MS-­‐ISA
on
R9.0
soPware
! Max.
6M
concurrent
sessions
per
MS-­‐ISA
on
R9.0
soPware
! Up
to
64k
new
NAT
sessions
per
second
(“ramp-­‐up
rate”)
per
MS-­‐ISA
on
R9.0
soPware
! Max.
128k
DS-­‐Lite
endpoints
per
MS-­‐ISA
on
R9.0
soPware
! List
price
=
$???k
/
MS-­‐ISA
(+
requires
an
IOM
mothercard,
takes
up
1
MDA
slot)

39. IPv6
migra6on:
Conclusions
! IPv6
is
a
networking
technology,
but
the
biggest
challenges
may
not
be
in
the
networking
department
! If
you
can,
go
dual
stack!
! If
you
can’t
go
dual
stack
(because
of
IPv4
or
infrastructure
resource
shortage),
DS-­‐lite
is
an
airac-ve
alterna-ve
(but,
those
firmware
upgrades
L)
! NAT444
has
many
caveats
and
is
only
interes-ng
if
DS-­‐lite
or
true
dual
stack
is
unaiainable
due
to
opera-onal
issues
(usually
large
carriers)
! NAT64
looks
like
the
“endgame”
technology
that
will
unlock
IPv4
long-­‐tail
content
on
IPv6
only
networks