migrating networks and services to ipv6...migrating routed networks and services to ipv6 alcatel-...

Migrating routed networks and services to iPv6 Residential bRoadband and business VPn seRVicesaPPlication note

table of contents

abstract / 1

1. introduction / 1

1.1 iPv4 versus iPv6 / 1

1.2 timing and process of iPv6 migration / 3

1.3 scope and impact / 4

2. iPv6 for business VPn services / 6

2.1 iPv4-iPv6 dual stack / 7

2.2 6in4 tunneling / 7

2.3 6Pe / 8

2.4 6VPe / 9

2.5 service router support / 9

3. iPv6 for residential services / 10

3.1 iPv6 (dual-stack) subscriber management / 10

3.2 iPv4 continuity / 12

3.3 service router support / 17

4. conclusion and recommendations / 17

5. Further reading / 18

6. abbreviations / 18

Migrating Routed networks and services to iPv6alcatel-lucent aPPlication note

1

abstractIPv6 migration has become an important topic for most network operators as the projected increase of IP-enabled applications, services and consumer devices is expected to exhaust the available IPv4 address space in the coming years.

This application note reviews the various methods, techniques and standards that are being developed to migrate routed networks and services to IPv6, with a focus on residential broadband and business virtual private network (VPN) service deployments. This information will aid network operators in formulating an IPv6 deployment strategy that meets their operational and business objectives for service continuity, innovation and expansion.

1. introductionIn the late 1980s it was predicted that the Internet would run out of unallocated IPv4 address space somewhere around 1994. This gave rise to much concern because such an occurrence would effectively limit further growth of the Internet as no addresses would be available to connect additional devices to it. Thus, the Internet Engineering Taskforce (IETF) developed a two-pronged strategy to deal with the issue:

1. Immediately adopt a series of short-term measures, most notably classless interdomain routing (CIDR), to more efficiently and flexibly use the available IPv4 addressing space.

2. Initiate a design effort for a next-generation Internet Protocol (IPng) as the long-term solution. This development effort later became known as IPv6 and is described in Request for Comments (RFC) 2460.

The short-term measures proved to be very effective in deferring public IPv4 address exhaustion, but the adoption of IPv6 has been slow: The current allocated IPv6 address space represents less than 1 percent of the IPv4 connected devices in use. Today, more than 12 years after RFC 2460 was issued, we again find ourselves in a situation where IPv4 address exhaustion is imminent, but this time there are no easy fixes. This is no cause for panic; it is simply a fact that network equipment vendors and operators must plan and prepare for, as solving the IPv4 address exhaustion problem is not trivial and operators who find themselves unable to obtain more IPv4 addresses will experience a significant impact on their business.

1.1 iPv4 versus iPv6The key issue around IPv6 migration is rooted in the fact that while IPv6 was meant to be an evolution of IPv4 and carries almost all of its functionalities forward, it is not backwards compatible. IPv6 impacts the data path as well as routing, control and management planes as it introduces a different packet header format in which IP addressing is extended from 32 to 128 bit fields. Rarely used IPv4 header fields and options were dropped or become part of options extension to reduce fixed packet overhead (Figure 1).


2

Figure 1. IPv4 and IPv6 packet header formats

Other important differences are in the control protocols. IPv6 routing relies heavily on Internet Control Message Protocol (ICMP) for auto-discovery of neighbors. In IPv4, neighboring routers are defined by means of configuring a default gateway address and the use of Address Resolution Protocol (ARP), while networks often block ICMP messages for security reasons.

Ironically, the success of stop-gap solutions that prevented IPv4 address exhaustion 10 years ago has vastly aggravated the scale and magnitude of the IPv4 migration problem, as the Internet has witnessed enormous growth in the past decade. Fortunately, continuous innovation in IP applications, technologies and routing platforms has occurred in parallel. Hardware and software on both client and server side are being prepared for IPv6. Microsoft’s Windows 7 Operating System, for example, is fully IPv6 enabled (Figure 2). Since World IPv6 Day in 2011, popular Internet content providers like Google, Yahoo, Facebook, and more than 2400 others have made a concerted effort to make their services equally available over IPv4 and IPv6. All routing vendors are already manufacturing IPv6-capable products.

Figure 2. PC operating system support for IPv6 support

0 4 8 12 16 20 32

0 4 12 16 24 32

Version

Version

H. Len TOS Total length

TTL

Source address

Destination address

Source address

Destination address

Options

Protocol Header checksum

Identification Fragment offsetFlags

Flow labelTraffic class

Payload length Hop limitNext header

Apple OS XWindows Vista/7WIndows XPFeature

YesYesYesIPv6-capable

YesYesNoIPv6 by default

YesNoDHCPv6 support

Yes

Yes

YesNoDNS over IPv6 support

Yes

Yes

YesNoIPv6 over PPP support

YesNoRouted IPv6 RG support

key issue: iPv4 clients are not

interoperable with iPv6 servers

without a translation function,

nor are iPv4 routers able to

route native iPv6 traffic. since

the internet is currently almost

exclusively based on iPv4, only

iPv4 clients can access this

content. therefore, the introduction

of iPv6 alone does not solve the

iPv4 address exhaustion problem

in the short term; all subscribers

will still need an iPv4 address in

order to access the vast majority

of legacy internet servers that

are still running iPv4. therefore, a

two-pronged strategy is required:

“dual stack” support for both iPv4

and iPv6 and an iPv4 continuity

strategy to prevent iPv4 address

exhaustion from happening.


3

Along with other equipment vendors, Alcatel-Lucent is fully committed to IPv6. It is actively contributing to IPv6 standardization and product validation through independent certification by organizations such as the IPv6 Forum (www.ipv6forum.com), a conformance and interoperability testing program of IPv6 capabilities.

1.2 timing and process of iPv6 migrationAlthough IPv6 migration has been discussed for years, large scale IPv6 deployments are relatively rare. This is not only because it is a large, complex and costly issue for carriers for which the business case remains largely elusive. The IPv4 address exhaustion problem does not have the same type of “drop dead” deadline as the Y2K issue had, nor does it enable new revenue applications. IPv4 address exhaustion is rather a flexible barrier in which increasing IPv4 address shortage will create more and more issues until the registration authorities (IANA and the five Regional Internet Registries (RIRs)) run out of unallocated addresses.

As the registries run out, one could envision that organizations with an IPv4 address space surplus may more efficiently allocate this resource. Service providers will find ways to further optimize IPv4 address space usage by renumbering address schemes and provisions such as Large Scale network address translation (NAT), which will be discussed later.

Organizations, applications and countries will migrate at different speeds. For example, the United States Government and Department of Defense has been rather aggressive by setting its original IPv6 migration deadline at 2008. Countries in the Asia Pacific region are likely to migrate sooner than other regions, as they joined the Internet community at a time when IPv4 address allocations had already begun their rationing process and APNIC IPv4 addresses were exhausted in April 2011. Because a large part of the growth in IP user devices is in mobile, and mobile has fewer legacy constraints than wireline network applications, mobile networks are transitioning earlier.

The expected outcome is a gradual transition process that will look roughly like Figure 3.

Figure 3. IPv4 to IPv6 transition

Today

: early ad

opters tu

nnel

IPv6

dual stack cap

ability

Intro

duce IP

v4

overlo

adin

g (NA

T)

Transition (24 months)

2010 2011 2012 2013

IPv4 free addresses

April 2011 – APNIC exhausts IPv4 address pool

Feb 2011 – IANA exhausts global IPv4 address pool

IPv6 adoption

Runout (36 months)

http://www.ipv6forum.com


4

The timeline of this migration consists of the following phases:

1. Introduction of an IPv6 stack in addition to IPv4 in a dual-stack approach (red bar).

2. A prolonged transition phase (yellow bars) in which native IPv4 and IPv6 clients (and servers) will coexist with dual-stack clients (having both IPv4 and IPv6 addresses). Large Scale NAT is expected to be adopted widely as a transition tool to stretch the use of IPv4 addresses.

3. An IPv6 post-transition phase (green bars) in which almost all IP clients and servers have moved over to IPv6. Once the transition to IPv6 gains critical mass there will be little incentive to maintain IPv4 addressing. IPv4 addressing and devices will naturally phase out as old content is ported to IPv6 and new content and applications become exclusive to IPv6.

Obviously the duration of the transition phase is the hardest to estimate, but definite driving cost incentives exist for not prolonging this phase longer than necessary. Interim remedies to prolong the life of the IPv4 address space will become increasingly cumbersome and costly. Such remedies can serve only to postpone IPv6 migration and will take away investment resources that could be used to accelerate the transition to IPv6.

1.3 scope and impactThe scope of the IPv6 transition is far reaching:

• ClientdevicessuchasIPphones,mobiledevices,PCs,PCoperatingsystemsand PC applications

• Internet-basedwebandapplicationserversandmiddleware

• NetworkdeviceswithLayer3capabilitiessuchashomegateways,IProutersand IP digital subscriber line access multiplexers (DSLAMs)

• AuxiliaryInternetdevicessuchasDomainNameSystem(DNS)Servers,DynamicHost Configuration Protocol (DHCP) servers, firewalls, virtual private network (VPN) gateways, intrusion detection systems, caching systems and load-balancers

• Network,serviceandsubscribermanagementandoperationalsupportsystemsingeneral

The scope discussed in this application note focuses on network infrastructure and ranges from the Residential Gateway to the interface points into the Internet and service back ends (Figure 4), encompassing broadband service access (Alcatel-Lucent 7300 Intelligent Services Access Manager [ISAM] series), broadband service aggregation, edge and core (Alcatel-Lucent 7450 Ethernet Service Switch [ESS] and the Alcatel-Lucent 7750 Service Router [SR]).

The application note will examine the IPv6 transition of both business and residential IP services.

iPv6 migration is a matter of securing long-term business continuity and growth for internet-based applications, services and content, which is in the interest of every internet user and provider. service providers have to balance their investments between temporary measures to extend the life of iPv4 versus a strategic investment in obtaining an iPv6-capable infrastructure.


5

Figure 4. Network scope of IPv6 transition

The supported IPv6 transition strategy aligns with the plan crafted by the original IETF IPng working group and is aimed at meeting four basic requirements:

• Incrementalupgrade.ExistinginstalledIPv4hostsandroutersmaybeupgradedto IPv6 at any time without being dependent on any other hosts or routers being upgraded.

• Incrementaldeployment.NewIPv6hostsandrouterscanbeinstalledatanytimewithout any prerequisites.

• Easyaddressing.WhenexistinginstalledIPv4hostsorroutersareupgradedtorundual stack — IPv4 and IPv6 — they may continue to use their existing IPv4 address. They do not need to be assigned new IPv4 addresses.

• Minimizestart-upcostsandpreparationworktoupgradeexistingIPv4systemsto IPv6 or to deploy new IPv6 systems.

Broadbandservice edge

Network infrastructure

Centralized policymanagement

IP/MPLS

Optical core

Opticaltransport

IPcommunications

Voice, IPTV, Internet

BroadbandInternetservices

PersonalizedIPTV

7750 SR

Digitalhome

RGresidentialgateway

CPECustomerpremises equipment

LANSMB

Enteprise

LAN

VLL

VPLS

VPRN

Element andnetwork management

5780 DSC5620 SAM

BSA

Broadbandservice

aggregator

ISAMfamily

BSAN

MTU/POP

Broadbandservice access

node

7450 ESS

Multi-tenantunit

BNG/MSE

7750 SR

IP serversIP clients


6

2. iPv6 for business vPn servicesThis chapter describes IPv6 network transition scenarios for business services such as IP Virtual Leased Lines (VLL), Virtual Private LAN Services (VPLS) and Virtual Private Routed Network (VPRN) services (IP VPNs). Drivers are enterprises with a presence in IPv4 address-constrained geographies; government agencies; mobile business users; IPv6-based virtual computing and datacenter applications; and machine-to-machine and Radio Frequency Identification (RFID) applications. With the introduction of IPv6 clients and servers within the Ethernet LAN (E-LAN) and the Customer Location Equipment (CLE), IPv6-capable wide area network (WAN) services are becoming mandatory, while supporting existing IPv4 clients and servers as well.

The focus is VPRN (IP VPN) services. E-LAN (VPLS) and E-Line services operate on Layer 2 and are transparent to the use of IPv6 routing in the Enterprise domain (the customer and the service provider each manages their own routing domain). In Section 2.5 we talk about extension to Layer 2 services for IPv6 filters.

The assumption is that the VPRN service is delivered as a network-based service in which the Provider Edge (PE) routers are located at the edge of the service provider network (the Alcatel-Lucent 7750 SR in Figure 4). Since the multi-tenant unit/broadband service access node (MTU/BSAN) (access) and Ethernet Aggregation network (EAN) (aggregation) both typically operate at OSI Layer 2, they are transparent to IPv6 customer routing.

In summary, for the IPv6 transition of business services, the PE routers at the edge and the P routers in the IP core are the key elements that participate in routing traffic and are therefore affected by an IPv6 transition. Initially, the IPv6 world hoped everyone would adopt IPv6 and build dual-stack systems, but this did not happen. In order not to have to wait for every vendor to implement IPv6, tunneling solutions were defined to keep the P routers unchanged and impacting only the PE.

The following core network options exist to conduct this transition:

• IProutedbackbone:IPv4-IPv6dualstackand6in4tunneling(RFC4213)

• Multi-ProtocolLabelSwitching(MPLS)backbone:6PE(RFC4798)and6VPE (RFC 4659)


7

2.1 iPv4-iPv6 dual stackRunning IPv4-IPv6 dual stack encompasses enabling of native IPv6 routing at the edge and core of the network in addition to IPv4 routing. The relevant IPv6 routing protocol updates are OSPFv3 (RFC 2740), IS-IS IPv6 and MP-BGP for IPv6 support. IS-IS Multi-Topology (RFC 5120) allows the service provider to have different topologies for IPv4 and IPv6.

Figure 5. IPv4-IPv6 dual stack

Essentially the dual-stack approach logically results in two separate routing domains and addressing spaces that run as “ships in the night” while sharing a common physical network.

2.2 6in4 tunnelingWhile the dual-stack approach impacts both provider edge and core, 6in4 (RFC 4213) retains the IPv4 backbone in combination with a dual-stack network edge (Figure 6). IPv6 packets are carried in 6in4 tunnels over the IPv4 backbone by encapsulating them in IPv4 packets (protocol-id = 41).

Figure 6. 6in4 operation

PEPE

PEPE

PE

PE

PEPE

PE

PE

PE

IPv4 only

Dual-stackcore

IPv6core

Dual stack

IPv6 only

CE

PE(7750 SR)

IPv6

IPv4 backbone

6in4 tunnel

6in4 is not typically used by service providers directly, but it is often used to tunnel IPv6 over IPv4 Internet to tunnel brokering services.

IPv6

PE(7750 SR)

P

IPv4

P

IPv4

CE

IPv6

IPv4

IPv6

IPv4


8

2.3 6Pe6PE allows IPv6 domains to communicate with each other over an MPLS IPv4 core network. This architecture requires no backbone infrastructure upgrades and no reconfiguration of core routers, because forwarding is based on MPLS labels rather than on the IP header itself. It provides a very cost-effective strategy for IPv6 deployment.

6PE requires that MP-BGP be extended to be able to bind an MPLS label to the IPv6 route. The extension required is defined in RFC 4798, “Connecting IPv6 Islands Over IPv4 MPLS Using IPv6 Provider Edge Routers,” and is co-authored by Alcatel-Lucent. It is quite akin to 6in4 with the difference that the IPv4 backbone uses MPLS tunnels to encapsulate IPv6 traffic into IPv4 Label Switched Paths (LSPs).

From a control plane perspective, the main principles of the solution are in the following (Figure 7):

• The6PEMP-BGProutersaredualstack:IPv6towardstheCEandIPv4towardstheMPLS core.

• MP-BGPisusedbetween6PErouterstoexchangeIPv6reachabilityinformation.The6PE router uses the IPv6 Explicit Null label (Label 2) for all the IPv6 prefixes that it advertises, but it also accepts an arbitrary label from its peers. When a labeled packet is received, the IPv6 Explicit Null label indicates that an additional IPv6 route lookup is required.

• Theingress6PEextractstheIPv4addresscontainedintheIPv4mappedIPv6address.Then the ingress 6PE resolves this IPv4 address (using the IPv4 routing table) in order to get the label associated to the LSP for this destination. This “IPv4 label” has been populated in the IPv4 tables through regular IPv4 MPLS control plane procedures using IPv4 IGP and IPv4 label distribution protocols such as LDP. The IPv4 label is then stored along with the BGP label for the destination IPv6 subnet in the IPv6 forwarding table of the ingress PE router.

Figure 7. 6PE operation

IPv4/MPLSbackbone

LSP

LDPlabel

MP-BGPlabel

IPv6packet

CE

PE(7750 SR)

IPv6IPv6

PE(7750 SR)

P

IPv4

P

IPv4

CE

IPv6

IPv4

IPv6

IPv4

Ingress PE pushes 2 MPLS labels:• IPv6 Explicit Null label (2) received via MP-IBGP from egress PE• LDP tunnel label

6PE only uses the global routing table and is not VRF-aware, so it is mostly used for Internet backbone providers.

Egress PE inspects the MP-BGP labelafter popping the LDP tunnel labeland performs IPv6 route lookup toforward IPv6 packet to next-hop


9

2.4 6vPe6VPE is a solution for IPv6 backbone transport that relies on the use of MPLS/BGP VPNs (RFC 4364). It is defined in RFC 4659 (“BGP-MPLS IP Virtual Private Network Extension (VPN) for IPv6 VPN”) and also co-authored by Alcatel-Lucent. As with 6PE, dual-stack operation is required only at the edge (PE routers), while the MPLS core again carries IPv6 packets over MPLS tunnels and as such is IPv6 unaware(Figure 8). The major difference between 6VPE and 6PE is that 6VPE supports multiple IPv6 VRFs on the PE routers, while 6PE supports only the default global IPv6 routing table.

Figure 8. 6VPE operation

An example of a 6VPE application is the creation of a network VPN to transport residential IPv6 traffic or for offering dual stack business IP VPN services.

2.5 service router supportThis section gives a brief overview of IPv6 support for business services on the Alcatel-Lucent 7750 SR multiservice IP routing platform. The Alcatel-Lucent 7750 SR support all scenarios described above (dual-stack routing, 6in4, 6PE and 6VPE). Distributed hardware forwarding of IPv6 anycast, unicast and multicast packets with filters and quality of service (QoS) are supported over Ethernet, POS and TDM/Frame Relay. Operations, administration and maintenance (OAM) tools, Simple Network Management Protocol (SNMP) and high-availability features are fully supported for IPv6.

Hardware packet forwarding and comprehensive control plane functionalities are available for the IPv6 protocol family. Support for QoS models on IPv6 is similar to IPv4 QoS. IPv6 uses traffic class and the definition of the traffic class byte in the same fashion as the DSCP byte in IPv4, allowing classification of IPv6 packets based on DSCP field in the traffic class field to a forwarding class. Similar extensions are made to support Access Control Lists for IPv6 traffic. For Layer 2 services, ingress and egress filters have been extended to support IPv6.

IP multicast for the IPv6 address family is fully supported. Extensions to OSPFv3, IS-IS and static-route are implemented to support submission of routes into the IPv6 multicast RTM. Multicast Listener Discovery (MLD) is the “IPv6 version” of IGMP. It is a sub-protocol of ICMPv6 and allows each IPv6 router to discover the presence of multicast

Ingress PE pushes 2 MPLS labels(RFC4364):• Service label received via MP-IBGP from egress PE• LDP/RSVP tunnel label

Egress PE pops tunnel label andperforms IPv6 route lookup andforwarding within VRF selectedthrough MP-BGP service label

IPv4/v6VPN

IPv4/MPLSbackbone

LSP

LDPlabel

MP-BGPlabel

IPv6packet

CE

PE(7750 SR)

IPv6IPv6

PE(7750 SR)

P

IPv4

P

IPv4

CE

IPv6

IPv4

IPv6

IPv4

VRF VRF

MP-BGP


10

listeners on its directly attached links and to discover specifically which multicast groups are of interest to those neighboring nodes. The Alcatel-Lucent 7750 Service Router supports both MLDv1 and MLDv2.

The Alcatel-Lucent 7750 SR has been qualified by the United States Government’s Joint Interoperability Test Command as an IPv6-approved product. Please refer to specific product release documentation or your local sales representative for details on product features.

3. iPv6 for residential servicesWhen considering the migration of IP-based triple play services for the residential market, the emphasis is clearly on migrating broadband Internet access services where issues related to IPv4 address space exhaustion are most urgent due to the requirement of many applications for a public address. This is followed by IP-based telephony services (VoIP). Walled garden services such as IPTV typically operate in a private IP address space, which makes the migration to IPv6 less urgent.

Although the business case for migrating a network to IPv6 is outside the scope of this paper, a study conducted by Alcatel-Lucent shows that the largest share of upgrade cost is contributed by the IP clients (IPv6-capable Residential Gateways are around 30 percent more expensive than IPv4 versions), but the cost of these devices is steadily decreasing and the number increasing. In addition, the still limited content availability in a native IPv6 environment requires residential users to be issued an IPv4 address as well.

3.1 iPv6 (dual-stack) subscriber managementDual-stack subscriber management enables clients with access to IPv6 servers on the Internet. The Broadband Forum has defined the transition of residential broadband services to IPv6 in technical reports for both Point-to-Point Protocol (PPP) and IP over Ethernet (IPoE) fixed-access architectures, known as TR-177 (IPv6 for TR-101) and TR-187 (IPv6 for PPP DSL Access). Alcatel-Lucent is a contributor to both of these standards.

Broadband Forum TR-187, “IPv6 for PPP DSL Access,” focuses on the migration to IPv6 in an architecture that does not impact the access/aggregation network using tunneling techniques, including PPP or L2TP (Figure 9). The dual-stack aspect represents both IPv4 and IPv6 traffic on the single PPPoE session that shares a common subscriber identity and SLA profile. As a routed gateway is provided, one or more unique per subscriber IPv6 prefixes are delegated to the dual-stack router for use within the home network. DHCPv6 is used to provide prefix delegation and optionally Residential Gateway Wide Area Network address assignment.


11

Figure 9. TR-187: IPv6 for PPP-based access

Broadband Forum TR-177, “Migration to IPv6 in the Context of TR-101,” focuses on the support of IPv6 over Ethernet in a TR-101 access/aggregation network (Figure 10).

Figure 10. TR-177, Migration to IPv6 in the context of TR-101

The Dual-Stack IPoE Routed Gateway (RG) service runs over either the Broadband Forum TR-101 n:1 or 1:1 VLAN Ethernet architectures. It allows operators of the existing TR-101 network to deploy IPv6 over Ethernet services in conjunction with an existing IPv4 over Ethernet service. The dual-stack aspect represents both IPv4 and IPv6 traffic on the single subscriber circuit that shares a common subscriber identity, SLA and subscriber profile.

As a routed gateway is provided, one or more unique per subscriber IPv6 prefixes are delegated to the dual-stack router for use within the home network. DHCPv6 is used to provide prefix delegation and to optionally assign the RG a WAN address. The dual-stack router does not perform any NAT for IPv6 traffic; it will install a default route on the receipt of valid router advertisements from the BNG with a next-hop of the BNG link-local address.

Enhancements in the access network may be needed as IPv6 traffic is carried directly in Ethernet frames — such enhancements may be extended to the honoring of IPv6 Traffic Class (analogous to DSCP in IPv4) or a requirement for Lightweight DHCPv6 Relay Agent (RFC 6221) in the access node (analogous to the L2 Relay Agent for IPv4).

IPv6Internet

Dual-stackBNG

IPv4Internet

Dual-stackhome

network Dual-stackhome

gateway

PPPoE session

Access and aggregationnetwork

IPoE session

Dual-stack access andaggregation

IPv6Internet

Dual-stackBNG

IPv4Internet

Dual-stackhome

network Dual-stackhome

gateway


12

3.2 iPv4 continuityThe IPv4 continuity approach (Figure 11) aims to postpone IPv4 address exhaustion by overloading IPv4 address usage by means of network address translation (NAT) techniques IPv4 continuity is not the same as IPv6 migration, but it can help to reduce the urgency to migrate to IPv6..

Figure 11. IPv4 continuity approach using Large Scale NAT

There are a number of general approaches to postpone IPv4 address exhaustion:

• LargeScaleNAT(4-4-4)isthemostcommonapproachandrequiresthatanIPv4NATelement be deployed within the service provider network to perform network address port translation (NAPT), sharing a single IPv4 public address across a number of subscribers.

• Dual-StackLite(4-6-4)interconnectsIPv4clientsinthehomewithIPv4serversontheInternet over an IPv6 access network. It uses L2TP tunnels in the access network to multiplex multiple IPv4 subscribers through a single global IPv4 address.

• NAT64(4-6,6-4).ThissetofprotocoltranslationtechniquesconnectsIPv6clientsto IPv4 servers (and vice versa) over an IPv6 access network. Translating between IPv6 and IPv4 (for example, from an IPv6 host in the home network) is far easier than translating from IPv4 to IPv6, simply because of the longer IPv6 addresses. Communication must be initiated by the IPv6 client.

The next paragraphs will briefly discuss each of these methods.

3.2.1 Large Scale NAT (4-4-4)Large Scale NAT (LSN), also referred to as Carrier-Grade NAT (CGN), is a network-based network address port translation function that is highly available, can scale to millions of simultaneous sessions, tracks customer connections and enforces per subscriber session limits, and uses managed port assignments to support law-enforcement investigation against individual subscribers. NAPT allows the service provider to map multiple subscribers to a single IPv4 public address at the service provider’s Internet gateway.

Today

: early ad

opters tu

nnel

IPv6

dual stack cap

ability

Intro

duce IP

v4

overlo

adin

g (NA

T)2010 2011 2012 2013

IPv4 free addresses

IPv6 adoption


13

Figure 12. Large Scale NAT (LSN)

The biggest challenge with LSN is managing the address space between the customer gateway and LSN, as well as ensuring consistent Internet application behavior. There is a stated desire from service providers to support existing IPv4 customer gateways, and because of restrictions imposed by these legacy devices address space that does not overlap or collide with the carrier must be found.

Even though RFC 1918 provided a set of private IPv4 addresses, different gateway vendors have selected different ranges for use within the home network. (See IETF draft-shirasaki-isp-shared-addr for a discussion on these issues.) RFC 6598 defines a Shared Address Space (100.64.0.0/10) to be used by service providers to number the interfaces that connect LSN devices to a CPE, avoiding issues with overlapping and colliding address spaces within the carrier.

It is known that certain types of Internet applications cannot traverse network NAPT functions. This presents a challenge to service providers — methods and service definitions may be required to determine or ensure that a given end customer may be allocated a private IP address without impacting the customer’s Internet access needs.

The massive advantage of LSN is the relatively small cost required to implement it in the service provider network — hardware as well as Operations Support System (OSS) and IT systems — compared to other techniques.

3.2.2 Dual-Stack LiteDual-Stack Lite is a standard from the IETF Softwires Working Group (RFC 6333) that makes an argument for deploying IPv6-only access networks and bounding IPv4 to within the customer LAN and Internet (Figure 13). By employing DS-Lite one can tunnel IPv4 traffic over an IPv6 softwire. The use of a tunnel provides a convenient container that represents exactly one Residential Gateway, which only needs to act as a simple router that passes packets from the customer LAN to the Dual-Stack Lite interface without changing any addressing, and a softwire concentrator with NAT capability. Of most significance is the proposal to use a common IP address within the softwire for all customer gateways.

ServerLarge scaleNAT

IPv4Internet

Private IPv4

network

PrivateIPv4

accessnetwork

Private IPv4

network

Private IPv4

network

NAT44 NAT44

Stateful


14

Figure 13. Dual-Stack Lite

In Dual-Stack Lite (Figure 13), the IPv4 address assigned to the customer gateway end of the softwire is not unique to a single subscriber and the softwire concentrator is responsible for performing NAPT. The DS-Lite approach requires new customer gateways that implement a softwire client and requires the immediate and complete adoption of IPv6 in the access network. This requirement for new customer premises equipment (CPE) is seen as a major drawback to the softwire approach. It does not address legacy access such as dial-up or mobile handsets. One advantage with Dual-Stack Lite is the ability to provide IPv6 services to the home.

3.2.3 NAT64 (4-6, 6-4)The final set of transition methods advocates a form of IPv6-to-IPv4 network address translation, and in some cases vice versa. NAT64 enables IPv6 hosts to communicate with IPv4 servers.

Figure 14. NAT64 (4-6, 6-4)

ServerSoftwireconcentrator

Softwire/IPv4/port IPv4/port

IPv4Internet

IPv6 accessnetwork

Softwire

v4 in v6 tunnels

Route Tunnel

Softwire_1/10.0.0.1/TCP 10000 129.0.0.1/TCP 5000

Private IPv4

network

Private IPv4

network

Private IPv4

network

NAT

ServerLarge scaleNAT

DNS64

IPv4Internet

IPv6

network

IPv6access

network

IPv6

network

IPv6

network

Route NAT64

Stateful

DNS responsewww.attt.net A 1.2.3.4

DNS responsewww.attt.net AAAA Pref64::1.2.3.4

http://www.attt.net

http://www.attt.net


15

The NAT64 method requires a complementary Domain Network Server function (DNS64) to interoperate IPv6 clients with IPv4 hosts. Until the IPv6 transition is complete we cannot assume all hosts will natively support an IPv6 stack, so we must assume IPv4 within the home network to a translation device of some kind. We may expect IPv6 hosts to directly address IPv4 endpoints, whereas IPv4 hosts may need an additional IPv4-to-IPv6 translation. Translating between IPv6 and IPv4 is far easier than translating from IPv4 to IPv6, simply because of the longer IPv6 addresses. The NAT64 method requires literal modification to IP headers, and like Dual-Stack Lite, it requires a new device in the home network, as well as upgrading the access network to IPv6.

The NAT64 approach is also useful when connecting a large IPv6 network to a small IPv4 network.

NAT64 seems to be a potential intermediate step in the v4-to-v6 evolution for a service provider beyond an initial LSN solution, to address issues associated with the need to access IPv4 content when the access network is completely IPv6 capable.

3.2.4 Layer 2-Aware NATOf all NAT methods discussed so far, Large Scale NAT is best understood and has the lowest impact relatively. Table 1 provides a summary of the advantages and drawbacks of each of the techniques described. All approaches based on NAPT will have inherent issues related to stateful operation: A degree of policy management overhead is required to regulate aging and termination of established NAPT sessions.

table 1. comparison of nat techniques

Layer 2-Aware NAT is a hybrid NAT44 solution co-authored by Alcatel-Lucent (draft-miles-behave-l2nat) that attempts to mix the best attributes of these three approaches. It exploits the softwire concept found in the Dual-Stack Lite approach — that is, the ability for many subscribers to use the same IP address — and applies it to non-tunneled access techniques. It does this by integrating the NAT/NAPT component into the Broadband Network Gateway (BNG) and using a unique subscriber ID as a key for all NAPT sessions, instead of relying on a unique port number inside source IP address. This creates the additional benefit of allowing the creation of subscriber-specific NAT policies.

Large Scale NAT

No CPE Change

Problematic IPv4 address space between CPE and LSN

Application Servers can sit between subscriber and LSN

Minimal impact

NAT64+DNS64

Host change. MUST support v6 (+v6DNS)

Only supports IPv6 hosts. Legacy IPv4 hosts incl. XP not supported

All IPv4 traffic must be subject to NAPT

Tunnel obsfucates all IPv4 traffic

Customer Premise

Con

Traffic Bypass

Current BNG/BRAS

Dual Stack Lite

CPE change

IPv4 is tunneled over IPv6

All IPv4 traffic must be subject to NAPT

Tunnel obsfucates all IPv4 traffic


16

Figure 15. Layer 2-Aware NAT

Layer 2-Aware NAT relies on Layer 2 connectivity information as a means to identify individual subscriber packets instead of the source IPv4 address assigned to the subscriber. It allows the use of various Layer 2 delimiter types to identify a subscriber session, notably 802.1Q (VLAN id), 802.1AD (stacked VLAN or QinQ), MAC address, PPPoE or a L2TP id, making this approach not only IP protocol independent, but very flexible as well. See Figure 15 for the theory of operation.

It is expected that all clients will be assigned the same IPv4 address that is in turn translated (with the exception of the bridged model, where multiple hosts exist that belong to the same subscriber). This IP address would be configured as an IANA-reserved IP address to allow future implementations to know when they are behind an L2-Aware NAT. To support fixed broadband networks without change to existing NAT devices, the home network NAT may exist between the subscriber LAN and the L2-Aware NAT. In this example the home network LAN would typically be a private IPv4 address space and is first NATed by the home network device. The home network LAN address space would then be translated to a public IP address, typically a well-known IP address as described in draft-durand-dual-stack-lite.

figure 16. subscriber mapping in subscriber-aware nat

Each subscriber is mapped to a predefined range of port numbers (Figure 16), which is essential to meet requirements for lawful intercept. Limiting port ranges prevents individual subscriber applications such as peer-to-peer file exchange to hog NAT resources from other subscribers. Although the Layer 2-Aware NAT approach is subject to a number of limitations associated with historical NAT implementations on consumer CPE, the advantage of the approach is that it requires no CPE changes, while providing a workaround for the potential shared address space problem described in the NAT444 method. The Layer 2-Aware NAT supports both bridged and routed home gateway operation (note that the routed gateway is more efficient in IP address usage).

IPv4

IPoE

L2TP

PPPoE

NAT44NAT44 Layer 2 delim

ServerSoftwireconcentrator

IPv4Internet

Private IPv4

network

Private IPv4

network

Private IPv4

network

Subscriber Outside IP Port start Port stop Port mask

Sub-1 1.2.3.4 4,069 8,191 4096/12

Sub-2 1.2.3.4 8,192 12,287 8192/12

Sub-3 1.2.3.4 12,288 16,383 12288/12


17

3.3 service router support The Alcatel-Lucent 7750 SR supports dual-stack IPv4/IPv6 BNG functionality for residential services where the IPv4 and IPv6 services are tied to a single subscriber context with a common policy for Quality of Service (QoS), accounting and so on. In addition, all of the IPv4 continuity and IPv6 transition features described above (Large Scale NAT, Layer 2-Aware NAT, Dual-Stack, NAT64/DNS64) are supported. The Alcatel-Lucent 7750 SR allows NAT services to be deployed in redundant pairs ensuring that NAT is highly available. Port Control Protocol, an emerging IETF protocol that allows a home gateway to communicate with the service provider NAT to facilitate incoming connections, is also supported. Please refer to specific product release docu-mentation or your local sales representative as the primary source for IPv6 support data.

4. conclusion and recoMMendationsThe impending exhaustion of IPv4 addresses will have a non-trivial impact on the network infrastructure and services of most network providers. As a result they must prepare themselves appropriately ahead of time:

• DeterminethemostappropriateIPv6introductionstrategy.Thisencompassesaspectssuch as:

¬ How various legacy IPv4 services would interwork and/or migrate to IPv6 operation.

¬ The differences and ramifications of IPv6 operation, as compared to IPv4 operation, on the network, control plane and OSS levels. Some of the largest impacts can be on OSS and IT systems.

¬ IPv6 readiness of existing network and OSS infrastructure and potential hardware and software upgrades required to enable IPv6 operation.

¬ Cost options and timing of introducing dual-stack operation in client devices, access, aggregation, edge and core.

¬ IPv6 readiness as a planning parameter for future network expansions and upgrades.

¬ Educating operational workforce as well as customers about IPv6 and how you are preparing for its introduction.

• DeterminethemostsuitableIPv4continuitystrategytoassurethecontinuedoperationof IPv4-based services and subscribers as long as viable (that is, until they can be migrated to IPv6). Assess:

¬ The potential impact of introducing network-based NAT functionality on existing services and processes. Think for example about satisfying lawful intercept requirements, support for server-initiated IP communication, usage auditing and troubleshooting.

¬ The implications of IPv4 address overloading on the existing addressing plan. A NATed operation could impact network-wide address numbering and summarization.

¬ Required operational procedures to migrate from transparent IPv4 to a NATed operation.

¬ Performance, scalability, interoperability and management requirements.

www.alcatel-lucent.com alcatel, lucent, alcatel-lucent and the alcatel-lucent logo are trademarks of alcatel-lucent. all other trademarks are the property of their respective owners. the information presented is subject to change without notice. alcatel-lucent assumes no responsibility for inaccuracies contained herein. copyright © 2012 alcatel-lucent. all rights reserved. M2012042816 (June)

Even though IPv6 deployment is still limited in scale and may take several years to ramp up, the migration challenges require careful consideration and planning. Being prepared reduces the risk of costly mistakes later and allows the defining and executing of a non-disruptive transition that optimally fits business objectives. As the industry migrates to IPv6 it is likely that pitfalls will appear and lessons will need to be learned.

However, network providers cannot afford to simply “wait and see.” They must take action to implement an IPv4 continuity solution to address the short-term problem of IPv4 address exhaustion, or run the risk of impeding further growth of their business. At the same time, they must prepare for the long-term solution of enabling IPv6.

5. further reading• ForAlcatel-LucentIPproductinformation,seewww.alcatel-lucent.com/7750sr

• Forfurtherproductupdates,seewww.alcatel-lucent.com/ipdnews

• FormoreinformationonWorldIPv6LaunchDay,seewww.worldipv6launch.org

• ForIPv4addressallocationstatus,seewww.potaroo.net/tools/ipv4/index.html

6. abbreviationsbGP border Gateway Protocol

bnG broadband network Gateway

bRas broadband Remote access server

dHcP dynamic Host configuration Protocol

dns domain name system

icMP internet control Message Protocol

ioM input/output module

iPoe iP over ethernet

is-is/isis intermediate system to intermediate system

ldP label distribution protocol

lsn large scale nat

MPls Multi-Protocol label switching

nat network address translation

osPF open shortest Path First

PPP Point-to-Point Protocol

snMP simple network Management Protocol

http://www.alcatel-lucent.com/7750sr

http://www.alcatel-lucent.com/ipdnews

http://www.worldipv6launch.org

http://www.potaroo.net/tools/ipv4/index.html

http://www.alcatel-lucent.com

migrating networks and services to ipv6...migrating routed networks and services to ipv6 alcatel-...

Documents