Upload
lytram
View
216
Download
0
Embed Size (px)
Citation preview
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.
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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.
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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)
ICMP6 – MLD report (join)
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
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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.
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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)
DHCPv6 – Solicit (IA_NA, IA_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)
ICMP6 – MLD report (join)
ICMPv6 – Router Advertisement
DHCPv6 – Advertise (IA_NA, IA_PD) DHCPv6 – Advertise (IA_NA, IA_PD)
DHCPv6 – Solicit (IA_NA, IA_PD)
ICMP6 – Neighbor Solicitation (DAD)
ICMP6 – MLD report (join)
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
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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.
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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
Aggregation/edge/coreAccessHome
GTP/PDPUE
IPv6: SLAAC/DHCP
IPv4 use caseNAT64
IPv4
DNS64
IPv6 use case
IPv6IPv6IPv6IPv6
IPv6IPv6IPv6
Private IPv4 address Public IPv4 address IPv6 address
IPMGW
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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.
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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
Private IPv4 address Public IPv4 address IPv6 address
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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
Public IPv4 use case
Aggregation/edge/core
Option 1
Optional
AccessHome
PPP, DHCPor IPoE
RG
IPv4: DHCP/NATIPv6: SLAAC/DHCP
NAT
IPv4IPv4 IPv4 IPv4
Private IPv4 use caseNAT CG-NAT
IPv4IPv4 IPv4 IPv4
IPv6 use caseOption 2
IPv6IPv6IPv6IPv6
Private IPv4 address Public IPv4 address IPv6 address
IPIP
BGP/IGP shortcuts forIPv4 + 6PE for IPv6 or
dual stack IP-VPN + IPv4to support IGP/MPLS
Public IPv4 use case
Aggregation/edge/core
Option 1
Optional
AccessHome
GTP/PDPUE
IPv4: DHCP/NATIPv6: SLAAC/DHCP
NAT
IPv4IPv4 IPv4 IPv4
Private IPv4 use caseNAT CG-NAT
IPv4IPv4 IPv4 IPv4
IPv6 use case
Option 2
IPv6IPv6IPv6IPv6
Private IPv4 address Public IPv4 address IPv6 address
IPMGW
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
15
The following implications should be considered when selecting this model:
• 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
Aggregation/edge/coreAccessHome
PPP, DHCPor IPoE
AFTRB4 IP
IPv4: DHCP/NATIPv6: SLAAC/DHCP
IPv4 use caseNAT
IPv4 IPv4
IPv6 use case
IPv6IPv6IPv6IPv6
IPv4IPv6IPv4IPv6
Private IPv4 address Public IPv4 address IPv6 address
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
16
AnAddressFamilyTransitionRouter(AFTR)isintroducedintheaggregationnetworktoencapsulate/de-encapsulateIPv4trafficin/fromIPv6,andprovidesCG-NATusingtheIPv6sourceprefixasthesubscriberkey.TheCPE/RGissuppliedusingDHCPv6withtheAFTRGWaddressandusesapredefinedprivateIPv4prefix.Moredetailsaredescribedindraft-ietf-softwire-dual-stack-lite-06.Figure14showsmoredetailsontheIPv4/IPv6connectivity using this transition scenario.
The following implications should be considered when selecting this model:
• 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.
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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.
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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.
IPv6 Transition in Fixed and Mobile EnvironmentsALCATEL-LUCENT TECHNOLOGY WHITE PAPER
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