ipv6 transition in fixed and mobile environments · 1.2 ipv6 transition: a multi-dimensional...

IPv6 TRANSITION IN FIXED AND MOBILE ENVIRONMENTS PLANNING A STRATEGY AND NAVIGATING THE ISSUES TECHNOLOGY WHITE PAPER

IPv6 migration has become an important topic for most network operators as

the projected increase of Internet Protocol (IP) — enabled applications, services

and consumer devices — is expected to exhaust the available public IPv4

address space in the coming years.

Although IPv6 has been around for some time, very few operators have been

adopting IPv6 in the residential wireless/wireline environment to date. As a result,

service providers require the tools to continue to grow the Internet adoption while

introducing IPv6. This white paper discusses different strategies to adopt IPv6

while continuing to support IPv4 services in residential broadband environments.

TABLE OF CONTENTS

1. The Internet today / 1

1.1 IPv4 address exhaust / 1

1.2 IPv6 transition: A multi-dimensional problem / 1

2. Implications of IPv6 support in carrier environments / 4

2.1 IPv6 in combination with PPPoX in Telco environments / 4

2.2 IPv6 in combination with IPoE in Telco environments / 6

2.3 IPv6 and DOCSIS 3.0 in cable environments / 7

2.4 IPv6 in mobile environments based on R7 or R8 3GPP / 8

3. IPv6 transition scenarios / 9

3.1 Scenario 1: IPv6 single stack / 9

3.2 IPv4/IPv6 dual-stack deployment options / 12

4. Carrier grade network address translation / 16

5. Summary / 18

6. References / 19

7. Abbreviations / 20

IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER

1

1. THE INTERNET TODAY1.1 IPv4 address exhaustThe IANA Public IPv4 address space was exhausted in January 2011. The highest levels of the Internet addressing authorities have been assigned the latest available public IPv4 address blocks. A number of factors, including the amount of unused Public IPv4 address space available and the amount of addresses required to sustain network service growth, will decide how soon this affects individual cases. Depending on these factors, service providers will eventually feel the impact on their service offerings.

Although IPv6 has been around for some time, very few service providers have actually introduced IPv6 in residential broadband networks. Studies indicate that less than 1% of the top 1000 websites support IPv6, and certain applications on the end devices do not support IPv6 connectivity at all.

This situation poses multiple issues to carriers such as:

• HowtocontinuegrowingthenetworkwhentherearenonewPublicIPv4 addresses available

• HowtoconnectlegacydevicesthatonlysupportIPv4

• HowtocontinueofferingservicetowebsitesontheInternetthatareIPv4only

• HowtosupportlegacyapplicationsthatdonotsupportIPv6connectivity

This white paper contains a detailed discussion of these issues and questions, and examines the design considerations for the different solutions available for both wireline and wireless environments.

1.2 IPv6 transition: A multi-dimensional problemWhile the IETF started work on IPv6 in 1990, there has been limited IPv6 adoption to date in residential environments. Although government institutions have been pushing service providers to adopt IPv6, so far there have not been strong business drivers for service providers to introduce IPv6. There were no new applications that required IPv6 while the cost of introducing IPv6 was perceived as high. All of this has resulted in service providers placing very little focus on introducing IPv6 in the residential broadband networkstodate.However,withthePublicIPv4addressexhaustionandtheveryrapidadoption of smartphones and M2M devices, the introduction of IPv6 is becoming urgent in order to sustain Internet growth and provide customers with proper service.


2

At the heart of the problem lies the fact that IPv6 is technically incompatible with IPv4 (see Figure 1) and has introduced several new concepts that change the present operation of broadband networks such as:

• IPv6addressing–unicast:Linklocaladdresses(LLA),globalunicastaddress(GUA)anduniquelocaladdress(ULA),multicastaddressing,depreciationofbroadcastaddressing

• IPv6headerchanges:NextHeader,etc.

• SLAAC:Statelessaddressauto-configurationforIPv6addresseswithoutconsuming aDHCPserver

• DefaultroutersupportusingRouteAdvertisements(RA)

• DHCPPD:DHCPprefixdelegationtoassignprefixestohomenetworks

• Neighbordiscovery(ND),MulticastListenerDiscovery(MLD),etc.supported throughICMP

Although there have been many valid reasons for these changes, these concepts have ramificationsonhowIPv6canbeofferedtoresidentialsubscribers.

Figure 1. IPv4 versus IPv6: Fundamental differences in packet format and control plane

IPv4

IPv6

0 4 8 16 20 32

0 4 12

While IPv6 carries many IPv4 functionalities forward, IPv6 is differentat the packet level, routing control plane and management plane

16 24 32

Version H. Len TOS

Identification Flags Fragment offset

Payload Length

Source Address(128 bit)

Destination Address(128 bit)

Next Header Hop Limit

Total Length

Header Checksum

Version Traffic Class Flow Label

ICMP

ICMP

IGMP

TTL Protocol

Destination Address (32 bit)

Source Address (32 bit)

Options

Packet format Control plane

IPv4

Address ResolutionProtocol (ARP)

Ethernet

IPv6

Ethernet

Neighbor discovery MLD


3

Figure 2. Introducing IPv6 is a multi-dimensional problem

Moreover,IPv6posesmulti-dimensionalissues(Figure2)withrequirementsoverwhichservice providers have no or little control. IPv6 has also implications on multiple elements, as follows:

• End-userdevices(hardwareandoperatingsystems)

¬PC:MACOS,Linux,WindowsVista/7havesolidIPv6supportwhileWindowsXPoperatesonlyindual-stackmodeandearlierWindowsversionshavenoIPv6support!

¬ IPv6 support on mobile handsets are emerging (iPhone, Android, Symbian, etc.)

¬VoIPOperatingSystemshavelittleIPv6supporttodate

¬IPTVOSsandSet-topboxeshavelittleIPv6supporttodate

¬CPE/RG:SupportforIPv6isemergingonxDSL/GPON/ETH/cableresidentialGW

• Accessnodes

¬DSL/GPON/ETH:MostvendorsstartsupportingcertainarchitecturesforIPv6

¬CMTS:MostvendorssupportIPv6

• Aggregation/Edge/Corenetworkelements

¬ Most of devices deployed have supported IPv6 for many years

• Fixed(BNG/BRAS),MGW(GGSN/PGW)Edgenode

¬BNG/BRAS:EmergingsupportforIPv6inPPPoX,IPoE(DHCPv6/DHCPv6PD),LNS

¬GGSN/PGW:WidespreadsupportforR8andR73GPPIPv6architectures

• Applications

¬End-userapplications:ProperOSsupport,API(s)forIPv6networkconnectivity

¬Websites:SupportforIPv6addressing/connectivity

¬ContentDeliveryNetworks:SupportforIPv6addressing/connectivity

The implications on some of these elements depend on the network design that is chosen for introducing IPv6. The following chapter highlights the implications of certain scenarios in Telco, cable and mobile environments, with focus on unicast IPv6 connectivity.

IPv6

Applications• End user applications• CDN• Web sites• etc.

Access nodes• DSLAM• GPON• CMTS• ETH switches• Wi-Fi hotspots• NB

BNG/BRAS• PPPoX• IPoE (DHCPv6/v6PD)

IP nodes• Edge• Aggregation• Core

CPE• DSL RG/CPE• GPON EG/CPE• ETH RG/CPE• Cable RG/CPE

End devices• PC OS• Mobile OS• VoIP OS• IPTV OS• etc.


4

2. IMPLICATIONS OF IPV6 SUPPORT IN CARRIER ENVIRONMENTS2.1 IPv6 in combination with PPPoX in Telco environmentsIPv6supportinTelcoenvironmentsusingPoint-to-PointProtocoloverEthernet(PPPoX)and/orATMisdefinedinTR-187oftheBroadbandForum.TheintroductionofIPv6usingPPPoX/L2TPhasnoimplicationsontheaccessandaggregationnetworkelements.PPPsessionauthenticationforIPv6isidenticaltoIPv4,usingPAP/CHAPoroption82.IPv4 and IPv6 authentication can be done in a single authentication phase to optimize RADIUStransactions.SincePPPoXIPv6CPisonlydefiningtheLinkLocalAddress,globalIPv6addressesaretypicallyassignedusingDHCPorSLAAC.TosupportanIPv6routedResidentialGateway(RG)usingthePTA/LNSmodel,thefollowingmechanismsarerequiredbetweentheRGandtheBNG/BRAStoensureIPv6connectivity:

• PPPoXIPv6CPforLink-LocalAddress(LLA)assignment.

• DHCPv6PrefixDelegation(IA-PD)isusedtoobtainaprefixforLANaddressassignment.

• StatelessDHCPv6isusedtoobtainadditionalconfigurationparameters.

• WhenthenumberedRGmodelisdeployed,statefulDHCPv6(IA-NA)isusedtoobtainanRGmanagementIPv6address;incaseofanunnumberedRGmodel,thisisnotrequired.

• RouteadvertisementsarerequiredtoassignthedefaultGWassignment.

Figure3showsaflowdiagramofhowtoestablishIPv6connectivityusingaroutedRGPPP model.

Figure 3. Telco IPv6 PPPoE-based access – routed home: DHCPv6 Prefix Delegation (PD)

FRAMED IP ADDRESS 10.3.0.10DELEGATED IPV6 PREFIX 2001:CAFE:CAFF:1::/64

Access Accept

Access Request

RADIUSBNG10.3.0.254

2001:CAFE:CAFF::/48

Routedgateway

IPv4/IPv6

Accounting stop

Accounting Request/Response

2

4

6

1

3

CHAP Challence/Response

Advertise DNS:2001:BAD:CAFE::138:203:145:134

Reply

IA Prefix :2001:BAD:CAFF::1

ICMPv6 RA without prefix-info

PADT

ICMPv6 Router Solicitation

Solicit IA-PD + DNS

Request

LCP Config Req/Ack

PADI/PADO/PADR/PADS

IPv6CP Config Req/Ack

IPCP Config Req/Ack10.3.0.10

Interface-id

02:00:00:ff:fe:00:00:03

10.3.0.254

CHAP authentication successful

DHCP6

Host hasnow a linklocal IPv6address

5


5

AnotheroptiontoprovideIPv6connectivitywithPPPoXisbyusingtheBridgedResidentialGateway(alsocalledthe“hostmodel”).Thefollowingmechanismsarerequiredbetweentheend-device(PCtypically)andtheBNG/BRAStoensureIPv6connectivity in this model:

• PPPoXIPv6CPforLLAassignment

• SLAACusedforthehosttoobtainaGlobal-UnicastIPv6address

• StatelessDHCPcanbeusedtoobtainadditionalconfigurationparameters

• RouteadvertisementsarerequiredtoassignthedefaultGWassignment

Figure4showsatypicalflowdiagramofhowIPv6connectivityisestablishedusingPPPoXinabridgedRGenvironment.

PPPoXforIPv6imposesnodifferentrequirementsonN:1VLANor1:1VLANarchitecturescompared to IPv4.

TosupportIPv6inaTelcoenvironment,usingPPPoXonlyimpactstheBNG/BRAS,CPEand/orRG,dependingonwhetherbridgedorroutedRGaredeployed.IfRADIUSisusedforauthentication,accountingandCoA(ChangeofAuthorization),somenewattributesalso need to be supported in the AAA environment.

Figure 4. Telco IPv6 PPPoE-based access – bridged home: Stateless Address AutoConfiguration (SLAAC)

FRAMED IP ADDRESS 10.4.0.6FRAMED IPV6 PREFIX 2001:CAFE:CEFE:1::/64

Access Accept

Access Request

RADIUSBridgedgateway

IPv4/IPv6

Accounting stop

Accounting Request/Response

2

4

7

6

1

3

CHAP Challence/Response

ICMPv6 Router Advertisement PREFIX 2001:CAFE:CEFE:1:: /64

LCP Echo-req / Echo-Rep (Keep alive)

PING PPoEv6 host

PADT

ICMPv6 Router Solicitation

LCP Config Req/Ack

PADI/PADO/PADR/PADS

IPv6CP Config Req/Ack

IPCP Config Req/Ack10.4.0.6

Interface-id

d4:ba:a4:b2:9c:c8:b1:5f

10.4.0.254

CHAP authentication successful

Host hasnow a linklocal IPv6address

5

BNG10.4.0.254

2001:CAFE:CAFF::/48

IPCP negotiates IPv4 andoptional DNSv4 addresses

IPv6CP negotiates only interface-id


6

2.2 IPv6 in combination with IPoE in Telco environmentsBroadbandForumspecificationTR-177definessupportforIPv6inTelcoenvironmentsbased on IPoE (IP over Ethernet). The implications for introducing IPv6 IPoE mainly dependontheVLANmodelused(1:1orN:1),andtheoperationalmodelofthehomegateway (bridged or routed).

Ina1:1VLANmodel,thehomeidentitycanbederivedfromtheVLANID.Assuch,itispossibletodeployIPv6withoutanychangestotheaccess/aggregationnetworkiftheexistingdevicessupportthebasicIPv6forwardingmechanism.WhenanN:1VLANmodelisdeployed,theAccessNodehastosupportataminimumaLightweightDHCPRelayAgent(LDRA),asdefinedinIETFdraft-ietf-dhc-dhcpv6-ldra-03,toensurethattheBNG/BRAScandeterminefromwhichsubscribertheDHCPrequestwasreceived.Itisfurtheradvisedthatanti-spoofingontheaccessnodebesupported.

TosupportIPv6fortheRoutedResidentialGatewaymodelusingtheDHCPv6,thefollowingmechanismsarerequiredbetweentheRGandtheBNG/BRAStoensureIPv6connectivity:

• DHCPv6prefixdelegation(IA-PD):Auniqueper-subscriberIPv6prefixisdelegatedtotheRGforusewithinthehomenetwork

• DHCPv6WANaddressassignmenttotheRGifanumberedRGmodelisused

• AdefaultrouteisinstalledonthereceiptofavalidRouterAdvertisementfromtheBNGwithanext-hopoftheBNGlink-localaddress

Figure5depictsatypicalflowdiagramoftheIPv6connectivitysetupusingaroutedRGIPoE model.

Figure 5. IPv6 for IPoE using xDSL/FTTx Access – Routed Home: DHCPv6 Prefix Delegation (PD)

Access Accept(Delegated-IPv6-Pfx, Alc-IPv6-Address)

Access Request

RADIUSDual stackrouted gateway

Dual stackISP network

Dual stackhome network Dual stack

access and aggregation

IPoE session

RADIUS – Acc. Resp.

RADIUS – Acc. Req. (start)DHCPv6 – Request (IA_NA, IA_PD)

ICMP6 – MLD report (join)

ICMPv6 – Router Advertisement

DHCPv6 – Advertise (IA_NA, IA_PD)

DHCPv6 – Solicit (IA_NA, IA_PD)

ICMP6 – Neighbor Solicitation (DAD)


DHCPv6 – Reply (IA_NA=<wan address>IA_PD=<LAN prefix>)

Dual stackBNG

DHCPv6 host joins the solicited-node multicast address

Note: Only IPv6 session flow is shown.IPv4 has its dedicated IPoE session.

BNG sends a Router Advertisement. This willresult in the DHCPv6 client to install a

default route with next-hop the BNG linklocal interface address

The routed gateway allocatesthe addresses in the home

network (SLAAC or DHCPv6)This is not shown here.

RADIUSAAA

Duplicate Address Detectioncheck performed by

DHCPv6 client

DHCPv6 session setup


7

TheimpactofIPv6supportforIPoEinaBridgedResidentialGatewaymodeldependsonwhetherDHCPorSLAACisusedtotheenddevice.WhendeployingDHCP,themaindifferencefromtheRoutedRGIPoEmodelcomesfromthefactthatthereisnoDHCPPDaddressrequiredandonlyanIAaddressisassignedtothehost.Caremustbetakentoensure communication between IPv6 devices in the home remains local and is not sent viatheBNG.

Statelessaddressauto-configuration(SLAAC)posesawholenewsetofissues.InanN:1VLANmodel,theBNGcannotdeterminefromwhichsubscriberaRouterSolicitation(RS)messageisoriginatingandhencetheBNGisunabletodecidewhichPrefixtosendbackintheRouteAdvertisement(RA)messages.Toovercomethisissue,theAccessNodeshouldaddaLineIdentificationoptionintheRSmessages,inthesamewayasitisdoneforDHCPv6.TheBNGneedstoensurethattheRA,asaresponsetoanRS,issentsuchthattheAccessNodecanforwardtheRAtothepropersubscriber.

Furthermore,duetothesplit-horizonforwardingbehaviorofanaccessnetwork,itmustbe ensured that Duplicate Address Detection (DAD) is still functioning properly, since DADmessagesarenotsenttoneighboringsubscribers.TheBNGmustassistinensuringDAD is still functioning properly by supporting a DAD proxy function. Since these issues are still being discussed in IETF, they may arise in most current implementations of AccessNodesandBNG(s).

2.3 IPv6 and DOCSIS 3.0 in cable environmentsInacableenvironment,IPv6connectivityisdefinedinDOCSIS3.0.ThemainelementsinvolvedintheIPv6connectivityestablishmentaretheCPE/RG,theCableModemTerminationSystem(CMTS)andtheDHCPserver.TheCMTSactsastheEdgeRouterandasaDHCPrelaywithacentralDHCPserver.

To provide IPv6 connectivity in the cable network, the following mechanisms are requiredbetweentheRG,theCMTSandtheDHCPservertoensureIPv6connectivity:

• DHCPv6prefixdelegation(IA-PD):auniqueper-subscriberIPv6prefixisdelegated totheRGforusewithinthehomenetwork

• DHCPv6WANaddressassignmenttotheRGifanumberedRGmodelisusedbased onSLAACorDHCPv6

• AdefaultrouteisinstalledonthereceiptofavalidRouterAdvertisementfromtheCMTSwithanext-hopoftheCMTSlink-localaddress

The implications of introducing IPv6 connectivity in a cable environment are mainly focused aroundtheResidentialGateway,CMTSandtheDHCPserver.DOCSISspecifiesabridgedIPv6solutioninthehome,whichusesSLAACand/orDHCPforIPv6addressassignment.


8

Figure6showsatypicalflowdiagramofhowIPv6connectivityisestablishedusingaroutedRGIPoEmodel.

2.4 IPv6 in mobile environments based on R7 or R8 3GPPIPv6connectivityinamobileenvironmentisdefinedin3GPPR7/R8/etc.ThemainelementsinvolvedintheIPv6connectivityestablishmentaretheUserEquipment(UE)andtheGGSN/PGW.ToprovideIPv6connectivityinaMobilenetwork,thefollowingmechanismsarerequiredbetweentheUEandtheGatewayGPRSSupportNode(GGSN)/PDNGateway(PGW):

• SLAACroutersolicitation(RS)/routeradvertisement(RA)using/64addressesareusedto provide IPv6 connectivity

• DNSinformationissuppliedintheprotocolconfigurationoptionsoftheCreatePDPResponse

• AdefaultrouteisinstalledonthereceiptofavalidRouterAdvertisementfromtheGGSN/PGWwithanext-hopoftheGGSN/PGWlink-localaddress

Figure 7. IPv6 in mobile environment

Figure 6. IPv6 for IPoE using CMTS access – routed home: DHCPv6 Prefix Delegation (PD)


DHCP serverDual stackrouted gateway

Dual stackISP network

Dual stackhome network

HFC

IPoE session

DHCPv6 – Request (IA_NA, IA_PD) DHCPv6 – Request (IA_NA, IA_PD)


ICMPv6 – Router Advertisement

DHCPv6 – Advertise (IA_NA, IA_PD) DHCPv6 – Advertise (IA_NA, IA_PD)


ICMP6 – Neighbor Solicitation (DAD)


DHCPv6 – Reply (IA_NA=<wan address>,IA_PD=<LAN prefix>)

DHCPv6 – Reply (IA_NA=<wan address>,IA_PD=<LAN prefix>)

CMTS

DHCP Relay

The routed gateway allocatesthe addresses in the home

network (SLAAC or DHCPv6)This is not shown here.

CMTS sends a RouterAdvertisement. This will result

in the DHCP6v client toinstall a default route

with next-hop the CMTS linklocal interface address

DHCPv6 host joins the solicited-node multicast address

Duplicate Address Detectioncheck performed by

DHCPv6 client

Note: Only IPv6 session flow is shown.IPv4 has its dedicated IPoE session.

DHCPv6 session setup

Base station

VPRN

Mobile coreMobile backhaul

Dual stackIPv4/IPv6 IPoE

3GRNC/BSC/SGSN

LTE/4GPGW/SGWMME/AGW CG-NAT

Dual stackIPv4/IPv6 IPoE


9

Figure7showsaflowdiagramofhowIPv6connectivityisestablishedinamobileenvi-ronment.FromR8onwards,3GPPhasdefinedamechanismusingPDPtype(IPv4IPv6)toassignbothanIPv4addressandanIPv6addressusingasinglePDP/BearerContext.Withthismechanism,noadditionalPDPContexthastobecreated.However,priortoR8aPDPContextwasrequiredperPDNtype(IPv4andIPv6),whichresultsinreducedscalabilityoftheGGSN.

3. IPV6 TRANSITION SCENARIOSThere are different choices to be made to deal with the IPv4 exhaustion and IPv6 intro-duction.However,forbestresults,itisimportanttounderstandthevariousimplicationsof providing native IPv6 connectivity in residential broadband environments for Telcos, cable and mobile service providers.

There are three main scenarios for dealing with the issues:

• Scenario 1: Provide IPv6 single stack to end customer and provide NAT64 when connectivityisrequiredfromaIPv6hosttoaIPv4host/website

• Scenario 2:Providedual-stackIPv4andIPv6toendcustomers.Therearemultipleoptions when choosing this strategy.

¬Scenario2A:LeveragetheIPv4installedbaseandprovideIPv6connectivity,usingtunnelingIPv6oIPv4using6RD[18].IPv4connectivityisprovidednatively.

¬Scenario2B:ProvidenativeIPv4andIPv6connectivitywithoutanytunneling.

¬Scenario2C:ProvidebothnativeIPv6connectivityandIPv4connectivityusingDS-LitebytunnelingIPv4oIPv6.

• Scenario 3:AvoidintroducingIPv6andkeepIPv4singlestackbyusingCarrier-gradeNetworkAddressTranslationorCG-NAT(NAT444).Althoughthismightbeseentobethe least costly option, there are implications that NAT has on end customer services. The implications are explained in chapter 4.

Thefollowingsub-sectionsprovidemoredetailsonthesescenariosandtheimplicationsoftheirintroductions.NotethattheIT/DHCP/RADIUSsystemsneedtosupporttheIPv6allocation/managementontopofprovidingIPv6connectivity.

3.1 Scenario 1: IPv6 single stackIn this scenario, only native IPv6 connectivity is provided to the end customer (using one ofthemechanismsdescribedinsection2).End-to-endIPv6connectivityisprovidednativelybetweenend-hosts/websites.ToprovidecommunicationfromIPv6toanIPv4host/website,aNAT64/DNS64serviceneedstobedeployedinthenetwork.

Figure8andFigure9showscenariosforestablishingbasicconnectivityinanIPv6singlestack deployment in a wireline, respectively mobile environment.


10

Figure 8. Scenario 1: IPv6-only operation in wireline deployments

Figure 9. Scenario 1: IPv6-only operation in mobile deployments

6PE or 6VPEIPv4-only supporting

IGP/MPLS

Aggregation/edge/coreAccessHome

PPP, DHCPor IPoE

RG

IPv6: SLAAC/DHCP

IPv4 use caseNAT64

IPv4

DNS64

IPv6 use case

IPv6IPv6IPv6IPv6

IPv6IPv6IPv6

Private IPv4 address Public IPv4 address IPv6 address

IPIP

6PE for IPv6 or 6VPE+ IPv4 to support

IGP/MPLS


GTP/PDPUE

IPv6: SLAAC/DHCP

IPv4 use caseNAT64

IPv4

DNS64

IPv6 use case

IPv6IPv6IPv6IPv6

IPv6IPv6IPv6


IPMGW


11

TheoperationofDNS64/NAT64isasfollows:

1)AnIPv6hostrequestsconnectivityusingDNStoahost/web-site.

2) The DNS query is sent to the DNS64 server and resolves the request via the Auth. DNS server.

3)WhenanArecordisreturned,theDNS64synthesizesthisintoaAAAArecordandprovidesaIPv6addresstotheenddeviceusingawell-knownIPv6prefixthatembedsthe IPv4 address.

4)WhentheIPv6end-hostgetsthisDNSresponse,itsenttheIPv6packettothedestination IPv6 address received in the DNS response.

5)Sincethiswell-knownprefixisallocated/advertizedbytheNAT64element,thepacketarrives in the NAT64 device.

6) The NAT64 device translates the IPv6 packet into an IPv4 packet and NAT(s) the packet such that a public IPv4 source IP address is assigned. The NAT64 device forwardsthenativeIPv4packettotheendsystem(host/web-site)

Moredetailsaredescribedindraft-ietf-behave-v6v4-xlate-statefulandFigure10showsthecallflowofthecommunicationofDNS64/NAT64.

Figure 10. NAT64/DNS64 operation

Dest.: 203.0.113.1:80Src.: 192.0.2.45.6853

AllocateNAT-binding

IPv4

IPv4

IPv6

IPv6

IPv4 serverNAT64Pref64=2001:db8:8000::/64

Auth. DNSDNS64IPv6 Host

DNS Query

DNS Response

DNS Query

AAAA example.com

DNS Query

AAA example.com

A example.com

A 203.0.113.1

NXDOMAIN

Dest.: [2001:db8:8000::203.0.113.1]:80Src.: [2001:db8::xyz]:abc

DNS Response

AAAA2001:db8:8000::203.0.113.1

DNS Response


12

Although this scenario looks simple, some consideration needs to be taken into account:

• ThenetworkneedstobeupgradedtosupportnativeIPv6intheRG/CPEandaccess,aggregation, edge, core and peering routers.

• ThereisnoneedtoprovideanIPv4addresstotheenddevices,whichcanimprovescalability.

• ANAT64andDNS64serviceneedstobeembeddedintothenetwork.

• WindowsXP,whichrepresentsthemajorityofOSdeploymentsonPC(s)todate, does not natively operate in this model since it uses DNSv4 to get IPv6 AAAA records. Due to the fact that there is no IPv4 connectivity, this causes a big issue.

• SinceenddevicesaremainlyusingSLAACandsincesupplyingDNSinSLAAC(RFC5006)wasanafterthought,someOSsmightnotsupportDNSusingIPv6.Inmobileenvironments,thisisnotanissuesinceDNSisprovidedusingPCOintheCreate-PDP-Context-responsemessage.

• RecentstudieshaveshownthatnotallapplicationsaredesignedtodatetooperateinanIPv6-onlyenvironment.(Seedraft-arkko-ipv6-only-experience-02formoredetails.)

• WhensubscribersareusingstaticIPaddressingforcommunicationwithoutusingDNS,theyneedtobesuppliedwiththesyntheticprefixfortheNAT64device.

SincemobileUEOShavemoreandmoreIPv6supportandsincesomemobileoperatorshavemorecontrolontheOSusedintheirenvironment,webelievethatadoptingthismodelinamobileenvironmentisacceptableunderthesecircumstances.Forfixedoperators,thenon-nativesupportofWindowsXPisamajorhurdleforadoptingthismodelintheshort term.

ThecostforthismodelincludesCAPEX/OPEXtoexchange/upgradeRG/UE, CAPEX/OPEXoftheDNS64/NAT64GW,CAPEX/OPEXofintroducingIPv6in access,aggregation,edgeandcore,aswellasOPEXontheOSS.

3.2 IPv4/IPv6 dual-stack deployment options3.2.1 Scenario 2A: Tunneling IPv6 over IPv4 using 6RDInthisscenario,theenddevicesaresuppliedwithdual-stackaddressing.BothanIPv4andanIPv6addressareprovidedtothecustomerLAN.IPv4connectivityinthismodelis provided as usual, i.e., using private or public IPv4 addressing. IPv6 connectivity is providedusing6to4tunneling(RFC3056),wherethestandard6to4prefix2002::/16ischangedbyanIPv6prefixthatbelongstotheISP-assignedaddressspace.TheIPv6prefixallocatedtotheendcustomerisderivedfromtheIPv4addressassignedtotheCPE/RG. Thev4suffix-length,v6prefix-length,6RDBorderRelayIPv4(Anycast)Addressand6RDSPPrefixareprovidedtotheCPEusingDHCP.Todeploy6RD,a6RDCE(CPE/RG)needstobedeployedinconjunctionwitha6RDBorderRelay(BR)whichprovides6to4tunneling.MoredetailscanbefoundinRFC5969.


13

Figure 11. Scenario 2A: Dual stack and 6RD (wireline)

The following implications should be considered when selecting this model:

• TheRG/CPEneedstobeupgradedtosupport6RD,anda6RDBRfunctionneeds to be added into the network

• ThereisnoneedtoupgradetheAccess/Aggregation/BNG/BRAS

• IPv6trafficisalwaystunneledbetween6RDCEand6RDGW;ifnativeIPv6support is required, a second upgrade is required using one of the other scenarios described in this white paper

• PropersupportforMTUsizeissuesthatmightbeintroducedduetothe6to4tunneling

• MobileUEOShavenotbeenadoptingthisstrategyduetothetunnelingimplications,which means that this scenario is not applicable in a mobile environment

• DifferentiatingpersubscriberservicesforbothIPv4andIPv6arecumbersometoimplement

This scenario is positioned in wireline deployments for rapid IPv6 introduction to support Internet access in cases where the access network is incapable of supporting IPv6. Native IPv6 is not supported in this scenario, thus potentially requiring a second upgrade. The costs aredeterminedbyCAPEX/OPEXtochange/upgradeRGtosupport6RD,CAPEX/OPEXofthe6RDBRandOPEXontheOSS.

3.2.2 Scenario 2B: Dual stack throughout the networkThis scenario is supporting both native IPv4 and native IPv6 to the end customer. IPv4 issupportedusingthecurrentmodeofoperationwithoptionaldeploymentofCG-NAT,depending on the available Public IPv4 address space. IPv6 is provided using one of the methodsdescribedinchapter2.Figure12andFigure13showmoredetailsonIPv4andIPv6 connectivity.

BGP/IGP shortcuts orIP-VPN + IPv4 to

support IGP/MPLS

Public IPv4 use case

Aggregation/edge/core

Option 1

Optional

AccessHome

PPP, DHCPor IPoE

IPRG

6RD 6RD

IP

IPv4: DHCP/NATIPv6: SLAAC/DHCP

NAT

IPv4IPv4 IPv4 IPv4

Private IPv4 use caseNAT CG-NAT

IPv4IPv4 IPv4 IPv4

IPv6 use case

Option 2

IPv6IPv6IPv4IPv6IPv6 IPv4

6rd: 6to4 tunnel



14

Figure 12. Scenario 2B: Dual stack throughout in wireline deployments

Figure 13. Scenario 2B: Dual stack throughout in mobile deployments

BGP/IGP shortcuts forIPv4 + 6PE for IPv6 or

dual stack IP-VPN + IPv4to support IGP/MPLS



Option 1

Optional

AccessHome

PPP, DHCPor IPoE

RG


NAT

IPv4IPv4 IPv4 IPv4


IPv4IPv4 IPv4 IPv4

IPv6 use caseOption 2

IPv6IPv6IPv6IPv6


IPIP

BGP/IGP shortcuts forIPv4 + 6PE for IPv6 or

dual stack IP-VPN + IPv4to support IGP/MPLS



Option 1

Optional

AccessHome

GTP/PDPUE


NAT

IPv4IPv4 IPv4 IPv4


IPv4IPv4 IPv4 IPv4

IPv6 use case

Option 2

IPv6IPv6IPv6IPv6


IPMGW


15


• TheRG/CPE,Access,Aggregation,BNG/BRASand/orGGSN/PGWneedtobeupgraded to support native IPv6.

• TosupportbothIPv4andIPv6infixednetworksandmobileenvironments(priortoR8),therecanbeimplicationsonthescalabilityontheCMTS,BRAS/BNGandGGSN/PGW.Additional elements need to be deployed potentially to scale the network properly.

• IPv4andIPv6services(likeInternet,Voice,IPTV,etc.)canbedeployedindependentlyleveraging IPv4 or IPv6 without tunneling.

• CG-NATisoptionalifdependingontheavailablepublicIPv4addressesareavailable.

• AbilitytoofferdifferentiatedservicesforbothIPv4andIPv6isstraightforward.

Scenario2Bispositionedinwirelineandwirelessnetworkdeployments.Serviceproviderscanleveragesynergiesbetweenfixedandmobileiftheysupplybothservices.ThecostisdeterminedbytheCAPEX/OPEXtochange/upgradetheRG/UE,theCAPEX/OPEXoftheCGNAT,andtheCAPEX/OPEXofintroducingIPv6inAccess,Aggregation,EdgeandCoreandOPEXontheOSS.

3.2.3 Scenario 2C: Partial dual-stack deployment in combination with IPv6-onlyScenario2CprovidesnativeIPv6connectivitywhileIPv4connectivityisprovidedusingIPv4inIPv6tunneling.Inthismodel,theB4element(BasicBroadbandBridging)isintroducedintheCPE/RG,whichprovidesIPv4inIPv6tunnelingcapabilities.

Figure 14. Wireline Scenario 2C: Partial dual stack in combination with IPv6-only

DS lite tunnel

6PE or 6VPEIPV4-only supporting

IGP/MPLS


PPP, DHCPor IPoE

AFTRB4 IP


IPv4 use caseNAT

IPv4 IPv4

IPv6 use case

IPv6IPv6IPv6IPv6

IPv4IPv6IPv4IPv6



16

AnAddressFamilyTransitionRouter(AFTR)isintroducedintheaggregationnetworktoencapsulate/de-encapsulateIPv4trafficin/fromIPv6,andprovidesCG-NATusingtheIPv6sourceprefixasthesubscriberkey.TheCPE/RGissuppliedusingDHCPv6withtheAFTRGWaddressandusesapredefinedprivateIPv4prefix.Moredetailsaredescribedindraft-ietf-softwire-dual-stack-lite-06.Figure14showsmoredetailsontheIPv4/IPv6connectivity using this transition scenario.


• TheRG/CPE,Access,Aggregation,BNG/BRASand/orGGSN/PGWneedtobeupgraded or changed to support native IPv6.

• TheRG/CPEneedtobeupgradedtosupporttheB4capabilityandanAFTRelementneeds to be introduced in the network.

• SinceIPv4servicesaretunneled,upgradingVoice/Video/MulticastservicestoIPv6should be considered. In essence, there is a trade off between the implications of the tunneling versus the cost of upgrading services to IPv6.

• MobileUEOperatingSystemshavenotbeenadoptingthisstrategyduetothetunnelingimplications, which means that this scenario is not applicable in a mobile environment.

• DifferentiatingpersubscriberservicesforbothIPv4andIPv6arecumbersometoimplement.

Scenario2CismainlypositionedinwirelinedeploymentsthatneedtotransitionquicklytoanativeIPv6-onlyenvironmentinaccessandaggregation.ImplementationcostsincludesCAPEX/OPEXtoexchange/upgradeRG/UEtosupportB4/IPv6,CAPEX/OPEX oftheAFTR,CAPEX/OPEXofintroducingIPv6inAccess,Aggregation,EdgeandCoreandOPEXontheOSS.

4. CARRIER GRADE NETWORK ADDRESS TRANSLATIONBesidesapproachestoprovidingIPv6andIPv4connectivity,thereareotherconsiderationssuchasCG-NATanditsvariousimplicationsthatdeterminetheIPv6transitionstrategy.ThefollowingconsiderationsneedtobetakenintoaccountforCG-NAT:

• Networkconnectivitymustbeinitiatedfromtheinsidetowardstheoutside,unlessstaticport-forwardingrulesareconfiguredontheCG-NATdevice.NotethatUniversalPlugandPlay(UPnP)andNATPortMappingProtocol(NAT-PMP)willnolongerworkwithCG-NAT,andpotentiallyaportalneedstobedeployedtoenablecustomerstousepinholesintheCG-NATservice.TheIETFisattemptingtoaddressthisissueinthePortControlProtocol(PCP)WorkingGroupforwhichimplementationsarestartingtoappear.

• TheprivateIPaddressspacehasalimitedsizewhichmustbefactoredinwhenmakingnetworkdesigndecisions.DS-LiteisaddressingthisissuebyperformingNATonthebasisofthesourceIPv6address.L2-awareNATisasimilarsolutionthatperformsNATonthebasisofPPP,VLAN-idandMACaddressesanddescribedindraft-miles-behave-l2nat.


17

• ApplicationLevelGateways(ALGs)mustbesupportedtoallowcertainapplications(FTP/RTSP/SIP/etc.)tooperateacrossCG-NAT.Inparallel,SessionTraversalUtilitiesforNAT(STUN),InteractiveConnectivityEstablishment(ICE)andTraversalUsingRelaysaroundNAT(TURN)canoptionallybedeployedtoassistcertainapplicationandminimizeALGrequirements.

• TotracktheallocationsofhoststoPublicIPaddressesandports,itisbesttolettheCG-NATallocateportblockstoreduceloggingandstorageoftheloggingfiles.Asapercentageofcustomersareoff-lineatanytime,1:1CG-NATcanbedeployedtorelaxdata retention requirements and avoid port overloading issues.

• WhenN:1CG-NATstrategyisselectedusingportblockallocations,thesolutionshouldensurethatsufficientportsareallocatedtoagivenhost.Dividingtheavailableportsby a factor of 10 increases the available Public addressing space by a factor of 10 and prevents additional logging and multiple port block allocations. A typical Internet user consumes close to 100 ports, whereas heavy users consume around 500 ports and more at peak times.

• LawfulIntercept(LI)shouldbeintegratedintheCG-NATdevicetoensurepublicIPcommunicationispresentedtotheLImediationdevice.

• WhenCG-NATisdeployedinotherdevicesthanthesubscriberEdge(e.g.,GGSN/PGW,BNG/BRASorDHCPServer),IPaddressesareallocatedindependentlyfromNATPublicIP/portmappings.ThiscanresultinallocatingthesameinsideIPaddresstoadifferenthost, while the NAT mapping has not timed out. Either an implicit timeout mechanism or an explicit mechanism should be installed to take this into account.

• SubscriberDeepPacketInspection(DPI)enforcementshouldbedeployedinfrontoftheNATfunctionunlessthesubscriberDPIenforcementcanoperatewithIPaddress/portblockallocationsprovidedbytheCG-NATdevice.IncaseDS-Lite/6RDisused,deployingDPIinfrontoftheNATmightbeproblematicsinceDS-Lite/6RDistunnelingtheIPv4/IPv6packetinIPv6/IPv4.WhenusingNAT64/NAT444,theDPIsystemshould be upgraded to support IPv6 signatures and heuristics.

• CertainInternetservices,whichoperatebasedonIPonlyinformation,willnolongerbe able to identify a host based on IP address and need to be enhanced with the port information allocated to a certain host.

• Takeintoaccountthethroughput,NATbindingtranslationrates,andbindingscalabilitysupportofthedeployedCG-NATdevice.

• Selectasolutionthatcanbedeployedinbothacentralizedordistributedmanner,since NAT requirements might change over time.

Many service providers that have offered public IP services have to face these challenges whileminimizingtheimpacttotheircustomers.Hence,providingnativeIPv6willbeimportant to satisfy a customer base as it avoids the various issues that are related to theuseofCG-NAT.


18

5. SUMMARYTheimpendingexhaustionofpublicIPv4addresseshasanon-trivialimpactonthenetwork infrastructure and services of all network providers. As a result, the network providers must prepare themselves appropriately ahead of time by taking into account the following:

• DeterminethemostappropriateIPv6introductionstrategy.Thisencompassesaspectssuch as:

¬HowvariouslegacyIPv4serviceswouldinterworkand/ormigratetoIPv6operation

¬ThedifferencesandramificationsofIPv6operation,ascomparedtoIPv4operation,onthenetwork,controlplaneandOSSlevel(notingthatsomeofthelargestimpactscanbeonOSSandITsystems

¬IPv6readinessofexistingnetworkandOSSinfrastructureandpotentialhardwareand software upgrades required to enable IPv6 operation

¬Costoptionsandtimingofintroducingdual-stackoperationinclientdevices,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 the steps being taken to prepare for its introduction

• DeterminethemostsuitableIPv4continuitystrategytoassurethecontinuedoperationofIPv4-basedlegacyservices,devicesandapplicationsuntiltheycanbemigratedoverto IPv6, including:

¬Thepotentialimpactofintroducingnetwork-basedCG-NATfunctionalityonexisting services and processes, for example, think about satisfying lawful intercept requirements,supportforserver-initiatedIPcommunication,usageauditingandtroubleshooting

¬ The implications of IPv4 address overloading on the existing addressing plan, notingthataNATedoperationcouldimpactnetwork-wideaddressnumbering and summarization)

¬RequiredoperationalprocedurestomigratefromtransparentIPv4toaNATedoperation

¬ Performance, scalability, interoperability and management requirements

As there are many options in deploying IPv6 and dealing with IPv4 exhaustion, Alcatel-Lucentiscommittedtohelpnetworkserviceprovidersmaketherightchoicesfortheirnetworks.Alcatel-Lucentsolutionsfocusontechnical,businessandservicechallengestosolvethismulti-dimensionaltransitionissueinthemostcost-effectiveway.

Alcatel-LucentproductshavebeenvalidatedinvariousdeploymentsandthroughindependentvalidationofthesestrategiesbyISOCORE,whichshowsdetailsonhowwellour solution supports and scales in IPv6 transition scenarios. For more details, contact Alcatel-Lucentsalessupport.


19

6. REFERENCESREFERENCE DOCUMENT NAME

RFC 1918 [1] RFC 1918 Address Allocation for Private Internets

RFC4787 [2] Network Address Translation (NAT) Behavioral Requirements for Unicast UDP

RFC5382 [3] NAT Behavioral Requirements for TCP

RFC5508 [4] NAT Behavioral Requirements for ICMP

RFC 3489 – RFC 5389 [5] Session Traversal Utilities for NAT (STUN)

RFC 5766 [6] Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)

RFC 5245 [7] Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

draft-cheshire-nat-pmp-03.txt [8] NAT Port Mapping Protocol (NAT-PMP)

draft-ietf-tsvwg-port-randomization-09 [9]

Transport Protocol Port Randomization Recommendations

draft-ietf-softwire-dual-stack-lite-06 [10]

Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion

RFC4213 [11] Basic Transition Mechanisms for IPv6 Hosts and Routers

draft-ietf-softwire-ds-lite-tunnel-option-07 [12]

Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite

draft-ietf-dhc-dhcpv6-ldra-03 [13] Lightweight DHCPv6 Relay Agent

WT146 [14] Internet Protocol (IP) Sessions

TR177 [15] IPv6 in the context of TR-101

TR187 [16] IPv6 for PPP broadband access

RFC 3056 [17] 6to4 tunneling

RFC 5969 [18] IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

draft-ietf-softwire-dual-stack-lite-06 [19]

Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion

draft-ietf-behave-v6v4-xlate-stateful-12 [20]

Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers

RFC 4862 [21] IPv6 Stateless Address Auto-configuration

RFC 3315 [22] Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

RFC 3633 [23] IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6

RFC 5072 [24] IP Version 6 over PPP

RFC 2516 [25] A Method for Transmitting PPP Over Ethernet (PPPoE)

RFC 3162 [26] RADIUS and IPv6

RFC4818 [27] RADIUS Delegated-IPv6-Prefix Attribute

draft-ietf-radext-ipv6-access-02 [28]

RADIUS attributes for IPv6 Access Networks

RFC3363 [29] Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)

RFC 4294 [30] IPv6 Node Requirements

RFC 3736 [31] Stateless Dynamic Host Configuration Protocol (DHCP)

draft-miles-behave-l2nat-00 [32] Layer 2-Aware NAT

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. M2012042755 (April)

7. ABBREVIATIONS6PE IPv6 Provider Edge over MPLS

6RD IPv6 rapid deployment

6RD CE CPE/RG supporting 6RD

6RD BR 6RD Border Relay

6VPE IPv6 provider Edge over MPLS VPN

AFTR DS-Lite Address Family Transition

Router element

AGW Application Gateway

ALG Application level gateway

B4 DS-Lite Basic Bridging Broadband

element

BNG Broadband Network Gateway

BGP Border Gateway Protocol

BRAS Broadband Remote Access Server

CAPEX Capital expenses

CE Customer Edge router

CG-NAT Carrier Grade Network address

translation

CPE Customer Premises Equipment

DHCP Dynamic Host configuration protocol

DNS Domain Name system

DPI Deep Packet inspection

DS Dual Stack

DS-Lite Dial Stack Lite protocol

EBGP Exterior Border Gateway Protocol

GGSN Gateway GPRS Support Node

GRE Generic Routing Encapsulation

GUA Global unicast address (IPv6)

IA-NA Association - Non-temporary Address

IA-PD Identity Association - Prefix Delegation

ICE Interactive Connectivity Establishment

IPv6CP IPv6 Control Protocol

LDP Label Distribution Protocol

LI Lawful intercept

LLA Link local address (IPv6)

LNS L2TP Network Server

LSN Large Scale Network address translation

LSP Label Switched Path

LSR Label Switch Router

MME Mobility Management Entity

MPLS Multi-Protocol Label Switching

NAT Network address translation

NAT64 Network address translation between

IPv6 and Ipv4

NAT-PMP NAT Port mapping protocol

OPEX Operational expenses

OS Operating system

OSS Operation support system

PCP Port configuration protocol

PDP Packet Data protocol

PE Provider Edge router

PGW PDN Gateway

PGW Packet Gateway (LTE)

PTA PPP Termination and Aggregation

RD Route Distinguisher

RG Residential Gateway

RP Rendezvous Point

RPF Reverse Path Forwarding

RR Route Reflector

SGW Serving Gateway

SLAAC Stateless address auto-configuration

STUN Simple Traversal of User Datagram

Protocol

TURN Traversal Using Relays around NAT

UE User equipment

ULA Unique Local address (IPv6)

UPnP Universal plug and Play protocol

VPN Virtual Private Network

VPRN Virtual Private Routed Network

ipv6 transition in fixed and mobile environments · 1.2 ipv6 transition: a multi-dimensional...

Documents