IPv6 Migration Plan

2018
IPv6 Migration/Deployment Plan
Mohammad Khalil
Eng-mssk.blogger.com
1/17/2018
Technical Document
TABLE OF CONTENTS
INTRODUCTION .................................................................................................... 3
IPV4 ADDRESSING STATUS ..................................................................................... 4
WHY IPV6............................................................................................................. 5
IPV6 BENEFITS ..................................................................................................... 6
IPV4 VS IPV6 ........................................................................................................ 7
IPV6 ADDRESSING ................................................................................................ 8
IPV6 ADDRESS ARCHITECTURE ............................................................................... 8
IPV6 ADDRESS ALLOCATION ................................................................................ 15
IPV6 PREFIX LENGTH CONSIDERATIONS ................................................................. 16
IPV6 MIGRATION ................................................................................................. 21
INTRODUCTION .................................................................................................. 21
IMPLEMENTATION/DEPLOYMENT ........................................................................... 22
DUAL STACK ...................................................................................................... 22
TUNNELING........................................................................................................ 23
ABOUT .............................................................................................................. 23
TUNNELS CONFIGURATIONS................................................................................. 25
Translation (NAT-PT) ................................................................................................................................................ 37
Static NAT-PT ............................................................................................................................................................. 38
Dynamic NAT-PT ........................................................................................................................................................ 38
NAT-PT restrictions ................................................................................................................................................... 38
IPv6 over MPLS .......................................................................................................................................................... 39
Introduction ................................................................................................................................................................. 39
Why IPv6 over MPLS .......................................................................................................................... 40

Eng-mssk.blogger.com Page 1 of 163
Technical Document
6PE 44
6VPE ....................................................................................................................................................... 45
CONFIGURATION EXAMPLES ................................................................................ 48

Dual stack ............................................................................................................................................. 48
Tunneling .............................................................................................................................................. 52
Manual .......................................................................................................................................................................... 52
GRE 57
6to4 61
ISATAP ......................................................................................................................................................................... 65
Translation ............................................................................................................................................ 69
NAT-PT ......................................................................................................................................................................... 69
MPLS ...................................................................................................................................................... 73
6PE 73
6VPE IOS ...................................................................................................................................................................... 91
6VPE IOS-XR ............................................................................................................................................................. 114
CARRIER GRADE NAT ........................................................................................ 141

Introduction ........................................................................................................................................ 141
NAT, PAT and overloading ............................................................................................................. 142
The NAT444 model ........................................................................................................................... 142
Carrier Grade IPv6 solutions ......................................................................................................... 144

NAT444 ....................................................................................................................................................................... 144
IPv6 over L2TP........................................................................................................................................................... 145
6RD 146
DS-Lite......................................................................................................................................................................... 146
AFT64 .......................................................................................................................................................................... 147
MIGRATION/DEPLOYMENT .................................................................................. 148

Infrastructure ..................................................................................................................................... 148
Technical Document
Implementing IPv6 ............................................................................................................................ 152
Proposed Solution ............................................................................................................................ 157
Introduction
This document aims to highlight some IPv6 addressing and deployment aspects and gives mainly the
service providers the ability to migrate to IPv6 smoothly

Technical Document
IPv4 addressing status
As known, the lack of IPv4 became a headache to all parties involved in running it, which required
alternative solutions to take place such as using NAT and other technologies in order to reserve as
much as possible, but as well that was not enough due to the growth in the information market
That was the reason to invent a new scheme for addressing which is IPv6
As can be seen from the below table and diagrams, IPv4 is exhausted and there is no space enough
for future needs (Data is taken from http://www.potaroo.net/tools/ipv4/index.html)
Figure: Projection of consumption of remaining RIR address pools

Technical Document
Figure: RIPE NCC address allocation rate

As well, there is a tool called IPv4 exhaustion counter that also shows the status of IPv4 addressing
which can be found in the below link:
http://inetcore.com/project/ipv4ec/index_en.html
Why IPv6
The IPv6 protocol was established because the number of IPv4 addresses was being depleted so
quickly. The IPv6 protocol creates a 128-bit address, four times the size of the 32-bit IPv4 standard,
providing infinitely more available IP addresses. This will accommodate all the smartphones, tablets
and other computers on the network, but also the coming proliferation of Internet-connected devices
including refrigerators, cars, and myriad sensors in homes, buildings and on IP networks.
Enterprises may not need to go IPv6 internally, but should consider that users will be accessing their
publicly facing websites with devices using IPv6, especially if they're using mobile devices. Websites
that haven't added IPv6 will perform more slowly when accessed by IPv6-enabled phones than those
with IPv6 because the traffic will need to translate by a mobile operator.
More core infrastructure applications are requiring IPv6, and at some point, major applications will
stop supporting IPv4. IPv6 has been enabled now for about six years in most operating systems, and
there are potential network design gains an enterprise can realize with IPv6 simply because of the
new address size.
How different is IPv6 from IPv4? It’s based on a colon-hexadecimal system, compared to IPv4 being
dotted-decimal. Besides its 128-bit number vs. IPv4's 32 bits, it has no broadcast-type message.

Technical Document
Those messages you know as broadcast in IPv4 are now link-local multicast. IPv6 also has a few
other operational differences from IPv4.
Some technologists may believe you can simply "turn on" IPv6, but that's not case. You may not
break your network, but there's a good chance some things will not work as they did before, or they'll
work different (generally slower) providing a poor user experience
IPv6 benefits
With IPv6, everything from appliances to automobiles can be interconnected. But an increased
number of IT addresses isn't the only advantage of IPv6 over IPv4. Below are the major benefits of
ensuring your hardware, software, and services support IPv6
1. More efficient routing
IPv6 reduces the size of routing tables and makes routing more efficient and hierarchical. IPv6 allows
ISPs to aggregate the prefixes of their customers' networks into a single prefix and announce this one
prefix to the IPv6 Internet. In addition, in IPv6 networks, fragmentation is handled by the source
device, rather than the router, using a protocol for discovery of the path's maximum transmission unit
(MTU)
2. More efficient packet processing
IPv6's simplified packet header makes packet processing more efficient. Compared with IPv4, IPv6
contains no IP-level checksum, so the checksum does not need to be recalculated at every router
hop. Getting rid of the IP-level checksum was possible because most link-layer technologies already
contain checksum and error-control capabilities. In addition, most transport layers, which handle end-
to-end connectivity, have a checksum that enables error detection.
3. Directed data flows
IPv6 supports multicast rather than broadcast. Multicast allows bandwidth-intensive packet flows (like
multimedia streams) to be sent to multiple destinations simultaneously, saving network bandwidth.
Disinterested hosts no longer must process broadcast packets. In addition, the IPv6 header has a
new field, named Flow Label, which can identify packets belonging to the same flow.
4. Simplified network configuration

Technical Document
Address auto-configuration (address assignment) is built in to IPv6. A router will send the prefix of the
local link in its router advertisements. A host can generate its own IP address by appending its link-
layer (MAC) address, converted into Extended Universal Identifier (EUI) 64-bit format, to the 64 bits of
the local link prefix.
5. Support for new services
By eliminating Network Address Translation (NAT), true end-to-end connectivity at the IP layer is
restored, enabling new and valuable services. Peer-to-peer networks are easier to create and
maintain, and services such as VoIP and quality of service (QoS) become more robust.
6. Security
IPSec, which provides confidentiality, authentication and data integrity, is baked into in IPv6. Because
of their potential to carry malware, IPv4 ICMP packets are often blocked by corporate firewalls, but
ICMPv6, the implementation of the Internet Control Message Protocol for IPv6, may be permitted
because IPSec can be applied to the ICMPv6 packets
IPv4 vs IPv6
The below table lists the high level differences and similarities between the two IP versions
Table: IPv4 vs IPv6
Aspect/Protocol version IPv4 IPv6

Address scope 32 bit 128 bit, multiple scopes
IP allocation Manual, Dynamic Host Manual, stateless address
Configuration Protocol (DHCP) autoconfiguration (SLAAC),
DHCP
Address types Unicast, multicast, broadcast Unicast and multicast
QoS Differentiated services, Differentiated services,
integrated integrated services, flow label
services
Multicast Internet Group Management Multicast Listener Discovery
Protocol (IGMP), Protocol- (MLD), PIM, MP-BGP
Independent Multicast (PIM),
Multiprotocol Border Gateway
Protocol (MP-BGP)
Security No built-in- support IPsec built in

Technical Document
IPv6 addressing
IPv6 address architecture
IPv6 addressing architecture is globally defined by RFC4291. To make the large address-space of
IPv6 scalable and ‘aggregate able’ in a proper way there are some policies, guidelines and
recommendations to be followed.
There are several RFCs that have been written that discuss IPv6 addresses including RFC4291,
RFC4193 and RFC5375 that define the IPv6 address architecture. Also, RFC5156 lists the special
use IPv6 address allocations.
The recent RFC5375 is the most comprehensive public document covering the recommended
practices for IPv6 address allocation.
IPV6 addresses are split in 3 categories:
 Unicast
 Anycast
 Multicast
A key difference with IPv4 is that an IPv6 interface is expected to have multiple IPv6 addresses
associated with it. IPv6 interfaces always have a link local address (LLA). An IPv6 interface also has
a unique local address (ULA) or globally unique address

Technical Document
Figure: IPv6 address space breakdown

Technical Document
Global Unicast addresses are reachable from across the Internet. Global addresses are allocated
from the regional registries (e.g., RIPE, ARIN, APNIC) and are all currently assigned out of the
2000::/3 block.
Provider Host
3 Bits 45 Bits 16 Bits 64 Bits
Global Routing Prefix Subnet Interface ID
001
Figure: IPv6 Global Unicast Address

Technical Document
A link local address is used for communications on a single link and packets with a link local source
or destination address are not forwarded by a router off that link. Link local addresses only have
meaning on that link. All link local addresses can be identified as starting with the FE80::/10 prefix. As
noted previously, all IPv6 interfaces have a link local address assigned to them.
128 Bits
0 Interface ID
64 Bits
1111 1110 10
FE80::/10
10 Bits
Figure: IPv6 Link Local Address (LLA)

Technical Document
Unique local addresses are reachable outside of a particular link, but they only have meaning inside a
limited scope or domain. Unique local addresses are not intended to be routable across the Internet.
They should be routable inside a particular site or customer domain. Unique local addresses are
analogous to RFC 1918 addresses in IPv4. The main difference between unique local addresses and
RFC 1918 space is that the unique local address space is intended to be globally unique.
128 Bits
Subnet ID
Global ID 41 Bits 16 Bits
Interface ID
1111 110
FC00::/7
7 Bits
Figure: IPv6 Unique Local Address (ULA)

Technical Document
128 Bits
Multicast Group ID – 112 Bits
64 Bits
1111 1111 Flags
F F 0 RP T Scope R = 1 = embedded RP , (then PT=11)
Flag = PT = 11 = Unicast based mapping

8 Bits 8 Bits
PT = 00 = IANA Multicast address
1 = Node
2 = Link
Scope = 5 = Site (depreceated)
8 = Organization
E = Global
Figure: IPv6 Multicast address

The flag bits determine if this IPv6 multicast group is a well-known multicast group defined by IANA or
if the group is ‘user defined’ mapping of unicast into multicast. IPv6 addressing has also the capability
to ‘embed’ the IPv6 address of the RP inside the mcast group, which remove the needs of RP static
configuration or announcement mechanism like BSR across the network.
The scope bits determine if the multicast group is local or global
As an example:
 FF::/8 is the IPv6 equivalent of 224/4

 FF02::1 is the IPv6 equivalent of the link local address 224.0.0.1
 FF3X::/32, SSM address range where X represents the scope bits
The following example shows how to build a ‘global unique’ multicast group by mapping a global
unicast IPv6 prefix (64bits) into the multicast address then 32 bits are left for the multicast groups.

Technical Document
Figure: IPv6 unicast to multicast mapping
With this mechanism (and the R bit flag), we can also map the IPv6 address of the RP into the
multicast group. As described below, the unicast prefix is mapped into multicast address and 4 bits
are reserved to assign the last bit of the RP IPv6 multicast. (15 RPs possible)
Figure: IPv6 multicast embedded RP format address

Technical Document
IPv6 address allocation
As known, services providers commonly get their IPv4 address pools from one of the RIRs whom
responsible for different geographical areas
RIPE is the one responsible to support Middle East area with any related addressing issues
RIPE website is listed below:

https://www.ripe.net/
Any service provider can request IPv6 subnet from RIPE by accessing LIR portal:
https://lirportal.ripe.net/
Usually IPv6 address ranges are assigned as below:
Figure: IPv6 address ranges assignment

Currently, IANA allocates address blocks to the regional registries. The registries in turn assign
address blocks to service providers. It is the service provider's responsibility to hand out addresses to
their respective customers. The current policy varies by region and in the most conservative case
dictates that an end user must go through their service provider to get IPv6 address space and
cannot directly approach the regional registry for IPv6 address space

Technical Document
Provider Assigned (PA) Provider Independent (PI)
2000::/3 2000::/3
IANA
/12 /12
Registries
/32 /48
ISP Org
/48
Enterprise
Figure: IANA IPv6 address space allocation
IPv6 prefix length considerations
There are two areas to consider when looking at IPv6 prefix lengths – segments that have end
stations and infrastructure segments.
For segments that have end stations connected to them, the addressing RFCs for IPv6 suggest that a
/64 prefix length be used. With 264 available addresses per segment, it is highly unlikely to see prefix
lengths shorter than /64 for segments that host end systems. A /64 segment prefix is also required if
stateless autoconfiguration is going to be used to assign the interface ID to the end stations. Secure
Neighbor Discovery and privacy extensions also require a /64 prefix.
There are many options available when assigning prefixes for network infrastructure. Network
planners could opt to be consistent across the network and deploy /64 prefixes for both network
Technical Document
infrastructure and host access segments. Network planners could also opt for a plan that uses prefix
lengths longer than /64. With all of these options available, there are no hard and fast rules available
for assigning prefixes to network infrastructure. At this stage in the address plan, network planners
should keep in mind the principles mentioned above – simplicity, aggregation, and growth.
Table below summarizes some guidelines to consider when assigning prefixes to a link. The rest of
the section adds some more background and detail to these considerations.
Figure: Link Level Prefix Concern

There are several potential issues when considering the use of prefixes longer than /64. A first area
of concern has to do with bit positions 71 and 72 (“u” and “g” bits respectively) in the IPv6 address.
These bits have an identified meaning and their value should be correctly set. Bit 71 identifies
whether or not the address is globally unique (‘1’) or locally assigned (‘0’) and bit 72 identifies
whether the address is unicast (‘0’) or multicast (‘1’). These bit positions are related to their functions

Technical Document
in the MAC address and to the EUI-64 address expansion process. Most IPv6 implementations do
not currently account for these bit settings. However, we should set bit 71 and 72 to ‘0’ in all /126 link
prefixes in order not to interfere with prefixes that have a predefined use (e.g.
2a00::4fff:0:501:c01:a001/126)
Ethernet MAC
address (48 Bits) 00 90 27 17 FC 0F
00 90 27 17 FC 0F
FF FE
64-Bit version 00 90 27 FF FE 17 FC 0F
Uniqueness of 000000X0 1 = Unique
the MAC Where X =
X=1 0 = Not Unique
EUI-64 address 02
00 90 27 FF FE 17 FC 0F
Figure: IPv6 EUI-64 address format
EUI-64 address format allow an IPv6 node to automatically build its IPv6 interface ID portion. As
shown above The EUI-64 uses the 48 bits of the MAC address and insert FFFE to build the 64bits of
interface ID.
Another consideration when using prefixes longer than /64 has to do with anycast addresses.
Network planners should avoid the use of an all zero interface identifier, which has been defined by
RFC4291 as the subnet router anycast address. The other anycast address to avoid is the reserved
IPv6 subnet anycast address defined in RFC2526. In this case, the last seven bits are reserved for
the anycast ID and the other bits of the identifier are set to 1.
Another addressing consideration comes into play if multicast is going to be used in the network and
rendezvous point (RP) information is going to be embedded in the multicast group per RFC 3956
(described previously). RFC 3956 requires a prefix length of /64 for the RP, so the RP IPv6 network

Technical Document
prefix should not be >64bits. This requirement must be accommodated when developing the overall
plan.
A last area of concern has to do with Intra Site Automatic Tunnel Address Protocol (ISATAP)
addresses.
ISATAP requires a /64 for use and it embeds the IPv4 address in the last 32 bits of the IPv6 address.
To complete the host interface identifier, ISATAP uses 0000:5efe. This sequence should be avoided
when considering prefix lengths longer than /64.
Host
192.168.1.1 address
Interface
ID
ISATAP
Unicast Prefix 0000:5EFE C0A8:0201 address
Can be Link-local or global ISATAP ID IPv4 address of host
Figure: IPv6 ISATAP address format

There are multiple thoughts on the prefix length for a Point to point link and there are conflicting RFCs
also written that confuses the administrators more. Due to that reason, the following table clarifies the
facts regarding each option and supporting evidence why they may or may not be relevant

Technical Document
Table: Network Infrastructure P2P Link Prefix Length Selection
k/64 /126 /127

Ping Pong could occur if a Theoretically optimal but still Old RFC 3627 and 5375
packet sent to an un-specified could result in a ping pong loop recommends using against
address /127 due to Subnet-Router
anycast but newer RFC 6164
Recommends using /127
Common use with overall Common use keeping IPv4 Cisco devices disables Subnet-
consistency to other LAN type of conservation mentality Router Anycast upon
blocks – IOS devices have a fix – IOS devices have a fix for configuration of a /127 address
for Ping pong loops Ping pong loops
Mandated by RFC 4443 to Mandated by RFC 4443 to Most vendor equipment do not
send a Code 3 Destination send a Code 3 Destination use or plan to use subnet-
Unreachable message to the Unreachable message to the router anycast
neighbor router neighbor router
Use this style, if operational Use this style, if operational Use this style, if operational
focus to keep the same length focus to keep the IPv4 /30 type focus to keep the IPv4 /31 type
across the board addressing semantics addressing semantics
A recommended approach for network infrastructure would be to implement /64, /126, and /128
prefixes.
A /128 is used for loopback addresses to identify network nodes. A /64 or a /126 is used for point-to-
point links such as serial or POS links. A /64 prefix scheme is the simplest scheme to implement. A
/126 prefix scheme allows for the most address conservation. At this point a choice needs to be made
between the simplicity of the /64 scheme and the potential complexity of the /126 scheme. /127 can
be used for P2P links if the equipment supports the RFC. The existing /126 subnet can be
renumbered to /127 without renumbering it

Technical Document
IPv6 Migration
Introduction
Fore sure no service provider , enterprise or wholesale provider will tear down its already existing
IPV4 network and replace it with IPv6 , not practical and even not doable
A lot of migration/implementation techniques has been invented to help networks smoothly transition
to deploying IPv6 among their infrastructure with each method/technique differently suites each

Technical Document
Implementation/Deployment
IPv6 transition techniques can be depicted in the below figure:
IPv6 Implementation
Dual Stack Tunneling Translation
Manual GRE
Point-to-Point IPv6 link
Point-to-Point IPv6
over an existing IPv4
link over an existing
network (Several
IPv4 network (only
protocols are
IPv6 is supported)
supported)
NAT-PT
6to4 6RD ISATAP

Point-to-Multipoint Point-to-Multipoint IPv6 Point-to-Multipoint
IPv6 link over an link over an existing IPv4 IPv6 link over an
existing IPv4 network network (Any range can existing IPv4 network
(Between devices at
(2002::16 to be used) be used)
the same site)
Figure: IPv6 Transition Techniques
Dual Stack
In dual-stack configuration, the device is configured for both IPv4 and IPv6 network stacks. The dual-

Technical Document
stack configuration can be implemented on a single interface or with multiple interfaces. In this
configuration, the device decides how to send the traffic based on the destination address of the
other device.
IPv4
Network Native
Dual-Stack IPv4 Site
Router
Dual-Stack Dual-Stack
Host
Site
IPv6
Network
Native
IPv6 Site
Figure: IPv4/IPv6 Dual-Stack
Tunneling
About
IPv6 is being introduced gradually rather than immediately into many networks. A typical scenario in
the transitional period is thus communication between IPv6 nodes on an IPv4 network. IPv6
communication needs to be transported over IPv4, that is, IPv6 needs to be tunneled into IPv4. This
means that the IPv6 data packet is encapsulated in an IPv4 packet. The IPv6 node itself or a gateway
wraps the IPv6 packet in IPv4 and sends it on its way. In doing so, it sets the protocol field in the IPv4
header to a value of 41

Technical Document
IPv6 packet
Upper layer Protocol Data Units

IPv6 Header
(e.g. TCP with payload)
IPv4 Header Upper layer Protocol Data Units

IPv6 Header
(protocol: 41) (e.g. TCP with payload)
IPv4 packet
Figure: IPv6 encapsulation in IPv4
The IPv6 header contains the IPv6 addresses of the end-to-end communication, (i.e., of the
communicating endpoints). The IPv4 header contains the source and destination addresses of the
endpoints within the IPv4 network. These endpoints can be the "real" endpoints of the IPv6
communication in certain tunneling mechanisms. Most of the time, encapsulation is handled by the
tunnel gateways. These are usually the border routers or firewalls of the local network.
From the point of view of an IPv6 packet, IPv4 encapsulation is nothing but ordinary encapsulation at
link-layer level, like in Ethernet. In such tunnel scenarios, completely different structures can exist for
the IPv6 network and the IPv4 network. For example, a complete IPv4 infrastructure, consisting of
many routers and network segments, can be transcended in a single hop between the source and the
destination from an IPv6 point of view.
The advantage of tunnel solutions is their flexibility in connecting individual IPv6 islands in the "IPv4
Ocean." Nevertheless, tunnel technologies are always going to be second choice compared to native
IPv6 communication, because they can be complex to configure and also prone to error. Thus, the
Teredo tunneling mechanism is regarded as only partially usable, because it does not work properly
in the majority of cases

Technical Document
Tunnels configurations
Similarly to VPN tunnels, IPv6 tunnels can connect remote locations on the network. RFC 4213
provides for the following tunnel configurations:
 Router-to-Router
 Host-to-Router and Router-to-Host
 Host-to-Host
Router-to-router tunnels connect IPv6 infrastructures via a single virtual hop in an IPv4-only
infrastructure. This is the simplest and most common case of a tunnel, because the tunnel
configuration is only needed on one or a few systems of the network, and the IPv6-only nodes do not
need to know about it. A typical example of router-to-router tunnel is a 6to4 tunnel. In many cases,
the tunnel connects two corresponding routers over the IPv4 Internet, in order to connect IPv6
networks across multiple locations
IPv4-only Infrastructre
IPv6 activated IPv6 activated
IPv6 over IPv4
infrastructre infrastructre
Tunnel
IPv6/IPv4 Router IPv6/IPv4 Router
IPv6-only (Tunnel IPv6-only
(Tunnel
Node Endpoint) Node
Endpoint)
Figure: Router to router tunneling
The host-to-router tunnel connects an IPv6/IPv4 node on an IPv4-only network with an IPv6/IPv4
router .To do this, the host uses a tunnel interface and appropriate routing entries (e.g., in the form of
the default gateway), which route the corresponding traffic to the tunnel interface. The tunnel
interface wraps the IPv6 packets in IPv4 packets and sends them to the IPv6/IPv4 router, which
forwards the IPv6 packets to the IPv6 destination. The way back (router-to-host) is similar. ISATAP is
a tunneling technology that works on this principle. This tunnel type is mainly used to connect IPv6
nodes within an enterprise network.

Technical Document
IPv6 activated
IPv6 over IPv4 Tunnel infrastructre
IPv6/IPv4 Router
IPv6/IPv4 (Tunnel IPv6 Node
Node Endpoint)
Figure: Router to host tunneling
A host-to-host tunnel connects the communicating endpoints directly with one another through an
IPv4 tunnel. The encapsulated IPv6 packet is unpacked again only at the endpoint of the
communication. This principle is also used in ISATAP tunneling technologies and is used to support
communications between two IPv6 nodes within an IPv4 network.
Tunnel types
Basically two different types of IPv6 tunnels are available: configured tunnels and automatic tunnels.
With configured tunnels, the administrator needs to set up the tunnel manually on the tunnel
endpoints. In this case, the IPv4 destination address of the remote endpoint is not embedded in the
IPv6 address, as is typically the case with automatic tunnels. Configured tunnels use manually
created tunnel interfaces that define fixed source and destination addresses.
Automatic tunnels
No manual configuration is necessary for automatic tunnels. The tunnels are set up dynamically when
needed; the IPv4 destination addresses are typically embedded in the IPv6 address. Tunnel
technologies include:
 6to4: Used to connect IPv6 nodes on the IPv4 Internet.

 6rd: A development of 6to4 without the restriction of statically defined 6to4 prefixes.
 ISATAP: For connecting IPv6 nodes on an IPv4 intranet.
 Teredo: Allows the connection of IPv6 nodes through NAT.

Technical Document
6to4
6to4 can act as a router-to-router, host-to-router, and router-to-host tunnel. However, you will typically
build the tunnel as a router-to-router configuration. 6to4 treats the entire IPv4 Internet as a single link.
The prefix of 6to4 is 2002::/16, that is, it always begins with 2002. The use of a single address prefix
means you can always identify a 6to4 tunnel address. The next 32 bits of the address contain the
hexadecimal IPv4 address of the remote endpoints of the tunnel, which is a 6to4 router or 6to4 relay.
Next are the 16-bit subnet ID and the interface ID of the target system
16 Bits 32 Bits 16 Bits 64 Bits
Subnet
2002 IPv4 address of target Interface ID
ID
Figure: 6to4 target IPv4 address embed
Windows systems as of Windows Vista automatically create a 6to4 tunnel interface, if the system
uses a public IPv4 address on one of its interfaces and no other IPv6 connectivity (native or on
ISATAP) exists. In this case, the 6to4 tunnel interface is assigned an IPv6 address of
2002:WWXX:YYZZ::WWXX:YYZZ, where WWXXYYZZ stands for the public IPv4 address. If the
public IPv4 address of a Windows Server 2012-based computer is, for example, 131.107.1.1, then
the 6to4 tunnel address is 2002:836B:101::836B:101.
6to4 uses various components to handle different tasks, as follows:
 6to4 host: A native IPv6 host that has at least one 6to4 address (prefix 2002::/16) through
which it can be reached. This host does not have a 6to4 tunnel interface because it
communicates via IPv4. It is the endpoint of IPv6 communications routed via a 6to4 tunnel.
 6to4 router: An IPv6/IPv4 router that has a 6to4 tunnel interface, which it uses to forward
traffic between 6to4 hosts to another 6to4 router, 6to4 relay, or 6to4 host. 6to4 routers must
be configured appropriately – no matter which platform they use.
 6to4 host/router: An IPv6/IPv4 host that is connected directly to the Internet. In contrast to the
6to4 router, it forwards only its own traffic via 6to4 to other IPv6 nodes, not the traffic from
other systems.
 6to4 relay: In contrast to 6to4 routers, a 6to4 relay directs the traffic to the IPv6 Internet. This
means that a 6to4 relay must use BGP to connect to the Internet, while 6to4 routers connect a
specific IPv6 network.

Technical Document
Each 6to4 site has its own 6to4 prefix (2002:WWXX:YYZZ::/48). The rest of the 6to4 address defines
the subnet and the interface ID of the host on the network. From the perspective of a 6to4 host or
router, the entire 6to4 site is comprised of a single computer: itself
For a 6to4 router, the 6to4 site can comprise up to 65,536 subnets. In any case, it sees all the
subnets on the site. A 6to4 site can, on the other hand, comprise a single IPv4 address through which
the site is accessible. In its router advertisements, the 6to4 router propagates the 6to4 prefix to the
internal nodes so that 6to4 also works well with autoconfiguration.
The trick here is that the IPv4 address of the target host's site is embedded in the 6to4 address. The
stakeholder systems extract this address and use it to bridge the IPv4 part of the route. In the
example scenario from Figure 5, WKS1 wants to communicate with WKS2 and resolves the Fully
Qualified Domain Name (FQDN) of WKS2. The DNS server returns the address 2002:9D3C:101:F::1.
From the prefix, WKS1 sees that this is a 6to4 address.
6to4
Router
6to4 Network
6to4
Router 6to4 tunnel
6to4 Network IPv4 Infrastructure
6to4 tunnel
IPv4 Network
6to4
Relay
Figure: 6to4 tunneling
6RD
In contrast to 6to4, 6rd uses end customer prefixes, instead of a separate prefix of its own. This
feature contributes to the success of 6rd.
The data for the communications is transported between internal and external IPv6-only nodes that
are connected via the IPv4 Internet by the provider's own 6rd relays. The provider retains full control
over IPv6 communications crossing its networks and can therefore also use its own prefixes.

Technical Document
Because the public IPv4 address of the 6rd relay must be communicated here, too, it is also
embedded in the IPv6 address.
Provider Network
IPv6 over IPv4

Tunnel
IPv6
IPv6/IPv4 IPv4 GW
Node IPv4
GW
6to4
Relay
6to4 tunnel
Figure: 6RD tunneling
One special feature of 6rd is the fact that the prefix assigned to a provider is variable, so, in the case
of longer prefixes, there are not enough bits in the IPv6 address. If the provider receives a standard
prefix (/32) from the Regional Internet Registry (RIR), it can accommodate the IPv4 address in the
following 32 bits. But, the provider can only provide a single subnet to the customer, because the last
64 bits of the IPv6 address are reserved for the interface ID. In the case of FREE, the provider later
received a /26 prefix. The address was divided so that the IPv4 hex address was embedded after the
prefix; then two reserved bits followed, and, finally, the 4-bit subnet ID.
Another approach to the problem of saving static bits for the purpose of supporting longer provider
prefixes is to omit redundant parts of the IPv4 address. If a provider, for example, always uses a
specific /18 subnet for its customers, the provider can omit the first 18 bits of the IPv4 address without
losing any relevant information. The 6rd technique is an interesting approach with the potential of
replacing the legacy 6to4 system in the medium term.

Technical Document
ISATAP
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is used for host-to-host, host-to-
router, and router-to-host connections. Router-to-router connections are not envisaged. ISATAP is
used to connect IPv6/IPv4 nodes over an IPv4 infrastructure on an enterprise network. This protocol
is not designed for connecting over the Internet. ISATAP should not be used on production networks,
because it is primarily used for testing purposes
ISATAP
Enabled
Router
IPv4 hosts with ISATAP IPv6-only hosts

configured interfaces
IPv4 network Native IPv6
Figure: ISATAP tunneling
ISATAP is defined in RFC 5214 and requires no manual configuration on the hosts. It was developed
by Cisco and Microsoft, but it is also supported by Linux. Like 6to4, ISATAP uses a virtual tunnel
interface that is created automatically and assigned an IPv6 address. An arbitrary Unicast/64 prefix
can be used (including link-local). The IPv4 address of the corresponding LAN interface is embedded
at the end of the interface ID. Depending on whether they are global or private, according to RFC
1918, ISATAP addresses have the following format:
 Global addresses: 64-bit Unicast prefix:200:5EFE:w.x.y.z

 Private addresses: 64-bit Unicast prefix:0:5EFE:w.x.y.z
Here, w.x.y.z stands for an IPv4 address in the normal dotted decimal notation. A possible ISATAP
address would be, for example, 2001:db8:200:5EFE:85.25.66.51. The ISATAP tunneling interface
views the IPv4 part of the network as a single link-layer segment, in a similar way to Ethernet. From
the point of view of ISATAP, link-layer encapsulation is thus handled by IPv4.
A Windows system creates a separate ISATAP tunneling interface for each LAN interface, which
receives its own DNS suffix (and thus resides on a separate subnet). The ISATAP interfaces initially
have a status of "Disconnected" from Vista SP1 onward, as long as the ISATAP name cannot be

Technical Document
resolved. This DNS name resolves to the IPv4 address of an ISATAP router. If "ISATAP" can be
resolved, the following happens:
The ISATAP interfaces assign themselves a link-local address: FE80::5EFE:w.x.y.z or

FE80::200:5EFE:w.x.y.z.
The ISATAP hosts use the ISATAP tunneling interface to send a router solicitation message unicast
via IPv4 to the IPv4 address of the ISATAP router.
The ISATAP router responds with an IPv4 router advertisement unicast to the IPv4 address of the
ISATAP host, in which it announces itself as the default gateway and propagates the prefix for the
ISATAP subnet. This can be a global unicast or a unique local prefix.
Communication with the router is handled via IPv4 unicast. The normal approach of using IPv6
multicast is not available for exchanging router solicitation and advertisement messages. IPv4
multicast cannot be used, because it would require an IPv4 multicast infrastructure across subnets.
The ISATAP router on an ISATAP network is mandatory for initial activation of the ISATAP tunneling
interfaces. However, it does not need to assign prefixes because, in a local ISATAP segment, the
ISATAP hosts can communicate via their link-local addresses. The ISATAP router can also connect
ISATAP hosts with a native IPv6 part of an enterprise network. However, this approach requires a
global unicast or unique local prefix, which must be assigned via router advertisements. In this case,
the ISATAP hosts can use their autoconfigured addresses to communicate with IPv6 nodes outside
of their own ISATAP subnet, by using the ISATAP router as the default gateway. In contrast to
ISATAP hosts, the ISATAP router must be configured manually.
ISATAP has the advantage on Windows of being quickly implemented. The disadvantage is that
communication is limited to the corporate network and not designed for communication with systems
on the Internet. Additionally, ISATAP is not suitable for use in many NAT scenarios
Teredo
6to4 offers an IPv6 tunnel over the IPv4 Internet, but it has the disadvantage that the 6to4 router
always needs an official IPv4 address. If the router resides behind a NAT device, 6to4 does not work.
This is where Teredo comes into its own. Teredo is a tunneling technology developed by Microsoft
that is used, in particular, with Microsoft environments. However, a Teredo implementation is
available for Linux. Incidentally, the name is derived from Teredo navalis, which is the name for a
shipworm
Teredo is defined in RFCs 5991 and 4380 and provides IPv6 tunnels for IPv6 nodes that reside
behind NAT devices and are not 6to4 routers. To do this, Teredo does not just tunnel IPv6 packets in
IPv4 but also in UDP. Thus, the original IPv6 packet is transported by UDP as a payload, which

Technical Document
improves the chances of getting through a NAT device. In principle, the tunneled packet can also
pass through multiple NAT stages.
The NAT types play an important role. RFC 3489 distinguishes between the following types:
 Cone NAT: There is a 1-to-1 mapping between internal and external addresses, which can
accordingly also be addressed from external locations.
 Restricted NAT: Contact from the outside is only possible if a connection was previously set
up from the inside.
 Symmetric NAT: The internal address can be assigned to different external addresses and is
therefore not clearly identifiable from the outside.
In practice, however, this distinction is only a guideline, because many NAT routers use a hybrid
approach. Teredo basically works with Cone NAT and Restricted NAT. Teredo defines the following
components:
 Teredo clients: These are IPv6/IPv4 nodes that support Teredo tunneling interfaces (as of
Windows XP SP1).
 Teredo servers: IPv6/IPv4 nodes that are connected to both IPv4 and to the IPv6 Internet.
They assign Teredo prefixes and help the Teredo clients to contact other Teredo clients or
IPv6-only nodes. Teredo servers listen by default on port 3544/UDP.
 Teredo relays: IPv6/IPv4 routers that forward packets from Teredo clients on the IPv4 Internet
to the IPv6 Internet. They work partly with Teredo servers.
 Host-specific Teredo relay: This relay is also connected to the IPv6 and IPv4 Internet. If an
IPv6 node is also IPv4-capable, it can communicate directly over IPv4 with the Teredo client
via a host-specific Teredo relay. In this case, no Teredo relay is needed, so there is no
communication on the IPv6 Internet.
The Teredo address consists of a 32-bit prefix (2001::/32), followed by the hexadecimal IPv4 address
of the Teredo server. The last 64 bits are split into three parts. The flags (16 bits) define, in particular,
the type of NAT. The encrypted external port (16 bits) states the port on which the internal Teredo
client is accessible from the outside through the NAT device. The Teredo server determines this by
analyzing the source port of the packets that reach it from the client and informs the client of the
result in the response packet. Because some NAT devices try to translate a port contained in the
payload to the internal port number, this value is XOR-encrypted. The last 32 bits contain the client's
encrypted external IPv4 address.

Technical Document
Teredo server Encrypted

Encrypted external
Teredo Prefix 2001 Flags external
IPv4 address port address
32 Bits 32 Bits 16 Bits 16 Bits 32 Bits
Figure: Teredo address encoding
Teredo addresses are assigned exclusively to Teredo clients. Teredo servers and relays only receive
native IPv4 or IPv6 addresses. Communication is now initiated by the Teredo clients via the Teredo
servers; the servers tell the clients which official IP addresses and ports they are visible on. Armed
with this information, the Teredo session leverages the NAT entries to be able to address the internal
systems from the outside. To keep the NAT sessions running, Teredo clients send bubble packets to
the Teredo servers at regular intervals. A bubble packet is an "empty" IPv6 packet encapsulated in an
IPv4 UDP packet.
If two Teredo clients want to communicate with each other on the same link, they use bubble packets
as a replacement for the neighbor discovery process to initiate the conversation. If a Teredo client
wants to communicate with another Teredo client on a remote site, the communication depends on
the NAT type.
If both nodes reside behind a Cone NAT, the systems can connect directly, because a connection
can be set up by any source IP address in line with the Cone NAT definition. However, if the nodes
are located behind routers using Restricted NAT, bubble packets must first be sent to the remote
sites and the Teredo server, which then initiates the connection. After the connection is opened, the
actual communication is routed directly between the two peers; the Teredo server only helps to set up
the connection.
Where a Teredo client connects with a native IPv6 node on the IPv6 Internet, the Teredo server also
acts as a router on the IPv6 Internet. Connections that need to be set up from the IPv6 Internet to a
Teredo client are implemented with the help of the nearest Teredo relay or host-specific relay.
These complex mechanisms make Teredo very slow when it comes to opening connections (because
of timeouts, etc.) and also unreliable, because connections can only be established under specific
conditions. Teredo is thus not suitable for production use right now.

Technical Document
Configured tunnels
Manual
In this case we will manually configure the tunnel between the boundary routers (IPv4/IPv6 enabled)
between the IPv6 sites over the IPv4 network
Manual IPv6IP Tunnel
IPv4
Network
IPv6 IPv6
Network Network
Figure: Manual IPv6IP tunnel
GRE
The GRE IPv6 Tunnels feature enables the delivery of packets from other protocols through an IPv6
network and allows the routing of IPv6 packets between private networks across public networks with
globally routed IPv6 addresses.
For point-to-point GRE tunnels, each tunnel interface requires a tunnel source IPv6 address and a
tunnel destination IPv6 address when being configured. All packets are encapsulated with an outer
IPv6 header and a GRE header

Technical Document
GRE Tunnel IPv6 Network

IPv6 Network
IPv6 Header Data IPv6 Header Data
IPv4 Header GRE Header IPv6 Header Data
Figure: GRE tunnel
Restrictions for GRE IPv6 tunnels
 GRE tunnel keepalive packets are not supported.

 Multipoint GRE (mGRE) IPv6 tunneling is not supported.
 There is limited support for tunnel transport in virtual routing and forwarding (VRF). The limited
support in VRF is applicable to IPv6 point-to-point GRE without tunnel protection.
The table below to help you determine which type of tunnel that you want to configure to carry IPv6
packets over an IPv4 network
Table 2: Suggested usage of tunnel types
Tunneling Type Suggested Usage Usage Notes

Manual Simple point-to-point tunnels Can carry IPv6 packets only
that can be used within a site
or between sites
GRE Simple point-to-point tunnels Can carry IPv6, Connectionless
that can be used within a site Network Service (CLNS), and
or between sites many other types of packets
IPv4-Compatible Point-to-multipoint tunnels Uses the ::/96 prefix. We do not
recommend using this tunnel
type
6to4 Point-to-multipoint tunnels that Sites use addresses from the
can be used to connect 2002::/16 prefix
isolated IPv6 sites

Technical Document
6RD IPv6 service is provided to Prefixes can be from the SP’s

customers over an IPv4 own address block
network by using encapsulation
of IPv6 in IPv4
ISATAP Point-to-multipoint tunnels that Sites can use any IPv6 unicast
can be used to connect addresses
systems within a site
After deep studying and evaluation of migration caveats, network administrator can use the below
table to guide him through tunnel configuration parameters
Table 3: Tunnel configuration parameters
Tunneling Type Tunnel configuration parameter

Tunnel Tunnel source Tunnel Interface prefix
mode destination or address
Manual ipv6ip An IPv4 address, or a An IPv4 address An IPv6 address
GRE gre ip reference to an An IPv4 address An IPv6 address
IPv4-compatible ipv6ip auto- interface on which Not required. Not required. The
tunnel IPv4 is configured These are all interface address
point-to-multipoint is generated as
tunneling types. ::tunnel-
The IPv4 source/96
6to4 ipv6ip 6to4 destination An IPv6 address.
address is The prefix must
calculated, on a embed the tunnel
per-packet basis, source IPv4
from the IPv6 address
6RD ipv6ip 6rd destination An IPv6 address
ISATAP ipv6ip isatap An IPv6 prefix in
modified eui-64
format. The IPv6
address is
generated from
the prefix and the
tunnel source
IPv4 address
Note: Detailed configuration examples will be listed in later section

Technical Document
Translation (NAT-PT)
Network Address Translation (NAT)-Port Translation (PT) for Cisco software based on RFC 2766 and
RFC 2765 is a migration tool that helps customers transition their IPv4 networks to IPv6 networks.
Using a protocol translator between IPv6 and IPv4 allows direct communication between hosts that use
different network protocols. You can use static, dynamic, port address translation, IPv4-mapped
definitions for NAT-PT operation
The figure below shows that NAT-PT runs on a device that is configured between an IPv6 network and
an IPv4 network that helps connect an IPv6-only node with an IPv4-only node
IPv6
Network IPv4
NAT-PT
IPv6-only IPv4-only
Node Node
Figure: NAT-PT basic operation
NAT-PT allows direct communication between IPv6-only networks and IPv4-only networks. Dual-
stack networks (networks that have IPv4 and IPv6) can have some IPv6-only hosts configured to take
advantage of the IPv6 autoconfiguration, global addressing, and simpler management features, and
these hosts can use NAT-PT to communicate with existing IPv4-only networks in the same
organization.
One of the benefits of NAT-PT is that no changes are required to existing hosts if NAT-PT is
configured, because all NAT-PT configurations are performed at the NAT-PT device. Stable IPv4
networks can introduce an IPv6 network and use NAT-PT to communicate between these networks
without disrupting the network. For a seamless transition, you can use FTP between IPv4 and IPv6
hosts.
When you configure IPv6, packet fragmentation is enabled by default, to allow IPv4 and IPv6
networks to resolve fragmentation problems. Without the ability to resolve fragmentation, connectivity
can be intermittent when fragmented packets are dropped or not interpreted correctly.
We do not recommend the use of NAT-PT to communicate between a dual-stack host and an IPv6-
only or IPv4-only host. We do not recommend the use of NAT-PT in a scenario in which an IPv6-only
network tries to communicate with another IPv6-only network via an IPv4 backbone or vice versa,

Technical Document
because NAT-PT requires a double translation. You can use tunneling techniques for communication
in these scenarios.
You can configure one the following operations for NAT-PT, but not all four
Static NAT-PT
Static NAT-PT uses static translation rules to map an IPv6 address to an IPv4 address. IPv6 network
nodes communicate with IPv4 network nodes using an IPv6 mapping of the IPv4 address that is
configured on the NAT-PT device.
If you have multiple IPv6-only or IPv4-only hosts, you may need to configure multiple static NAT-PT
mappings. Static NAT-PT is useful when applications or servers require access to a stable IPv4
address, such as accessing an external IPv4 Domain Name System (DNS) server
Dynamic NAT-PT
Dynamic NAT-PT allows multiple NAT-PT mappings by allocating addresses from a pool of
addresses. NAT-PT is configured with a pool of IPv6 and/or IPv4 addresses. At the start of a NAT-PT
session a temporary address is dynamically allocated from this pool. The number of addresses
available in the address pool determines the maximum number of concurrent sessions. The NAT-PT
device records each mapping between addresses in a dynamic state table
Dynamic NAT-PT translation operation requires at least one static mapping for the IPv4 Domain
Name System (DNS) server.
After the IPv6 to IPv4 connection is established, reply packets going from IPv4 to IPv6 uses the
previously established dynamic mapping to translate back from IPv4 to IPv6 and vice versa for an
IPv4-only host
NAT-PT restrictions
 Network Address Translation (NAT)-Protocol Translation (PT) is not supported with Cisco
Express Forwarding.
 NAT-PT supports only Domain Naming System (DNS), File Transfer Protocol (FTP), and
Internet Control Message Protocol (ICMP) application-layer gateways (ALGs).
 NAT-PT does not provide end-to-end security to networks. The device on which NAT-PT is
configured can be a single point of failure in the network.
 Bridge-group virtual interfaces (BVIs) in IPv6 are not supported with NAT-PT and wireless
interfaces Dot11Radio

Technical Document
IPv6 over MPLS
Introduction
Multiprotocol Label Switching (MPLS) is deployed by many service providers in their IPv4 networks.
Service providers want to introduce IPv6 services to their customers, but changes to their existing
IPv4 infrastructure can be expensive and the cost benefit for a small amount of IPv6 traffic does not
make economic sense. Several integration scenarios have been developed to leverage an existing
IPv4 MPLS infrastructure and add IPv6 services without requiring any changes to the network
backbone. This document describes how to implement IPv6 over MPLS.
Let’s say that you have a standard IPv4 based MPLS network where you offer MPLS VPNs and other
such services, and now you want to start supporting IPv6 in this network. One way of doing this would
be to move to a dual stack solution, which would would involve implementing an IPv6 IGP, MP-BGP
and IPv6 LDP (or MPLS-TE). At the time of this book’s release, LDP wasn’t even implemented for
IPv6.
Another approach is to maintain the MPLS network as it stands, but implement mechanisms on the
PE routers that allow you to transport IPv6 packets as normal labeled packets on the P routers. This
is exactly what the 6PE and 6VPE solutions do. The key selling point of these two solutions is that
you do not need IPv6 support in the core; only PE routers are dual stack.
The difference between 6PE and 6VPE is whether the IPv6 routes are in the global routing table or in
VRFs. 6PE serves the same role as plain IPv4 over MPLS, and 6VPE is the equivalent of an MPLS
VPN.
Both 6PE and 6VPE exploit the fact that as long as a packet somehow can be forwarded along an
LSP from ingress to egress PE, P routers do not care about anything but the transport label. When
using a BGP route in an IPv4 MPLS VPN (or just IPv4 over MPLS), the top label is found by looking
at the BGP next hop of the route. The ingress looks at this IPv4 next hop, finds the label associated
with it, and by using this label, the packet will be forwarded to the egress PE.
If we had an IPv6 MPLS VPN with an IPv6 IGP in the core, VPNv6 prefixes through MP-BGP and
IPv6 LDP, the BGP next hop would be an IPv6 address, and the router would find the correct
transport label for that FEC using the IPv6 CEF table. Now, imagine that instead of the BGP route
having an IPv6 next hop address, the next hop was an IPv4 address. If that was the case, the ingress
PE router would impose the same VPN label, but the transport label would be found in the IPv4 FIB.
The egress PE wouldn’t care either way because the VPN label would be the same, and the packet
would still be forwarded out the same interface based on that router’s LFIB. 6PE and 6VPE are based

Technical Document
on that idea; as long as BGP provides the ingress PE with a VPN label, it doesn’t matter exactly how
the transport label is handled as long as the packet reaches the egress PE.
Why IPv6 over MPLS
Because you already have an MPLS core and want to provide IPv6 access and transit services
to your customers
 IPv6 access to IPv6 services and resources that you provide

 IPv6 access to IPv6 services and resources reachable via your network
 VPNv6 services
Pre-existing MPLS core = IPv4 services; think co-existence

You want to provide IPv6 access and transit services, and MPLS is a the technology to do
(speed, traffic engineering, QoS, VPN, resiliency)
Now, the questions arises what the status of the core network we want to implement IPv6 (MPLS)
over, is it an existing one or it’s a new one?
Pre-existing core
Stick with what you have (L2-based/L3-based, LDP, RSVP) and use 6PE-6VPE
New core
 Providing mixed (IPv4/IPv6) services

 IPv6 only (no LDPv6 available yet)
Next, we should determine what technology to follow in order to provide services of concern?
Table 1: MPLS Technologies Comparison
Mechanism Primary Use Benefits Limitations
IPv6 over a circuit SP with circuit to the Transparent to the SP Scalability
transport over MPLS CE (ATM, Ethernet,
etc.)
IPv6 over IPv4 tunnels SP willing to offer IPv6 Impact limited to Tunnel overhead
over MPLS service on top of an MPLS PE configuration
existing IPv4 MPLS
service
IPv6 MPLS with IPv4- SP willing to offer IPv6 Impact limited to Core is unaware of
based core service on top of an MPLS PE IPv6 : limitations in
(6PE/6VPE

Technical Document
existing IPv4 MPLS load-balancing and

service troubleshooting
IPv6 MPLS with IPv6- SP willing to offer Full MPLS-IPv6  Impact on
based core MPLS services in functionality entire MPLS
IPv6-only context infrastructure
 Complexity if
co-existence
with IPv4-MPLS
services
IPv6 over IPv4

tunnels
V6
V4
IPv4 IPv6
PE P P PE
V6
IPv6
IPv6 V6
MPLS Backbone
P
IPv4
V4 PE PE
V4
IPv4
IPv6
V6
IPv4
Figure: IPv6 over a circuit transport over MPLS
 No impact on existing IPv4 on MPLS core

 Only CEs have to be IPv6-aware (Dual stack)
 Mesh of IPv6 over IPv4 tunnels (CE to CE)
 Overhead: IPv4 header + MPLS header
 Service provider cannot delegate his IPv6 prefix to the CE routers

Technical Document
V6
V6
IPv6
IPv6
PE P P PE
MPLS Backbone
IPv6 P
routers
PE PE
IPv6 IPv6
V6 V6
Circuit over
MPLS
IPv6 Circuit IPv6
Figure: IPv6 over circuit over MPLS
 No impact on existing IPv4 or MPLS core (IPv6 unaware)

 Edge MPLS routers need to support Circuit over MPLS
 Mesh of MPLS circuits (PE to PE)
 PE routers can also be regular IPv6 routers (IPv6 over ATM, IPv6 over Ethernet) to aggregate
customers IPv6 routers

Technical Document
MPLS Label IPv6

BGP Label
(LDP) Packet
PE PE
IPv6 MPLS Backbone IPv6
V6 CE CE V6
LSP Setup : IGP + LDP

MP-iBGP Peering
IPv6 + label
VPNv6
Figure: IPv4 over MPLS (V4-signalled LSP)

Technical Document
All routers are

V6 IPv6-aware V6
IPv6 IPv6
PE P P PE
MPLS Backbone
P
PE PE
IPv6 IPv6
V6 V6
IPv6 IPv6 MPLS IPv6
Figure: IPv4 over MPLS (V6-signalled LSP)
Core infrastructure requires full control-plane upgrade to IPv6
 IPv6 routing in core

 IPv6 Label Distribution Protocol
6PE
6PE is one such wonderful feature which allows Service provider to deliver IPv6 services to Edge
Customers without migrating the stabilized IPv4 backbone to IPv6. Most of Service Provider has
MPLS backbone which forwards traffic based on labels instead of actually looking into the IP header.
6PE utilizes existing MPLS cloud to forward IPv6 traffic using labels. This requires the below:
 Service Provider backbone with MPLS enabled.

 Provider Edge devices should be enabled to support dual stack (both IPv4 and IPv6).
 MP -BGP between all Provider Edge devices.

Technical Document
6PE is a technology that allows IPv6 customers to communicate with each other over an IPv4 MPLS
Provider without any tunnel setup, by having the customer IPv6 prefixes using a IPv4-mapped IPv6
address as next-hop inside the Provider's network and using IPv4 LSPs between the 6PEs.
In 6PE, labels must be exchanged between the 6PEs for their IPv6 prefixes, which means that a
labeled IPv4 iBGP session must be activated under the IPv6 address family (in IOS) or the labeled
IPv6 capability must be activated for the IPv4 peer 6PE (in IOS-XR)
MP-iBGP Session
V6
DSL
6PE 6PE
P P
V4/V6
MPLS Backbone
P
PE PE
V4
FTTH
MPLS
Figure: 6PE infrastructure

The below notes briefly describe the technology:
 MPLS/IPv4 core infrastructure is IPv6-unaware

 PEs are updated to support Dual stack/6PE
 IPv6 reachability exchanged among 6PEs via iBGP (MP-iBGP)
 IPv6 packets transported from 6PE to 6PE inside MPLS
6VPE
6VPE is a technology that allows IPv6 VPN customers to communicate with each other over an IPv4
MPLS Provider without any tunnel setup, by having the customer VPNv6 prefixes using a v4-mapped
IPv6 address as next-hop inside the provider's network and using IPv4 LSPs between the 6VPEs.

Technical Document
In 6VPE, labels must be exchanged between the 6VPEs for their VPNv6 prefixes, which means that
the VPNv6 address-family must be activated on the IPv4 iBGP session between the 6VPEs.
MP-iBGP Session
(VPNv6 AF)
V6
DSL VRF
6PE 6PE
P P
V4/V6
MPLS Backbone
P
PE PE
V4
FTTH
MPLS
Figure: 6VPE infrastructure

The table below lists comparison between VPNv4 and VPNv6 regarding several attributes.
Table: VPNv4 vs VPNv6

Attribute VPNv4 6VPE (VPNv6)
RD 2Bytes:6Bytes 2Bytes:6Bytes
TYPE:VALUE TYPE:VALUE
RT (Extended community) 2 Bytes:6 Bytes 2 Bytes:6 Bytes
TYPE:VALUE TYPE:VALUE
VPN address 8Bytes:4 Bytes [8Bytes]16Bytes
RD:IPv4-address [RD]IPv6-address
MP_REACH_NLRI AFI=1 AFI=2
SAFI=128 SAFI=128
NLRI <length, IPv4-prefix,label> <length, IPv4-prefix,label>
VRF 1 VRF = 1 RIB + 1 FIB MP-VRF
Next-hop 0:IPv4-address [0]::FFFF:IPv4-address
[0]:IPv6-address
[0]:IPv6-LL-address
Peering IPv4-address IPv4-address

Technical Document
IPv6-address
IPv6-LL-address
The below points briefly describe 6VPE functionality:
 An MPLS core with IPv4 IGP and IPv4 LDP and/or TE.
 The PE routers are IPv6 capable.
 The PE routers have IPv6 VRFs on interfaces towards CEs.
 BGP advertises VPNv6 prefixes between PEs and they are imported into VRFs based on
route targets.
 The data plane uses a transport label and a VPN label.
 There’s some kind of IPv6 routing between CE and PE.
 BGP next hop on ingress PE is an IPv4-mapped IPv6 address.
 You can run MPLS VPN for IPv4 and 6VPE at the same time, and even on the same interface
The below diagram shows the detailed routing tables when VPNv6 is in place:
RED
routing BGP
table table
CE1-
S1
CE2-
S2
PE CE1-
S2
CE2-
S1
GREEN Global
routing routing
table table
Figure: Detailed routing table

Technical Document
Configuration Examples
Dual stack
Network diagram
OSPFv3 RIPng
Area 0 AS#300
R1 2001:192:12::/64 R2
R2 2001:192:23::/64 R3
2001:192:34::/64
R4
AS#400
Figure 1: Dual stack (Routing)
Configurations
R1
interface Loopback0
ipv6 address 2001::1/128
ipv6 ospf 1 area 0
interface Loopback1
ipv6 address 2001:DB8::1/128
ipv6 ospf 1 area 0

Technical Document
interface FastEthernet0/0
ipv6 address 2001:192:12::1/64
ipv6 ospf network point-to-point
ipv6 ospf 1 area 0
ipv6 router ospf 1

router-id 1.1.1.1
R2
interface Loopback0
ipv6 ospf 1 area 0
interface Loopback1
ipv6 ospf 1 area 0
ipv6 address 2001:192:12::2/64
ipv6 ospf network point-to-point
ipv6 ospf 1 area 0
ipv6 address 2001:192:23::2/64
ipv6 rip RIPng enable
ipv6 router ospf 1

router-id 2.2.2.2
redistribute rip RIPng include-connected
ipv6 router rip RIPng

redistribute ospf 1 include-connected
R3
interface Loopback0
interface Loopback1
ipv6 address 2001:192:23::3/64
Technical Document
ipv6 address 2001:192:34::3/64

redistribute bgp 300
router bgp 300

bgp router-id 3.3.3.3
bgp log-neighbor-changes
neighbor 2001:192:34::4 remote-as 400
address-family ipv6
neighbor 2001:192:34::4 activate
redistribute rip RIPng include-connected
R4
interface Loopback0
interface Loopback1
no ip address
ipv6 address 2001:192:34::4/64
router bgp 400

bgp router-id 4.4.4.4
neighbor 2001:192:34::3 remote-as 300
address-family ipv6
neighbor 2001:192:34::3 activate
network 2001::4/128
network 2001:DB8::4/128
Verifications
R2#sh ipv6 route ospf
IPv6 Routing Table - 12 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP

Technical Document
U - Per-user Static route, M - MIPv6

I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
O 2001::1/128 [110/10]
via FE80::C000:74FF:FEF5:0, FastEthernet0/0
O 2001:DB8::1/128 [110/10]
R3#sh ipv6 route rip
R 2001::1/128 [120/2]
R 2001::2/128 [120/2]
R 2001:192:12::/64 [120/2]
R 2001:DB8::2/128 [120/2]
R3#sh bgp ipv6 unicast

Technical Document
BGP table version is 14, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2001::1/128 :: 6 32768 ?
*> 2001::2/128 :: 2 32768 ?
*> 2001::3/128 :: 0 32768 ?
*> 2001::4/128 2001:192:34::4 0 0 400 i
*> 2001:192:12::/64 :: 2 32768 ?
*> 2001:192:23::/64 :: 0 32768 ?
*> 2001:DB8::2/128 :: 2 32768 ?
*> 2001:DB8::3/128 :: 0 32768 ?
*> 2001:DB8::4/128 2001:192:34::4 0 0 400 i
Tunneling
Manual
IPv6 packets are tunneled across an IPv4 network by encapsulating them in IPv4 packets, this
requires routers to be configured with dual stack IP scheme
Network diagram
R3 R1 192.1.12.0/24 R2 R4
2001:192:13::/64 2001:192:24::/64
RIPv2
Figure: Manual Tunneling

Technical Document
Configurations
R1
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip address 192.1.12.1 255.255.255.0
no ip address
speed 100
full-duplex
ipv6 address 2001:192:1:13::1/64
router rip
version 2
network 1.0.0.0
network 192.1.12.0
no auto-summary
interface Tunnel12
no ip address

Technical Document

tunnel source Loopback0
tunnel destination 2.2.2.2
tunnel mode ipv6ip
R2
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 192.1.12.2 255.255.255.0
no ip address
speed 100
full-duplex
ipv6 address 2001:192:1:24::2/64
router rip
version 2
network 2.0.0.0
network 192.1.12.0
no auto-summary

Technical Document
interface Tunnel12
no ip address
tunnel mode ipv6ip
R3
interface Loopback0
ipv6 address 2001:192:1:13::3/64

R4
interface Loopback0
ipv6 address 2001:192:1:24::4/64

Technical Document
Verifications
R1#sh int tun12 | inc line

Tunnel12 is up, line protocol is up
R1#ping 12::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
R 12::/64 [120/2]
via FE80::C000:79FF:FEEA:1, FastEthernet0/0
R 2001::4/128 [120/4]
R 2001:192:1:24::/64 [120/3]
R3#ping 2001::4 source lo0
Packet sent with a source address of 2001::3

Technical Document
!!!!!
GRE
IPv6 packets are tunneled across an IPv4 network by encapsulating them using GRE, this requires
routers to be configured with dual stack IP scheme
Network Diagram
R3 R1 192.1.12.0/24 R2 R4
2001:192:13::/64 2001:192:24::/64
GRE
RIPv2
Figure: GRE Tunneling
Configurations
R1
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip address 192.1.12.1 255.255.255.0
no ip address
speed 100
full-duplex

Technical Document
ipv6 address 2001:192:1:13::1/64

router rip
version 2
network 1.0.0.0
network 192.1.12.0
no auto-summary
interface Tunnel12
no ip address
tunnel mode gre ip
R2
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip address 192.1.12.2 255.255.255.0

Technical Document
no ip address
speed 100
full-duplex
ipv6 address 2001:192:1:24::2/64
router rip
version 2
network 2.0.0.0
network 192.1.12.0
no auto-summary
interface Tunnel12
no ip address
tunnel mode gre ip
R3
interface Loopback0

Technical Document
ipv6 address 2001:192:1:13::3/64

R4
interface Loopback0
ipv6 address 2001:192:1:24::4/64
Verifications

R 12::/64 [120/2]
R 2001::4/128 [120/4]

Technical Document

R 2001:192:1:24::/64 [120/3]
!!!!!
R3#traceroute 2001::4
Tracing the route to 2001::4
1 2001:192:1:13::1 8 msec 4 msec 4 msec
2 12::2 12 msec 8 msec 8 msec
3 2001::4 12 msec 12 msec 12 msec
6to4
Allows IPv6 localities to connect to other IPv6 localities across an IPv4 backbone, such as the Internet,
automatically. This method applies a unique IPv6 prefix to each locality without having to retrieve IPv6
addressing information from address registries or ISPs.
RIPv2 will still be the routing protocol on the IPv4 segment between R1 and R2 in order to achieve
connectivity between their loopback 0 interfaces

Technical Document
Network Diagram
R3 R1 192.1.12.0/24 R2 R4
2001:192:13::/64 2001:192:24::/64
6to4
RIPv2
Figure: 6to4 Tunneling
Configurations
R1
router rip
version 2
network 1.0.0.0
network 192.1.12.0
no auto-summary
R2
router rip
version 2
network 2.0.0.0
network 192.1.12.0
no auto-summary
Now, the tunnel interface in 6to4 mode does not have destination in the tunnel configuration, as well
the IPv6 address assigned to the tunnel interface is extracted from the tunnel source IPv4 address
(which is in our case loopback 0 interface), i.e. the loopback 0 interface of R1 has an IPv4 address of
1.1.1.1 which when converted to hexadecimal becomes 0101:0101, this will be appended to the
prefix 2002:, that means the IPv6 address of R1 tunnel interface will be 2002:101:101::/128

Technical Document
Next, we will need static routes to reach: the prefix that the tunnel interface is composed of and the
prefixes of concern which will be delivering to our CE router
R1
interface Tunnel12
no ip address
ipv6 address 2002:101:101::/128
tunnel mode ipv6ip 6to4
ipv6 route 2001::4/128 2002:202:202::

ipv6 route 2001:192:1:24::/64 2002:202:202::
ipv6 route 2002::/16 Tunnel12
redistribute static
R2
interface Tunnel12
no ip address
ipv6 address 2002:202:202::/128
tunnel mode ipv6ip 6to4
ipv6 route 2001::3/128 2002:101:101::

ipv6 route 2001:192:1:13::/64 2002:101:101::
ipv6 route 2002::/16 Tunnel12
redistribute static
Technical Document
Verifications

R 2001::4/128 [120/2]
R 2001:192:1:24::/64 [120/2]
R 2002::/16 [120/2]
!!!!!

Technical Document
R 2001::3/128 [120/2]
R 2001:192:1:13::/64 [120/2]
R 2002::/16 [120/2]
!!!!!
ISATAP
Uses virtual links to connect IPv6 localities together within a site that is primarily using IPv4.
Boundary routers between the two addressing types must be configured with dual stacks.
ISATAP tunneling rely on the link local address to establish connectivity, let us choose the prefix
12:12 for tunnel interfaces, and we will rely on automatic address assignment using eui-64

Technical Document
Network Diagram
R3 R1 192.1.12.0/24 R2 R4
2001:192:13::/64 2001:192:24::/64
ISATAP
RIPv2
Figure: ISATAP Tunneling
Configurations
R1
interface Tunnel12
no ip address
ipv6 address 12:12::/64 eui-64
tunnel mode ipv6ip isatap
R1#sh ipv6 int tun 12 | inc link|EUI
IPv6 is enabled, link-local address is FE80::5EFE:101:101
No Virtual link-local address(es):
12:12::5EFE:101:101, subnet is 12:12::/64 [EUI]
ipv6 route 2001::4/128 Tunnel12 FE80::5EFE:202:202
ipv6 route 2001:192:1:24::/64 Tunnel12 FE80::5EFE:202:202
redistribute static
R2
interface Tunnel12
Technical Document
no ip address
ipv6 address 12:12::/64 eui-64
tunnel mode ipv6ip isatap
R2#sh ipv6 int tun 12 | inc link|EUI
IPv6 is enabled, link-local address is FE80::5EFE:202:202
No Virtual link-local address(es):
12:12::5EFE:202:202, subnet is 12:12::/64 [EUI]
ipv6 route 2001::3/128 Tunnel12 FE80::5EFE:101:101
ipv6 route 2001:192:1:13::/64 Tunnel12 FE80::5EFE:101:101
redistribute static
Verifications
R 2001::4/128 [120/2]
R 2001:192:1:24::/64 [120/2]

Technical Document

!!!!!
R 2001::3/128 [120/2]
R 2001:192:1:13::/64 [120/2]
!!!!!

Technical Document
Translation
NAT-PT
Has an address translation device that translates addresses between an IPv6 and IPv4 network
and vice versa.
This type of technique used when we have IPv4 only segment and IPv6 only segment and needs to
communicate via IPv6
NAT-PT router will have both of its interfaces enabled for IPv6 nat, it will reserve /96 prefix for NAT
translation purposes
Network Diagram
R1 R2 14::/64 R4
172.16.123.0/24
RIPng
Figure: NAT-PT
Configurations
R1
ip address 172.16.123.2 255.255.255.0
speed 100
full-duplex
interface Loopback0

Technical Document
no ip address
ipv6 address 102:102::1/64
R2
ip address 172.16.123.1 255.255.255.0
speed 100
full-duplex
ipv6 nat
no ip address
speed 100
full-duplex
ipv6 nat

redistribute connected metric 3
ipv6 nat v4v6 source 172.16.123.2 1144::2

ipv6 nat v6v4 source 14::4 172.16.123.100
ipv6 nat prefix 1144::/96
R4
no ip address

Technical Document
speed 100
full-duplex
interface Loopback0
no ip address

Verifications
R 1144::/96 [120/4]
R4#ping 1144::2
..!!!

Technical Document

R2#sh ipv6 nat translations
Prot IPv4 source IPv6 source
IPv4 destination IPv6 destination
--- --- ---
172.16.123.2 1144::2
icmp 172.16.123.100,8149 14::4,8149
172.16.123.2,8149 1144::2,8149
--- 172.16.123.100 14::4

--- ---

Technical Document
MPLS
6PE
Network diagram
OSPF A0
P
PE1 PE2
ESW2
iBGP
eBGP eBGP
CE1 CE2
AS#1 AS#5
Figure: MPLS 6PE

Configurations
CE1
ip address 192.1.12.1 255.255.255.0
duplex full
speed 100
ipv6 address 2001:DB8:12::1/64

Technical Document
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ipv6 ospf 1 area 0
PE1
vrf forwarding MSSK
ip address 192.1.12.2 255.255.255.0
duplex full
speed 100
ip address 192.1.23.2 255.255.255.0
ip ospf 1 area 0
duplex full
speed 100
mpls ip
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
vrf definition MSSK

rd 100:1

Technical Document
route-target export 100:1

route-target import 100:1
address-family ipv4
exit-address-family
address-family ipv6
exit-address-family
P
ip address 192.1.23.3 255.255.255.0
ip ospf 1 area 0
duplex full
speed 100
mpls ip
ip address 192.1.34.3 255.255.255.0
ip ospf 1 area 0
duplex full
speed 100
mpls ip
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0

Technical Document
PE2
ip address 192.1.34.4 255.255.255.0
ip ospf 1 area 0
duplex full
speed 100
mpls ip
vrf forwarding MSSK
ip address 192.1.45.4 255.255.255.0
duplex full
speed 100
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 0
ipv6 nd ra mtu suppress
vrf definition MSSK

rd 100:1

Technical Document
address-family ipv4
exit-address-family
address-family ipv6
exit-address-family
CE2
ip address 192.1.45.5 255.255.255.0
duplex full
speed 100
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ipv6 nd ra mtu suppress
Now, we have established eBGP sessions between CE1, PE1 and CE2, PE2 and we advertised CEs
loopbacks
CE1
router bgp 1
no bgp default ipv4-unicast
neighbor 2001:DB8:12::2 remote-as 100
address-family ipv6
neighbor 2001:DB8:12::2 activate
network 2001:DB8::1/128
Technical Document
exit-address-family
PE1
router bgp 100
no synchronization
neighbor 4.4.4.4 remote-as 100
neighbor 4.4.4.4 update-source Loopback0
no auto-summary
address-family vpnv6
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-community both
exit-address-family
address-family ipv6 vrf MSSK

redistribute bgp 1
no synchronization
exit-address-family
CE2
router bgp 5
no synchronization

Technical Document
no neighbor 2001:DB8:45::4 activate

no auto-summary
address-family ipv6
network 2001:DB8::5/128
exit-address-family
PE2
router bgp 100
no synchronization
no auto-summary
exit-address-family
redistribute bgp 5
no synchronization
exit-address-family

Technical Document
Verifications
CE1#sh bgp ipv6 unicast summary
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 3, main routing table version 3
2 network entries using 312 bytes of memory
2 path entries using 152 bytes of memory
3/2 BGP path/bestpath attribute entries using 444 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
BGP using 964 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8:12::2 4 100 2862 2863 3 0 0 1d23h 1
CE1#sh bgp ipv6 unicast

*> 2001:DB8::1/128 :: 0 32768 i
*> 2001:DB8::5/128 2001:DB8:12::2 0 100 5 i
CE1#sh bgp ipv6 unicast neighbors 2001:DB8:12::2 advertised-routes

Technical Document

*> 2001:DB8::1/128 :: 0 32768 i
Total number of prefixes 1

CE1#sh bgp ipv6 unicast neighbors 2001:DB8:12::2 routes

*> 2001:DB8::5/128 2001:DB8:12::2 0 100 5 i
CE2#sh bgp ipv6 unicast summary


Technical Document

2001:DB8:45::4 4 100 2471 2471 4 0 0 1d17h 1
CE2#sh bgp ipv6 unicast

*> 2001:DB8::1/128 2001:DB8:45::4 0 100 1 i
*> 2001:DB8::5/128 :: 0 32768 i
CE2#sh bgp ipv6 unicast neighbors 2001:DB8:45::4 advertised-routes


*> 2001:DB8::5/128 :: 0 32768 i
CE2#sh bgp ipv6 unicast neighbors 2001:DB8:45::4 routes

Technical Document

*> 2001:DB8::1/128 2001:DB8:45::4 0 100 1 i
PE1#sh bgp vpnv6 unicast vrf MSSK summary

1 BGP extended community entries using 24 bytes of memory

2001:DB8:12::1 4 1 2866 2865 4 0 0 2d00h 1


Technical Document


2001:DB8:12::1 4 1 2866 2865 4 0 0 2d00h 1
PE1#sh bgp vpnv6 unicast vrf MSSK


Route Distinguisher: 100:1 (default for vrf MSSK)
*> 2001:DB8::1/128 2001:DB8:12::1 0 01i
*>i2001:DB8::5/128 ::FFFF:4.4.4.4 0 100 05i

Technical Document
PE1#sh bgp vpnv6 unicast vrf MSSK neighbors 2001:DB8:12::1 advertised-routes


*>i2001:DB8::5/128 ::FFFF:4.4.4.4 0 100 05i
PE1#sh bgp vpnv6 unicast vrf MSSK neighbors 2001:DB8:12::1 routes


*> 2001:DB8::1/128 2001:DB8:12::1 0 01i


Technical Document


2001:DB8:45::5 4 5 2476 2476 4 0 0 1d17h 1
PE2#sh bgp vpnv6 unicast vrf MSSK


*>i2001:DB8::1/128 ::FFFF:2.2.2.2 0 100 01i
*> 2001:DB8::5/128 2001:DB8:45::5 0 05i

Technical Document
PE2#sh bgp vpnv6 unicast vrf MSSK neighbors 2001:DB8:45::5 advertised-routes


*>i2001:DB8::1/128 ::FFFF:2.2.2.2 0 100 01i
PE2#sh bgp vpnv6 unicast vrf MSSK neighbors 2001:DB8:45::5 routes


*> 2001:DB8::5/128 2001:DB8:45::5 0 05i
CE1#sh ipv6 route

IPv6 Routing Table - Default - 5 entries

Technical Document
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route

B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
LC 2001:DB8::1/128 [0/0]
via Loopback0, receive
B 2001:DB8::5/128 [20/0]
via FE80::C801:18FF:FE0C:1C, FastEthernet1/0
C 2001:DB8:12::/64 [0/0]
via FastEthernet1/0, directly connected
L 2001:DB8:12::1/128 [0/0]
via FastEthernet1/0, receive
L FF00::/8 [0/0]
via Null0, receive
CE2#sh ipv6 route

IPv6 Routing Table - Default - 5 entries
EX - EIGRP external
B 2001:DB8::1/128 [20/0]

Technical Document
via FE80::C803:18FF:FE0C:1D, FastEthernet1/0

LC 2001:DB8::5/128 [0/0]
C 2001:DB8:45::/64 [0/0]
L 2001:DB8:45::5/128 [0/0]
L FF00::/8 [0/0]
via Null0, receive
PE1#sh ipv6 route vrf MSSK

IPv6 Routing Table - MSSK - 5 entries
EX - EIGRP external
B 2001:DB8::1/128 [20/0]
B 2001:DB8::5/128 [200/0]
via 4.4.4.4%Default-IP-Routing-Table, indirectly connected
C 2001:DB8:12::/64 [0/0]
L 2001:DB8:12::2/128 [0/0]

Technical Document
L FF00::/8 [0/0]
via Null0, receive
PE2#sh ipv6 route vrf MSSK

EX - EIGRP external
B 2001:DB8::1/128 [200/0]
via 2.2.2.2%Default-IP-Routing-Table, indirectly connected
B 2001:DB8::5/128 [20/0]
C 2001:DB8:45::/64 [0/0]
L 2001:DB8:45::4/128 [0/0]
L FF00::/8 [0/0]
via Null0, receive
CE1#ping 2001:DB8::5 source loopback 0

Sending 5, 100-byte ICMP Echos to 2001:DB8::5, timeout is 2 seconds:

Technical Document
Packet sent with a source address of 2001:DB8::1

!!!!!
CE2#ping 2001:DB8::1 source loopback 0

Sending 5, 100-byte ICMP Echos to 2001:DB8::1, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8::5
!!!!!
6VPE IOS
Network Diagram
OSPF A0
P
PE1 PE2
ESW2
iBGP
EIGRP EIGRP
AS#1 AS#1
CE1 CE2
Figure: MPLS 6VPE

Technical Document
Configurations
R1
interface Loopback0
ip address 1.1.1.1 255.255.255.255
interface Serial1/0
ip address 192.168.12.1 255.255.255.0
encapsulation ppp
ipv6 address 2001:192:168:12::1/64
interface Serial1/1
ip address 192.168.13.1 255.255.255.0
encapsulation ppp
ipv6 address 2001:192:168:13::1/64
R2
interface Loopback0
ip address 2.2.2.2 255.255.255.255
interface Serial1/0
ip address 192.168.12.2 255.255.255.0
encapsulation ppp
ipv6 address 2001:192:168:12::2/64
ip address 192.168.24.2 255.255.255.0
speed 100

Technical Document
duplex full
ipv6 address 2001:192:168:24::2/64
R3
interface Loopback0
ip address 3.3.3.3 255.255.255.255
interface Serial1/0
ip address 192.168.13.3 255.255.255.0
encapsulation ppp
ipv6 address 2001:192:168:13::3/64
ip address 192.168.35.3 255.255.255.0
speed 100
duplex full
ipv6 address 2001:192:168:35::3/64
R4
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip address 192.168.24.4 255.255.255.0
speed 100
duplex full
ipv6 address 2001:192:168:24::4/64

Technical Document
R5
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip address 192.168.35.5 255.255.255.0
speed 100
duplex full
ipv6 address 2001:192:168:35::5/64
R2
vrf definition MSSK
rd 100:1
address-family ipv4
exit-address-family
address-family ipv6
exit-address-family
int f2/0
vrf forwarding MSSK

Technical Document
ip address 192.1.24.2 255.255.255.0

ipv6 address 2001:192:168:24::2/64
R3
vrf definition MSSK
rd 100:1
address-family ipv4
exit-address-family
address-family ipv6
exit-address-family
int f2/0
vrf forwarding MSSK
ip address 192.1.35.3 255.255.255.0
ipv6 address 2001:192:168:35::3/64
R1
router ospf 1
router-id 1.1.1.1
network 1.1.1.1 0.0.0.0 area 0
network 192.1.12.1 0.0.0.0 area 0
network 192.1.13.1 0.0.0.0 area 0

Technical Document
R2
router ospf 1
router-id 2.2.2.2
network 2.2.2.2 0.0.0.0 area 0
network 192.1.12.2 0.0.0.0 area 0
R3
router ospf 1
router-id 3.3.3.3
network 3.3.3.3 0.0.0.0 area 0
network 192.1.13.3 0.0.0.0 area 0
R1
mpls label protocol ldp
mpls ldp router-id lo0 force
int s1/0
mpls ip
int s1/1
mpls ip
R2
mpls ldp router-id Loopback0 force
int s1/0
mpls ip

Technical Document
R3
int s1/0
mpls ip
R2
router bgp 100
neighbor 3.3.3.3 update-source lo0
R3
router bgp 100
neighbor 2.2.2.2 update-source lo0

Technical Document

R2
router eigrp MSSK
address-family ipv4 unicast vrf MSSK autonomous-system 1
topology base
exit-af-topology
network 192.168.24.2 0.0.0.0
exit-address-family
topology base
exit-af-topology
exit-address-family
R4
router eigrp MSSK
address-family ipv4 unicast autonomous-system 1
topology base
exit-af-topology
network 4.4.4.4 0.0.0.0
network 192.168.24.4 0.0.0.0
exit-address-family
topology base
exit-af-topology
exit-address-family

Technical Document
R3
router eigrp MSSK
topology base
exit-af-topology
network 192.168.35.3 0.0.0.0
exit-address-family
topology base
exit-af-topology
exit-address-family
R5
router eigrp MSSK
topology base
exit-af-topology
network 5.5.5.5 0.0.0.0
network 192.168.35.5 0.0.0.0
exit-address-family
topology base
exit-af-topology
exit-address-family
R2
router eigrp MSSK

Technical Document
topology base
redistribute bgp 100 metric 1000 1000 255 1 1500
exit-af-topology
topology base
exit-af-topology
router bgp 100

redistribute eigrp 1
exit-address-family
redistribute eigrp 1 include-connected
exit-address-family
R3
router eigrp MSSK
topology base
exit-af-topology
topology base

Technical Document
exit-af-topology
router bgp 100

redistribute eigrp 1
exit-address-family
redistribute eigrp 1 include-connected
exit-address-family
Verifications
R2#sh mpls ldp neighbor

Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0
TCP connection: 1.1.1.1.646 - 2.2.2.2.35742
State: Oper; Msgs sent/rcvd: 77/77; Downstream
Up time: 01:00:24
LDP discovery sources:
Serial1/0, Src IP addr: 192.168.12.1
Addresses bound to peer LDP Ident:
1.1.1.1 192.168.12.1 192.168.13.1
R3#show mpls ldp neighbor

TCP connection: 1.1.1.1.646 - 3.3.3.3.15654
Technical Document
Up time: 01:00:23
Serial1/0, Src IP addr: 192.168.13.1
1.1.1.1 192.168.12.1 192.168.13.1
R2#show bgp vpnv4 unicast all summary


3.3.3.3 4 100 25 25 10 0 0 00:16:31 1
R2#show bgp vpnv4 unicast all

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,

Technical Document

RPKI validation codes: V valid, I invalid, N Not found

*> 4.4.4.4/32 192.168.24.4 103040 32768 ?
*>i 5.5.5.5/32 3.3.3.3 103040 100 0?


2.2.2.2 4 100 25 25 10 0 0 00:16:45 1


Technical Document


*>i 4.4.4.4/32 2.2.2.2 103040 100 0?
*> 5.5.5.5/32 192.168.35.5 103040 32768 ?
R2#sh ip eigrp vrf MSSK neighbors

EIGRP-IPv4 VR(MSSK) Address-Family Neighbors for AS(1)
VRF(MSSK)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.24.4 Fa2/0 14 00:22:39 14 100 0 7
R3#sh ip eigrp vrf MSSK neighbors

VRF(MSSK)
(sec) (ms) Cnt Num
0 192.168.35.5 Fa2/0 11 00:22:27 13 100 0 9
R4#sh ip eigrp neighbors


Technical Document

(sec) (ms) Cnt Num
0 192.168.24.2 Fa1/0 14 00:21:00 13 100 0 8
R5#sh ip eigrp neighbors

(sec) (ms) Cnt Num
0 192.168.35.3 Fa1/0 14 00:20:37 2 100 0 11
R4#show topology all

Topology Address Family Associated VRF State
base ipv4 default UP
base ipv4 multicast default DOWN


Technical Document

base ipv4 MSSK UP
base ipv6 MSSK UP
base ipv4 multicast MSSK DOWN

Technical Document

base ipv4 MSSK UP
base ipv6 MSSK UP
R4#sh ip route eigrp

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route

Technical Document
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

+ - replicated route, % - next hop override
Gateway of last resort is not set
5.0.0.0/32 is subnetted, 1 subnets

D 5.5.5.5 [90/153600] via 192.168.24.2, 00:17:47, FastEthernet1/0
R4#ping 5.5.5.5 source lo0

Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!
R4#traceroute 5.5.5.5 source lo0 numeric

Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.24.2 4 msec 0 msec 8 msec
2 192.168.12.1 [MPLS: Labels 19/20 Exp 0] 16 msec 20 msec 16 msec
3 192.168.35.3 [MPLS: Label 20 Exp 0] 12 msec 12 msec 12 msec
4 192.168.35.5 20 msec * 16 msec
R2#show eigrp address-family ipv6 vrf MSSK neighbors


Technical Document
VRF(MSSK)
(sec) (ms) Cnt Num
0 Link-local address: Fa2/0 13 00:20:32 7 100 0 4
FE80::C803:EFF:FE69:1C
R3#show eigrp address-family ipv6 vrf MSSK neighbors

VRF(MSSK)
(sec) (ms) Cnt Num
FE80::C804:EFF:FE69:1C
R2#show eigrp address-family ipv6 vrf MSSK interfaces

EIGRP-IPv6 VR(MSSK) Address-Family Interfaces for AS(1)
VRF(MSSK)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Fa2/0 1 0/0 0/0 7 0/0 50 0
R3#show eigrp address-family ipv6 vrf MSSK interfaces

EIGRP-IPv6 VR(MSSK) Address-Family Interfaces for AS(1)
VRF(MSSK)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes

Technical Document
Fa2/0 1 0/0 0/0 14 0/0 64 0


3.3.3.3 4 100 30 29 7 0 0 00:20:26 2


Technical Document

*> 2001::4/128 FE80::C803:EFF:FE69:1C
103040 32768 ?
*>i 2001::5/128 ::FFFF:3.3.3.3 103040 100 0?
*> 2001:192:168:24::/64
:: 0 32768 ?
*>i 2001:192:168:35::/64
::FFFF:3.3.3.3 0 100 0?


2.2.2.2 4 100 30 30 7 0 0 00:20:37 2


Technical Document


*>i 2001::4/128 ::FFFF:2.2.2.2 103040 100 0?
*> 2001::5/128 FE80::C804:EFF:FE69:1C
103040 32768 ?
*>i 2001:192:168:24::/64
::FFFF:2.2.2.2 0 100 0?
*> 2001:192:168:35::/64
:: 0 32768 ?
R4#sh ipv6 eigrp neighbors

(sec) (ms) Cnt Num
FE80::C801:EFF:FE69:38
R5#show ipv6 eigrp neighbors


Technical Document
(sec) (ms) Cnt Num

FE80::C802:EFF:FE69:38

!!!!!
R4#traceroute 2001::5
Tracing the route to 2001::5
1 FE80::C801:EFF:FE69:38 4 msec 4 msec 4 msec

2 ::FFFF:192.168.12.1 [MPLS: Labels 19/21 Exp 0] 20 msec 16 msec 16 msec
3 2001:192:168:35::3 [MPLS: Label 21 Exp 0] 16 msec 12 msec 12 msec
4 2001:192:168:35::5 16 msec 16 msec 16 msec

Technical Document
6VPE IOS-XR
Network Diagram
OSPFv2 A0
R2 OSPFv3 A0
XR1
R3
iBGP
Static Static
R4 R1
Figure: MPLS 6VPE IOS-XR
Initial Configurations
R1
ip address 192.168.102.1 255.255.255.0
speed auto
duplex auto
ipv6 address 2001:192:102::1/64
interface Loopback0
ip address 1.1.1.1 255.255.255.255

Technical Document

R2
ip address 192.168.101.2 255.255.255.0
speed auto
duplex auto
ipv6 address 2001:192:101::2/64
ip address 192.168.23.2 255.255.255.0
speed 100
duplex full
ipv6 address 2001:192:23::2/64
interface Loopback0
ip address 2.2.2.2 255.255.255.255
R3
ip address 192.168.23.3 255.255.255.0
speed 100
duplex full
ipv6 address 2001:192:23::3/64
ip address 192.168.34.3 255.255.255.0

Technical Document
speed 100
duplex full
ipv6 address 2001:192:34::3/64
interface Loopback0
ip address 3.3.3.3 255.255.255.255
R4
ip address 192.168.34.4 255.255.255.0
speed 100
duplex full
ipv6 address 2001:192:34::4/64
interface Loopback0
ip address 4.4.4.4 255.255.255.255
RP/0/0/CPU0:XR1
hostname XR1
cdp
interface Loopback0
ipv4 address 10.10.10.10 255.255.255.255

Technical Document
interface GigabitEthernet0/0/0/0
cdp
ipv4 address 192.168.102.10 255.255.255.0
ipv6 address 2001:192:102::10/64
duplex full
cdp
ipv4 address 192.168.101.10 255.255.255.0
ipv6 address 2001:192:101::10/64
Configurations
R1
ip address 192.168.102.1 255.255.255.0
speed auto
duplex auto
ipv6 address 2001:192:102::1/64
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip route 0.0.0.0 0.0.0.0 192.168.102.10

ipv6 route ::/0 2001:192:102::10

Technical Document
R2
ip address 192.168.101.2 255.255.255.0
ip ospf network point-to-point
speed auto
duplex auto
ipv6 address 2001:192:101::2/64
mpls ip
ospfv3 network point-to-point
ospfv3 1 ipv6 area 0
ip address 192.168.23.2 255.255.255.0
speed 100
duplex full
ipv6 address 2001:192:23::2/64
mpls ip
interface Loopback0
ip address 2.2.2.2 255.255.255.255

Technical Document
router ospfv3 1
router-id 2.2.2.2
address-family ipv6 unicast

exit-address-family
router ospf 1
router-id 2.2.2.2
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.2 0.0.0.0 area 0
network 192.168.101.2 0.0.0.0 area 0
R3
ip address 192.168.23.3 255.255.255.0
speed 100
duplex full
ipv6 address 2001:192:23::3/64
mpls ip
vrf forwarding MSSK

Technical Document
ip address 192.168.34.3 255.255.255.0

speed 100
duplex full
ipv6 address 2001:192:34::3/64
interface Loopback0
ip address 3.3.3.3 255.255.255.255
router ospfv3 1
router-id 3.3.3.3

exit-address-family
router ospf 1
router-id 3.3.3.3
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.3 0.0.0.0 area 0
router bgp 1

Technical Document
address-family ipv4
exit-address-family
exit-address-family
exit-address-family

redistribute static
exit-address-family

redistribute static
exit-address-family

vrf definition MSSK

Technical Document
rd 100:1
address-family ipv4
exit-address-family
address-family ipv6
exit-address-family
ip route vrf MSSK 4.4.4.4 255.255.255.255 192.168.34.4

ipv6 route vrf MSSK 2001::4/128 2001:192:34::4
R4
ip address 192.168.34.4 255.255.255.0
speed 100
duplex full
ipv6 address 2001:192:34::4/64
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip route 0.0.0.0 0.0.0.0 192.168.34.3

Technical Document
ipv6 route ::/0 2001:192:34::3
RP/0/0/CPU0:XR1
hostname XR1
cdp
vrf MSSK
import route-target
100:1
export route-target
100:1

import route-target
100:1
export route-target
100:1
interface Loopback0
ipv4 address 10.10.10.10 255.255.255.255
cdp
vrf MSSK

Technical Document
ipv4 address 192.168.102.10 255.255.255.0

ipv6 address 2001:192:102::10/64
duplex full
cdp
ipv4 address 192.168.101.10 255.255.255.0
ipv6 address 2001:192:101::10/64
router static
vrf MSSK
1.1.1.1/32 192.168.102.1

2001::1/128 2001:192:102::1
router ospf 1
router-id 10.10.10.10
area 0
interface Loopback0
network point-to-point
router ospfv3 MSSK_OSPFv3

Technical Document
router-id 10.10.10.10
area 0
interface Loopback0
network point-to-point
router bgp 1
address-family vpnv4 unicast
neighbor 3.3.3.3
remote-as 1
update-source Loopback0

vrf MSSK
rd 100:1
redistribute static

redistribute static

Technical Document
mpls ldp
router-id 10.10.10.10
Verifications
R1#sh ip route
Gateway of last resort is 192.168.102.10 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.102.10

C 1.1.1.1 is directly connected, Loopback0
192.168.102.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.102.0/24 is directly connected, FastEthernet1/0
L 192.168.102.1/32 is directly connected, FastEthernet1/0

Technical Document

!!!!!

1 192.168.102.10 72 msec 64 msec 64 msec
4 192.168.34.4 148 msec * 156 msec
R1#sh ipv6 route

IPv6 Routing Table - default - 5 entries
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
S ::/0 [1/0]
via 2001:192:102::10
LC 2001::1/128 [0/0]

Technical Document

C 2001:192:102::/64 [0/0]
L 2001:192:102::1/128 [0/0]
L FF00::/8 [0/0]
via Null0, receive

!!!!!

1 192.168.102.10 4 msec 20 msec 40 msec
4 192.168.34.4 148 msec 172 msec 184 msec
R4#sh ip route

Technical Document

Gateway of last resort is 192.168.34.3 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.168.34.3

C 4.4.4.4 is directly connected, Loopback0
192.168.34.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.34.0/24 is directly connected, FastEthernet1/0
L 192.168.34.4/32 is directly connected, FastEthernet1/0

!!!!!
R4#traceroute 1.1.1.1 source lo0

Technical Document

1 192.168.34.3 64 msec 88 msec *
4 192.168.102.1 184 msec 168 msec 172 msec
R4#sh ipv6 route

IPv6 Routing Table - default - 5 entries
S ::/0 [1/0]
via 2001:192:34::3
LC 2001::4/128 [0/0]
C 2001:192:34::/64 [0/0]
L 2001:192:34::4/128 [0/0]
L FF00::/8 [0/0]
via Null0, receive

Technical Document

!!!!!

TCP connection: 3.3.3.3.43203 - 2.2.2.2.646
Up time: 01:24:06
FastEthernet1/1, Src IP addr: 192.168.23.3
192.168.23.3 3.3.3.3
TCP connection: 10.10.10.10.23681 - 2.2.2.2.646
Up time: 01:19:08
10.10.10.10 192.168.101.10
R2#sh ip ospf neighbor

Technical Document
Neighbor ID Pri State Dead Time Address Interface

10.10.10.10 0 FULL/ - 00:00:35 192.168.101.10 FastEthernet1/0
R2#sh ospfv3 neighbor
OSPFv3 1 address-family ipv6 (router-id 2.2.2.2)
Neighbor ID Pri State Dead Time Interface ID Interface

10.10.10.10 0 FULL/ - 00:00:39 5 FastEthernet1/0
R2#sh mpls interfaces

Interface IP Tunnel BGP Static Operational
FastEthernet1/0 Yes (ldp) No No No Yes
R3#sh mpls interfaces

Interface IP Tunnel BGP Static Operational

TCP connection: 2.2.2.2.646 - 3.3.3.3.43203

Technical Document
Up time: 01:25:15
192.168.101.2 192.168.23.2 2.2.2.2
R3#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface

R3#sh ospfv3 neighbor
OSPFv3 1 address-family ipv6 (router-id 3.3.3.3)
Neighbor ID Pri State Dead Time Interface ID Interface

R3#sh bgp vpnv4 unicast all summary


Technical Document


10.10.10.10 4 1 43 50 4 0 0 00:40:45 1
R3#sh bgp vpnv4 unicast all


*>i 1.1.1.1/32 10.10.10.10 0 100 0?
*> 4.4.4.4/32 192.168.34.4 0 32768 ?
R3#sh bgp vpnv6 unicast all summary


Technical Document


10.10.10.10 4 1 43 50 4 0 0 00:40:51 1
R3#sh bgp vpnv6 unicast all


*>i 2001::1/128 ::FFFF:10.10.10.10
0 100 0?
*> 2001::4/128 2001:192:34::4 0 32768 ?
RP/0/0/CPU0:XR1#sh mpls interfaces

Tue Apr 29 14:13:24.958 UTC
Interface LDP Tunnel Static Enabled

Technical Document
-------------------------- -------- -------- -------- --------

GigabitEthernet0/0/0/2 Yes No No Yes
RP/0/0/CPU0:XR1#sh mpls ldp neighbor

Tue Apr 29 14:13:28.268 UTC
Peer LDP Identifier: 2.2.2.2:0

TCP connection: 2.2.2.2:646 - 10.10.10.10:23681
Graceful Restart: No
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 103/103; Downstream-Unsolicited
Up time: 01:18:36
LDP Discovery Sources:
GigabitEthernet0/0/0/2
Addresses bound to this peer:
2.2.2.2 192.168.23.2 192.168.101.2
RP/0/0/CPU0:XR1#sh bgp vpnv4 unicast summary

Tue Apr 29 14:14:22.664 UTC
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 5
BGP scan interval 60 secs

Technical Document
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

Speaker 5 5 5 5 5 5
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

3.3.3.3 0 1 51 45 5 0 0 00:40:55 1
RP/0/0/CPU0:XR1#sh bgp vpnv4 unicast

Tue Apr 29 14:14:23.394 UTC
Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard
*> 1.1.1.1/32 192.168.102.1 0 32768 ?
*>i4.4.4.4/32 3.3.3.3 0 100 0?
Processed 2 prefixes, 2 paths

Technical Document
RP/0/0/CPU0:XR1#sh bgp vpnv6 unicast summary

Tue Apr 29 14:14:31.414 UTC
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

Speaker 5 5 5 5 5 5
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

3.3.3.3 0 1 51 45 5 0 0 00:41:04 1
RP/0/0/CPU0:XR1#sh bgp vpnv6 unicast

Tue Apr 29 14:14:32.084 UTC

Technical Document
Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard
*> 2001::1/128 2001:192:102::1 0 32768 ?
*>i2001::4/128 3.3.3.3 0 100 0?
Processed 2 prefixes, 2 paths
R3#sh ip route vrf MSSK static
Routing Table: MSSK

Gateway of last resort is not set

Technical Document
S 4.4.4.4 [1/0] via 192.168.34.4
R3#sh ipv6 route vrf MSSK static

S 2001::4/128 [1/0]
via 2001:192:34::4
RP/0/0/CPU0:XR1#sh route vrf MSSK ipv4 static

Tue Apr 29 14:15:33.779 UTC
S 1.1.1.1/32 [1/0] via 192.168.102.1, 00:38:24
RP/0/0/CPU0:XR1#sh route vrf MSSK ipv6 static

Tue Apr 29 14:15:37.359 UTC
S 2001::1/128
[1/0] via 2001:192:102::1, 00:38:28

Technical Document
Carrier Grade NAT
Introduction
Carrier Grade NAT (CGN) and Large Scale NAT (LSN) are often presented as "IPv6 Transition
Technologies". In reality CGN, LSN, or any other mechanisms that provide IPv4-to-IPv4 connectivity
on Network Address Translator (NAT) platforms (i.e. NAT444) are NOT transition mechanisms to
IPv6. They are technologies to prolong IPv4 address availability by using private IPv4 address space
in Service Provider (SP) networks.
Some SPs may need to deploy CGN/LSN to manage the IPv4 address shortage in their networks
while deploying IPv6 services to customers. However, SPs who do not deploy IPv6 services
simultaneously with CGN/LSN will need to revisit the same issue in a few years' time and resolve the
same scaling problem as their customer base continues to expand. If there is no IPv6 in customer
access networks then customers cannot secure IPv6 reachability
Figure: CGN NAT

Technical Document
NAT, PAT and overloading
When people talk about Carrier Grade NAT (CGN) or Large Scale NAT (LSN) they are talking
primarily about NAT444. The NAT part of those acronyms stands for Network Address Translation
and NAT is already very common in IPv4 networks, particularly on LAN/WAN gateway devices. The
basic idea is to use non-globally-unique (“private”) addresses on the LAN (Local Area Network) and
only use globally-unique (“public”) addresses on the WAN (Wide Area Network) / Internet facing
interfaces. When deployed in this way, NAT is usually combined with less-often-spoke-of PAT (Port
Address Translation) to allow address overloading on the WAN side
The NAT444 model
So far we have discussed traditional NAT (mainly NAPT/NAT overload) which is starting to be called
NAT44 because it translates one IPv4 address for another (4 to 4). Now let’s explore what I (still) call
NAT444, which was also called Carrier Grade NAT (CGN) at one point and is currently called Large
Scale NAT (LSN) by all the cool geeks. I like NAT444 because it explains what is really going to occur
in most places when LSN is implemented; a triple NAT (IPv4 to IPv4 to IPv4). Sounds like a
nightmare already, doesn’t it? We just doubled the NAT, which means doubling the interference with
network traffic and further impeding the end to end principle. Let’s see what that looks like.

Technical Document
The IPv4 Network
IPv4 Peer
Router
Public IPv4 The IPv6 Network

IPv4 NAT #2
(Private to CGN/
ISP Public) LSN IPv6 Peer
Router
Network Shared IPv4 Global IPv6
IPv4 NAT #1 Dual

(Private to Stack
Private) CPE
RFC1918 IPv4
Customer Network and Global IPv6
(IPv4 and IPv6 hosts)
Figure: The NAT444 model
Deploying CGN/LSN without deploying IPv6 services come with some of the negative consequences
of using NAT:
 Breaks the end-to-end model of IP
 Breaks end-to-end security
 Serious consequences for lawful intercept
 Non-NAT friendly applications mean more upgrades
 Mandates the network keeps the state of the connections
 Difficult to scale NAT performance for large networks as number of available ports per
customer is restricted

Technical Document
 Makes fast rerouting and multi-homing difficult
Deploying CGN/LSN in IPv4-only SP networks will likely create a "double NATed" environment, as
most Customer Premise Equipment (CPE) already have NAT functionality. This further increases the
complexity of networks, compounding the negative impacts described above. More disadvantages:
 The SP needs a large, costly NAT device in the aggregation or core layers
 Technical drawbacks of NAT (above)
 Sharing IPv4 addresses among multiple users could increase behavioral, security, and liability
implications
 Multiple NATs can create difficulties in tracking the association of port/address and subscriber,
not to mention lawful intercept issues and increased difficulty for network troubleshooting
 Prevents subscribers from using IPv6 content, services, and applications
Carrier Grade IPv6 solutions
IPv6 deployment is today's new normal. The proliferation of IPv6 in service provider networks and
allocation to end users is a reality now, but it is not always as simple as just flipping a switch. Many
dependencies and considerations are involved as operators choose their path to IPv6. Each place in
the network has different characteristics that dictate how easy or hard it will be to turn on IPv6 and
eventually turn off IPv4.
NAT444
Residential Access Aggregation Edge Core

NAT44
CGN
NAT44
NAT44 IPv4
Private IPv4 Private IPv4 (SP Assigned domain) Public IPv4

(Subscribers)
Figure: NAT444

Technical Document
 Short-term solution to public IPv4 exhaustion issues without any changes on RG and SP
Access/Aggregation/Edge infrastructure
 Subscriber uses NAT44 (i.e. IPv4 NAT) in addition to the SP using CGN with NAT44 within its
network
 CGN NAT44 multiplexes several customers onto the same public IPv4 address
 CGN performance and capabilities should be analyzed in planning phase
 Long-term solution is to have IPv6 deployed
IPv6 over L2TP
RG
IPv4 IPv6
BNG LNS
RG
IPv4oPPPoE or IPv4oE IPv4
IPv6oPPPoL2TPv2 IPv6
Figure: IPv6 over L2TP
 Dual-Stack IPv4/IPv6 service on RG LAN side

 PPPoE or IPv4oE Termination on IPv4-only BNG
 L2TPv2 softwire between RG and IPv6-dedicated L2TP Network Server (LNS)
 Stateful architecture on LNS, offers dynamic control and granular accounting of IPv6 traffic
 Limited investment & impact on existing infrastructure

Technical Document
6RD

6RD CE
6RD BR
IPv6
6RD CE
6RD BR
IPv4/IPv6 IPv4 IPv4/IPv6
Figure: 6RD
 Introduction of two Components: 6rd CE (Customer Edge) and 6rd BR (Border Relay)
 Automatic Prefix Delegation on 6rd CE
 Simple, stateless, automatic IPv6-in-IPv4 encap and decap functions on 6rd (CE & BR)
 IPv6 traffic automatically follows IPv4 Routing
 6rd BRs addressed with IPv4 anycast for load-balancing and resiliency
 Limited investment & impact on existing infrastructure
DS-Lite

B4
6RD BR
IPv4
AFTR
B4
IPv4/IPv6 IPv6
Figure: IPv4 via IPv6 Using DS-Lite

Technical Document
 Access, Aggregation, Edge and Core migrated to IPv6. NMS/OSS and network services
migrated to IPv6 as well (DNS, DHCP)
 IPv4 Internet service still available and overlaid on top of IPv6-only network
 Introduction of two Components: B4 (Basic Bridging Broadband Element) and AFTR (Address
Family Transition Router)
 B4 typically sits in the RG
 AFTR is located in the Core infrastructure
AFT64

6RD BR DNS64
NAT64
Public IPv4 Internet
IPv4 DataCenter
IPv6 Only Connectivity IPv4 Only
Figure: Connecting IPv6-only with IPv4-only (AFT64)
 AFT64 technology is only applicable in case where there are IPv6 only end-points that need to
talk to IPv4 only end-points (AFT64 for going from IPv6 to IPv4)
 AFT64:= stateful v6 to v4 translation or ―stateless translation, ALG still required
 Key components includes NAT64 and DNS64
 Assumption: Network infrastructure and services have fully transitioned to IPv6 and IPv4 has
been phased out

Technical Document
Migration/Deployment
Infrastructure
Before we start talking about different migration and deployment strategies, let us talk about the
different services that a service provider generally provides to its customers
MPLS VPNs
The leading VPN technology nowadays is MPLS VPNs which aims mainly to support customers who
want to achieve connectivity among different branches (locations)
MPLS VPNs come into different flavors, either L2 (and this holds as well many implementations
setups as per the requirements) and L3 (in which the provider is involved in the routing which some
customers will not choose due to security concerns
Branch
HQ
VPLS
Virtual Private LAN
Service
Branch
HQ
Figure: MPLS VPN (VPLS)

Technical Document
CE PE PE CE
Ethernet Port-to-port
Pseudowire
CE PE PE CE
Ethernet VLAN
Pseudowire
Figure: MPLS VPN (EoMPLS)

VPLS service provided relies mainly on BGP auto-discovery setup (point-to-multipoint) with LDP
based signaling
Regarding L3VPN service, as known, each customer has its own routing table (VRF) for which routes
of concern are imported/exported independent from any other customer
Customer 1 Customer 2
PE MP-iBGP PE
Provider
network
Customer 2 Customer 1
Customer 1 routing table
Customer 2 routing table
Global routing table
Figure: MPLS L3VPN

Technical Document
ADSL
Asymmetric digital subscriber line (ADSL) is a type of digital subscriber line (DSL) technology, a data
communications technology that enables faster data transmission over copper telephone lines rather
than a conventional voice-band modem can provide. ADSL differs from the less common symmetric
digital subscriber line (SDSL). In ADSL, Bandwidth and bit rate are said to be asymmetric, meaning
greater toward the customer premises (downstream) than the reverse (upstream). Providers usually
market ADSL as a service for consumers for Internet access for primarily downloading content from
the Internet, but not serving content accessed by others
ISP Network/
Internet
Modem
Multiplexer
Computer
(Internet
connection)
Figure: ADSL service

As well, the PPPoE pools reserved for this service is redistributed into the IGP and advertised to
upper layer control plane devices to gain Internet access, i.e. the customers traffic is part from the
global routing table
WiMAX
WiMAX (short for Worldwide Interoperability for Microwave Access) is a technology standard for long-
range wireless networking. WiMAX equipment exists in two basic forms - base stations, installed by
service providers to deploy the technology in a coverage area, and receivers, installed in clients.
WiMAX supports several networking usage models:
1. a means to transfer data across an Internet service provider network, commonly called
backhaul
2. a form of fixed wireless broadband Internet access, replacing satellite Internet service
3. a form of mobile Internet access to competes directly with LTE technology

Technical Document
Host / built-in
WiMAX Adapter
Internet
Base Station
Residential
Internet
Access
Figure: WiMAX Service
3G/4G
With the rapid development of communication, each individual has its own small portable laptop
(Cellphone), Internet access to these devices as well as to residential are now provided by means of
what so called 3G and 4G

Technical Document
Internet
CGN
ISM/
VSM
Access
Network
Users
Figure: 3G/4G Services
Implementing IPv6
Implementing IPv6 in your network does not require tearing down your aging IPv4 network and
replacing it with a new IPv6-enabled network. Instead it is possible – usually even wise – to run the
IPv4 and IPv6 networks in parallel in what the industry calls a “dual-stack” network, thus adding IPv6
capabilities to your network’s existing IPv4 capabilities. While such an endeavor is certainly not trivial,
it might be easier than your think.
The following article introduces a six step process for successfully implementing IPv6. It has served
me well in past deployments and will hopefully give you some ideas and guidance

Technical Document
Goal
Dual-stack as defined in RFC 4213 refers to side-by-side implementation of IPv4 and IPv6. In this
case both protocols run on the same network infrastructure, and there’s no need to encapsulate IPv6
inside IPv4 (using tunneling) or vice-versa. This approach has to be considered the most desirable
IPv6 transition mechanisms until IPv6 completely supplants IPv4. While it avoids many complexities
and pitfalls of tunneling, it is not always possible to implement, since outdated network equipment
may not support IPv6 at all.
The goal of the highlighted implementation steps in this article will focus on implementing dual-stack
in an existing network. Such a network could be a data center network, a campus network, a Wide
Area Network, or even wireless network. You should still have a look at other transition mechanism
and decide what best suits your requirements.
Training Deploy
Network
and IPv6 in the
Optimization
Education network
1 2 3 4 5 6
Managing Enable
Network IPv6 Network
Audit address Services
space
Figure: Steps to implement IPv6
Training and education

While IPv6 is very similar to IPv4, it is still different enough to stumble at times. An example for this is
the functionality of automatic address assignment via DHCPv6, which is quite different from DHCP in
the IPv4 world.
Therefore it is very important to train and educate the involved technical stakeholders in an IPv6
implementation project. Ensuring that network architects, engineers and support staff not only know
the theory of IPv6, but at least had some hands-on experience in a lab setup, is crucial to the overall

Technical Document
success.
A good start for IPv6 related training is the 6deploy IPv6 e-learning package. Other valuable
resources are the ARIN IPv6 wiki, the RIPE IPv6 Act Now page or APNIC’s Training page.
Network Audit
Next you need to find out not only what equipment you have in your network, but also if it will support
IPv6. The ugly truth is that products from almost all vendors have issues and bugs when it comes to
IPv6. In many cases even though IPv6 functionality is available according to product specifications,
these capabilities are either not tested at all or not to the breadth and depth of IPv4. Even if
equipment meets requirements of the NIST USGv6 or the IPv6 Ready logo program, it doesn’t mean
that it’s usable in your network for your use case.
With this it is unfortunately unrealistic to just “move” an Enterprise network to IPv6, as you can’t
necessarily believe all the vendor specifications. Instead you will have to go beyond the pure
cataloging of your equipment and actually need to test the required IPv6 functionality yourself.
For missing or broken IPv6 functionality, you will then have to work with the product’s vendor to
acquire a fix, e.g. via a software upgrade or update. Often it is not possible to update the software
and a hardware upgrade is required. In case the vendor cannot provide such a fix, or at least a
roadmap with a firm timeline on anticipated fixes, it is highly recommended that you completely
replace this vendor’s product.
As the outcome of this step, you should have information on what equipment you use, what can be
made to support IPv6 via software changes, what needs a hardware swap and especially within
which time frame you can realistically expect all these upgrades and swaps to happen
Network Optimization
The IPv6 implementation in a network is often a quite large endeavor. But it is also your perfect
chance to clean up your existing network – which some might even call a “mess”. Most enterprise
networks have organically grown over time into what they are today and include numerous artifacts
from different implementation phases.
As such, you should have another look at your existing network and attempt to optimize it. Whatever
you can optimize and especially simplify in your existing network today will make your life easier
when adding IPv6.
While optimizing your network, you should use the following guidelines:
Simplify: Reduce the complexity of your network as much as possible, as you’ll end up adding
complexity unintentionally over time again anyways.
Unify: Standardize on components within your network. More coherence leads to less headaches
while managing components.
Amplify: As your previous network plans probably ended up being too small, this time plan big, really
big!

Technical Document
Keep in mind: If you can get rid of a component altogether, there is no need to upgrade it to IPv6.
Managing the IPv6 address space
Nowadays it is very easy to acquire IPv6 address space as well as transit for it. If you already own
IPv4 address space with your own Autonomous System (AS) you can request IPv6 address space
from your Regional Internet registry (RIR). For transit of this IPv6 address space contact your existing
IPv4 peering partners who can usually provide you with IPv6 peering as well. In case they do not
offer IPv6 peering it’s a good idea to look for another ISP, one that can.
If you do not own your address space, but use IPv4 addresses provided by your service provider, you
can usually receive IPv6 addresses and associated transit from this service provider.
You will either receive a /32 or a /48 IPv6 address space. In IPv6 addressing, a /32 results in 65,536
subnets, each of which is the size of a /48. Each /48 contains 65,536 /64s, which is the minimum size
of a subnet. Each /64 contains 18,446,744,073,709,551,616 IPv6 addresses. This means that each
IPv6 /32 allocation contains 4.29 billion /64s. This is probably enough address space for a typical
enterprise network. But on the other hand: What are we gonna do with all these addresses? That’s
where a solid IPv6 address plan comes into the picture, allocating this address space to locations
and/or functions. While you might not necessarily have such an address plan for your IPv4 network, it
is crucial to have one for IPv6.
If you ask “Why?” consider the following analogy: It might be possible to put together a puzzle with a
few hundred or even thousand pieces without looking at the cover and seeing the picture of the final
puzzle. But it’s pretty much impossible to do the same with a few million or billion puzzle pieces.
A very good resource on IPv6 address planning is RIPE’s document on Preparing an IPv6 address
plan or the book IPv6 Address Planning from Infoblox’ IPv6 evangelist Tom Coffeen.
As highlighted in my previous article “IPv6 deployment: Using link-local addresses as default
gateway“, I’m using the ULA address range fd53::/64 for DNS Anycast, where my DNS resolvers are
fd53::11 and fd53::12 everywhere in the network. Also I use the Link Local address fe80::1 as the
default gateway for static addressing. Following RIPE’s recommendation I reserve a /64 network for
point-to-point links, while addressing them as a /127 for 2 member addresses or /126 for 4 member
addresses (e.g. for VRPP/HSRP). Furthermore I only subnet on nibble boundaries (network mask
which aligns on a 4-bit boundary), making it easier to perform the math around IPv6 addresses and
subnets.
Last but not least: At this point often the question comes up whether to use ULA addresses
throughout the entire company along with IPv6-to-IPv6 Network Prefix Translation (RFC 6296)
or IPv6-to-IPv6 Network Address Translation (NAT66), or not. This question is especially posed
based on the desire to simulate the usage of IPv4’s RFC 1918 address space along with NAT,
coupled with the false believe that this provides security to your network. In short: It doesn’t.
From my experience of using both approaches, Global Address space as well as ULA with NPT, I
could not find any benefit of the ULA+NPT approach. Instead it only created more hassles and work.
With this approach you now have to manage twice the amount of address space. So instead be
happy that NAT is (hopefully) finally dead with IPv6 and use Global Unicast addresses.
Technical Document
Deploy IPv6 in the network

Once you made it up to here, it’s time to put your preparation into action. Surprisingly this step will be
very easy, if you’ve done all your homework right. Configuring IPv6 addresses on network device
interfaces is usually straight forward and configuring routing protocols – such as OSPFv3 – with IPv6
is also quite simple.
For Cisco IOS devices you can refer to the IPv6 Implementation Guide or the book Cisco Self-Study:
Implementing Cisco IPv6 Networks. Also recent course material for the Cisco Certified Network
Associate (CCNA) Routing and Switching certification includes details on implementing IPv6.
For address management in IPv6 you have different options as I described in the previous article
“IPv6 Address management of hosts“. In real life you will usually either use manual assignment of
IPv6 addresses to e.g. server systems, or Stateful DHCPv6, where O(ther) and M(anaged) flags are
set, while the (A)utonomous flag is unset inside the Router Announcements (RA). While address
assignment via Stateless Address Auto Configuration (SLAAC) is often touted as one of the benefits
of IPv6, it still requires DHCPv6 to assign DNS resolver information due to the lack of RDNSS (RFC
6106) support in modern client OSes. This makes this approach as complicated and complex as
using Stateful DHCPv6 right away.
Enable Network Services
After configuring your network components, ranging from L3 switches, over firewalls and routers to
load balancers or WAN accelerators, you’re almost ready to connect end-users via IPv6. What’s
missing are network services such as Domain Name System (DNS), Network Time Protocol
(NTP), Remote Authentication Dial In User Service (RADIUS) or Microsoft Active Directory.
While the network services available in your network might vary and differ from the list above, only by
making services available via IPv6, are you actually adding value via IPv6. Otherwise your IPv6
implementation is like a highway without any on or off ramps.
Similar to the previous step, enabling IPv6 on devices or hosts for such network services is usually
straight forward once you have verified that the product in its current version actually supports IPv6.

Technical Document
Proposed Solution
Core, distribution or access layers are native IPv4 with MPLS environment in place (either as a
transport inside among core links, or with the different VPNs service to the customers)
The most recommended solution to implement is dual stack for the core network with 6PE for MPLS
environment and we will talk about advantages and disadvantages in the coming sections
IPv4 and/or IPv6

Dual stack App IPv4 + IPv6 Edge IPv4 + IPv6 Edge Edge
PE P P PE CE IPv4
IPv4/
IPv6
CE IPv6
IPv4 IPv4 configured
Core interface
P P PE
PE CE IPv6
IPv6 configured
interface
Some or all
interfaces in cloud
are dual configured
Figure: Dual stack implementation
Where to start the implementation, edge to core or core to edge?
Figure: Core to edge
 Core devices usually the safest to add IPv6

 Address more difficult issues such as security and management
 Gain operational experience before going to the edge

Technical Document
 Consider the best when using dual stack strategy
Figure: Edge to core
 More difficult
 Relies more on tunneling Faster when need to connect endpoints to Data Centers and apps
that are IPv6-enabled
 When older devices in core cannot support IPv6
Advantages
 Most effective transition mechanism

 Allows for migrating devices on a more gradual basis, rather than all at once
 Implementation of IPv6 using dual stacks is the simplest approach (the change is driven by
DNS)
 At the upper protocol layers, an application can use either IPv4 or IPv6 to communicate
 Both
 IPv4-only and IPv6-only devices can communicate with a dual stacked node
 Simplest approach to adding IPv6 support to a group of interconnected router
 Integrated routing protocol (IS-IS and BGP)
 Version-specific routing protocols (OSPF)
 The approach is transparent to the end users
 Fewer pieces of equipment need to be converted (In this approach, only the backbone or core
routers need to be converted first)
 No tunneling mechanisms in the internal network are required, nor are the headaches that can
occur when using them
 Good for content distribution and global services (Internet)

Technical Document
Disadvantages
 Memory considerations for larger routing tables

 Must provide a DNS resolver library capable of dealing with the IPv4 A records as well as the
IPv6 AAAA records
 Device simultaneously supports IPv4 and IPv6
 Network management tools designed for an IPv4 network may not work the same way in an
IPv6 environment
 Many existing host and network security and administration tools may not provide full-fledged
support for IPv6
 Firewall rule sets and other security controls that stop unwanted IPv4 traffic are unlikely to be
effective at stopping any IPv6 traffic (Need parallel security rules to address IPv6 traffic)
 Manage and monitor 2 layer 3 stacks
 Every interface requires both an IPv4 address and an IPv6 address
 The router contains two independent routing tables
Now, let us go through the 6PE solution for MPLS
MP-iBGP Session
V6 V6
6PE 6PE
P P
V4
V6
Dual Stacked MPLS Backbone
Routers
P
6PE 6PE
V6 V4
V4
IPv4 MPLS
Figure: IPv6 Provider Edge (6PE) over MPLS

Technical Document
The below points briefly talks about this feature (in previous section some points were mentioned,
but to be mentioned again due to the solution proposed)
 IPv6 global connectivity over and IPv4-MPLS core

 Transitioning mechanism for providing unicast IP
 PEs are updated to support dual stack/6PE
 IPv6 reachability exchanged among 6PEs via iBGP (MBGP)
 IPv6 packets transported from 6PE to 6PE inside MPLS
Note: when activating the neighborship between the PEs under the IPv6 address-family, the BGP
session will be tore down
Benefits/Drawbacks:
 Core network (Ps) untouched

 IPv6 traffic inherits MPLS benefits (fast re-route, TE, etc.)
 Incremental deployment possible (i.e., only upgrade the
 PE routers which have to provide IPv6connectivity)
 Each site can be v4-only, v4VPN-only, v4+v6, v4VPN+v6
 P routers won’t be able to send ICMPv6messages (TTL expired, trace route)
 Scalability issues arise as a separate RIB and FIB is required for each connected customer
 Good solution only for SPs with limited devices in PE role
References:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_data_sheet09186a008052edd3.h
tml
Addressing
The questions arise, what type of addressing to deploy internally? It depends :)
 Unique Local Addresses (ULA) –FC00::/7

Prefix FC00::/7 is reserved by IANA for ULA(bit 8 determines if locally or centrally assigned,
so ULA or ULA-Central)
 Global-only –2000::/3
Recommended approach, but breaks topology hiding
 ULA +Global
Allows for the best of both worlds BUT at a price –much more address management with
DHCP, DNS, routing and security

Technical Document
Table: Link Level – Prefix Length Considerations
64 Bits <64 Bits >64 Bits

Recommended by RFC3177 Considered best practice Address space conservation
and IAB/IESG
Consistency makes 64 bits offer more space for Complicates management
management easy hosts than the media can
support
Must for SLAAC (DHCPv6 - Must avoid overlap with
also) specific addresses:
 Router Anycast
 Embedded RP
 ISATAP addresses
Significant address space loss - Special cases:
 /126 – valid for P2P
 /127 – valid for P2P
 /128 - Loopback
The most common prefix allocation practices:
 Many SPs offer /48, /52, /56, /60 or /64 prefixes

 Enterprise customers receives a /48
 Large Enterprises receive one or more/48 prefixes
 Small business customers receive /52 or /56
 BB customers using DHCP-PD receives /56 or /60
Security considerations
How individual sites and networks become compliant depends on how much IPv6 affects them and
how much planning they do. Security compliance may seem relatively easy because the IPSec
standard is embedded into IPv6 rather than bolted on, as it is with IPv4. That can be reassuring, but
there is a good deal of confusion surrounding IPv6 security and it's important to understand the
details.
An IPv6 transition shouldn't even begin until an enterprise verifies its security devices comply with
IPv6. All firewalls and intrusion detection and prevention must support IPv6, and the enterprise must
ensure all access control list rules are migrated from IPv4-compliant devices to IPv6-compliant
devices.
In addition, compliance and governance monitoring tools have to be able to accommodate IPv6,
probably sooner than other management tools, in order to provide accurate compliance auditing and

Technical Document
reporting. Migrating compliance to an IPv6 environment also requires a clear understanding of what
kinds of application and user traffic are traversing the network.
Once you've verified and prepared your devices, take the following frequently misunderstood points
into consideration:
1. IPv6 security defenses must apply to IPv4 networks
Organizations with IPv4 networks may think that they aren't susceptible to IPv6-based attacks, but
experts say that's not the case. Most new operating systems and mobile devices -- including
Windows, Mac OS X, Ubuntu Linux, iOS and Android -- ship with IPv6 automatically enabled, so if
you run or audit an IPv4 network, there are systems on it just waiting to communicate over IPv6. This
creates an opportunity for exploitation by hackers and malware.
The Windows HomeGroup feature, for example, uses TCP over IPv6 for local network management.
Every system with IPv6 enabled has a link-local address that other machines on the local network
can communicate with. This allows an intruder with access to the local network -- directly or through a
compromised IPv4 system -- to access and attack the IPv6 interfaces of other local devices.
2. Mandatory IPSec is no guarantee
A widely assumed benefit of IPv6 is IPSec support, but the reality is more nuanced. While IPv6
supports IPSec for transport encryption, actually using IPSec is not mandatory and it is not configured
by default. IPSec requires extensive configuration to be properly secured, even when it has been
enabled. Details vary depending on your hardware and OS, so contact your vendors for
implementation specifics.
3. Man-in-the-middle attacks are possible
Since IPv6 doesn't use Address Resolution Protocol (ARP), it's sometimes assumed to prevent man-
in-the-middle-attacks. In fact, IPv6 uses ICMPv6 to implement the Neighbor Discovery Protocol,
which replaces ARP for local address resolution. The Neighbor Discovery Protocol is just as
vulnerable to man-in-the-middle attacks as ARP -- if not more so. A single compromised internal node
can expose all local assets to the global IPv6 network through a simple route advertisement.
4. The problem with NAT
While some IPv6 misconceptions revolve around its perceived security, some believe it's less secure
than IPv4 due to a lack of NAT. Network Address Translation (RFC 1918) allows organizations to
assign private, un-routable IPv4 addresses to many devices, which are then provided connectivity to
the Internet via a limited number of public IPv4 addresses.

Technical Document
The private addressing of NAT can be mistaken as a security feature, and its omission is frequently
cited as a reason not to deploy IPv6. But IPv6s expanded address space solves the original problem
that NAT addressed. The real security of NAT was provided by the accompanying usage of stateful
inspection of inbound traffic. An organization should not be any more or less secure with IPv6 as
opposed to NAT, as long as it is combined with appropriate access controls and inspection tools.

IPv6 Migration Plan

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IPv6 Migration Plan

Uploaded by

Copyright:

Available Formats

2018

IPv6 Migration/Deployment Plan

IPV4 ADDRESSING STATUS ..................................................................................... 4

IPV6 BENEFITS ..................................................................................................... 6

IPV4 VS IPV6 ........................................................................................................ 7

IPV6 ADDRESSING ................................................................................................ 8

IPV6 ADDRESS ARCHITECTURE ............................................................................... 8

IPV6 ADDRESS ALLOCATION ................................................................................ 15

IPV6 PREFIX LENGTH CONSIDERATIONS ................................................................. 16

IPV6 MIGRATION ................................................................................................. 21

DUAL STACK ...................................................................................................... 22

Static NAT-PT ............................................................................................................................................................. 38

Dynamic NAT-PT ........................................................................................................................................................ 38

NAT-PT restrictions ................................................................................................................................................... 38

IPv6 over MPLS .......................................................................................................................................................... 39

Why IPv6 over MPLS .......................................................................................................................... 40

CONFIGURATION EXAMPLES ................................................................................ 48

6VPE IOS ...................................................................................................................................................................... 91

6VPE IOS-XR ............................................................................................................................................................. 114

CARRIER GRADE NAT ........................................................................................ 141

NAT, PAT and overloading ............................................................................................................. 142

The NAT444 model ........................................................................................................................... 142

Carrier Grade IPv6 solutions ......................................................................................................... 144

IPv6 over L2TP........................................................................................................................................................... 145

AFT64 .......................................................................................................................................................................... 147

MIGRATION/DEPLOYMENT .................................................................................. 148

Implementing IPv6 ............................................................................................................................ 152

Proposed Solution ............................................................................................................................ 157

Eng-mssk.blogger.com Page 3 of 163

IPv4 addressing status

Figure: Projection of consumption of remaining RIR address pools

Eng-mssk.blogger.com Page 4 of 163

Figure: RIPE NCC address allocation rate

Eng-mssk.blogger.com Page 5 of 163

1. More efficient routing

2. More efficient packet processing

3. Directed data flows

4. Simplified network configuration

Eng-mssk.blogger.com Page 6 of 163

5. Support for new services

Aspect/Protocol version IPv4 IPv6

Eng-mssk.blogger.com Page 7 of 163

Eng-mssk.blogger.com Page 8 of 163

Figure: IPv6 address space breakdown

Eng-mssk.blogger.com Page 9 of 163

3 Bits 45 Bits 16 Bits 64 Bits

Global Routing Prefix Subnet Interface ID

Figure: IPv6 Global Unicast Address

Eng-mssk.blogger.com Page 10 of 163

Figure: IPv6 Link Local Address (LLA)

Eng-mssk.blogger.com Page 11 of 163

Figure: IPv6 Unique Local Address (ULA)

Eng-mssk.blogger.com Page 12 of 163

Multicast Group ID – 112 Bits

F F 0 RP T Scope R = 1 = embedded RP , (then PT=11)

Flag = PT = 11 = Unicast based mapping

Figure: IPv6 Multicast address

 FF::/8 is the IPv6 equivalent of 224/4

Eng-mssk.blogger.com Page 13 of 163

Figure: IPv6 unicast to multicast mapping

Figure: IPv6 multicast embedded RP format address

Eng-mssk.blogger.com Page 14 of 163

IPv6 address allocation