TableOfContents

TableofContents
1. 2. 2.1 ExecutiveSummary............................................................................................................................3 Introduction.......................................................................................................................................4 EPSArchitecture......................................................................................................................................4 Simultaneousdualstacksupport.......................................................................................................5 Addressassignmentmechanisms......................................................................................................6 EvolvingpacketcoretoEPCandIPv6................................................................................................7

2.1.1 2.1.2 2.1.3 3. 3.1

VoiceCoreNetwork............................................................................................................................8 IPAddressUsageintheDistributedMSC...............................................................................................8 MSCtoSS7NetworkSIGTRAN........................................................................................................9 MSCServertoMediaGatewayMcinterface................................................................................11 MSCtoRNCforUMTSAccesssupportIuCSInterface.................................................................13 MSCtoMSCInterfaces....................................................................................................................16 SIPI .................................................................................................................................................18 .

3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.2 4. 4.1

MigratingtheVoiceCorefromIPv4andIPv6 ......................................................................................18 . ImpactoftheIntroductionofIPv6onSecurityinUMTS....................................................................19 IPv6SecurityIssuesOverview...............................................................................................................19 SecurityissuescommontoIPv4andIPv6........................................................................................19 SecurityissuesinvolvedintransitiontoIPv6...................................................................................20 SecurityissuesspecifictoIPv6.........................................................................................................21

4.1.1 4.1.2 4.1.3 4.2

OverviewofUMTSSecurityandIPv6...................................................................................................23 IPv6ImpactstoUMTSEndUserSecurity ........................................................................................23 . IPv6ImpactstoUMTSPacketNetworkSecurity..............................................................................23

4.2.1 4.2.2 4.3 4.4 5. 6. 7. 8.

IPv6ImpactsonLTESecurityImplementation.....................................................................................24 IPv6SecurityRecommendations..........................................................................................................24 Conclusions......................................................................................................................................25 Acknowledgements..........................................................................................................................25 References.......................................................................................................................................25 Glossary...........................................................................................................................................26

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

1.

EXECUTIVESUMMARY

As the wireless networks grow and evolve, the dependency on IP addresses becomes a vital ingredient to rolling out services. At the same time IPv4 addresses are being depleted, alwayson services(SIPbasedapplications)arealreadybeingdeployedatanincreasingrate;hence,theurgency tomovetoIPv6continuestobeamajorissueforoperatorsandvendorsinthewirelessindustry. ThepurposeofthispaperistobuildontheIPv6recommendationspresentedinthefirstiterationof 3GAmericasIPv6WhitePaperpublishedin2008.Thefocusofthispaperincludescommonareasof interestthatwillaffectinteroperabilityandotherappropriateissues.Thispapercoversthefollowing areas:

TheevolutiontotheEvolvedPacketCore AssessimpactofIPv6toexistingVoiceCore EnsurenetworkSecurityduringtransitiontoIPv6

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

2.

INTRODUCTION

The Evolved Packet Core is the mobility core solution associated with the Evolved Universal Terrestrial Radio Access Network (EUTRAN), which was formally known as Long Term Evolution (LTE).EPCandEUTRANaredefinedby3GPPsRelease8specifications,inparticular[1],[2]and[3]. ThecombinationofEUTRANandEPCiscalledEvolvedPacketSystem(EPS). 2.1 EPSARCHITECTURE

TheEPSarchitectureisdepictedinthefollowingfigure.

Figure1:EvolvedPacketSystem EUTRAN introduces a new radio interface technology. A base station that supports this radio interfacetechnologyiscalledEvolvedNodeB(eNB). TheEPCarchitectureconsistsofaMobilityManagementEntity(MME)andtwogateways,theServing Gateway(SGW)andthePacketDataNetworkGateway(PDNGWorPGW). The MME is responsible for control plane functions: authentication, mobility management, paging and signaling security. Many of the functions and protocols supported by the MME are similar to thosesupportedbySGSNsinUMTSdeployments.IncontrasttotheSGSN,theMMEsolelydealswith controlprotocols.UserplanetrafficflowsdirectlybetweentheeNBandthegateways. Thetwogatewaysmaybecombinedinasinglenetworkelement.InthecasethatSGWandPGW are separate network elements, there are two options for the protocol used between them: GPRS TunnelingProtocol(GTP)andProxyMobileIPv6(PMIPv6).

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

2.1.1 SIMULTANEOUSDUALSTACKSUPPORT Similar to the concept of PDP Context, which is defined in 3GPPs R7 specifications, the R8 specifications identify EPS bearers. An EPS bearer is a logical connection between a UE and a gateway,associated with aspecificQoSClass.An EPSbearer cancarry multipleServiceDataFlows (SDF),aslongastheseSDFsbelongtothesameQoSclass IncontrasttothePDPContextdefinitionin3GPPR7,anEPSbearercancarrybothnativeIPv4and IPv6 traffic. Therefore, a UE can support simultaneously an IPv4 and an IPv6 stack while being connectedthroughasingleEPSbearer. Inaprevious3GAmericaswhitepaperonIPv6([4]),itwasarguedthatinUMTSdeployments,support ofsimultaneousdualstackwasimpractical,becausethenumberofPDPContextthatwouldneedto be setup would be unacceptably high. Since EPC allows both IPv4 and IPv6 traffic on a single EPS bearer,supportofsimultaneousdualstackinEPCdoesnotsufferfromthesameproblem. Of course, allocating both IPv6 and IPv4 addresses to a device does not solve the problem of IPv4 exhaustion.AserviceprovidermaythereforedecidetoassignonlyIPv6addressestocertaindevices, evenwhenthedeviceisabletosupportIPv4andIPv6simultaneously.Inthatcase,NATPT(seeRFC 2766) or IPv6toIPv4 httpproxy functionality may be required to connect these IPv6only devices withlegacyIPv4endpoints.Suchadecisionneedscarefulconsiderationandtheissuesidentifiedin RFC4966(NATPTIssuesAnalysis)needtobetakenintoaccount. Note that the 3GPP R8 specs also provide updates to UMTS specifications. An R8based UMTS networkcancarrybothIPv4andIPv6trafficoverasinglePDPContext.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

2.1.2 ADDRESSASSIGNMENTMECHANISMS AUserEquipmentdevice(UE)obtainsanIPaddressinoneoftwoways: aspartoftheattachmentprocedure viasseparateassignmentprocedure,suchasDHCPorIPv6StatelessAddress Autoconfiguration

Theattachmentprocedureisdepictedinthefollowingfigure:

Figure2:Attachmentprocedure Theattachmentprocedureconsistsofthefollowingsteps: 1. The User Equipment (UE) requests attachment by sending a message to the MME. This is followedbyanauthenticationprocedurethatinvolvestheHSS.Aspartofthisprocedure,the HSSsendssubscriptiondataassociatedwiththeusertotheMME. 2. The MME is, with a few exceptions, responsible for selecting the Serving and PDN Gateways thatwillbeusedforthisUE.Itsendsarequestfortheestablishmentofthedefaultbearerto theSGW,whichforwardsittothePGW.Thismessageexchangeresultsintheestablishment ofaGTPtunneloraMobileIPtunnelsegmentbetweenSGWandPGW.Thissegmentremains up,aslongastheuserisattached,evenwhentheUEenterstheidlestate. 3. Asalaststep,theMMEorchestratestheestablishmentoftheGTPtunnelsegmentbetweenS GWandeNBandthe(default)radiobearerbetweeneNBandUE.ThebearerbetweenSGW and UE is torn down whenever the UE goes to idle state. If the SGW receives IP packets destinedfortheUEwhileitisinidlestate,theSGWtriggerstheMMEwhichstartsapaging procedure. In the case IP address assignment is part of the attachment procedure, the PGW allocates an IP addresstotheUEaspartofstep2.ThisaddressisconveyedtotheUEintheGTPcontrolmessages thatareusedtoestablishtheEPSbearerinstep3.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

Once a default bearer is established (with or without IP address assignment), the UE can perform DHCPorIPv6StatelessAddressAutoconfiguration(SLAAC)toobtainanIPaddress.Thus,forexample, aUEcouldobtainanIPv4addressaspartoftheattachmentprocedureandanIPv6addressthrough anadditionalIPv6SLAACprocedure. 2.1.3 EVOLVINGPACKETCORETOEPCANDIPV6

Introduction of LTE requires new or upgraded NodeBs and new mobility gateways in the core network.Manyserviceproviders,however,willgraduallyupgradetheirnetworkstoLTE.Therefore, LTEandUMTS(andprevioustechnologies)willbedeployedsimultaneously. ThefollowingfigureshowshowLTEandUMTSnetworksinterface.

Figure3:CombinedLTEandUMTSnetworkarchitecture When a UE, after attaching through an LTE radio link, moves out of the reach of LTE eNBs, it may havetofallbacktoUMTS.ThehandovertoUMTSisorchestratedbytheMME,whichinterfaceswith thetargetSGSN.ThePDPContextisroutedviatheSGSNtotheSGWtowhichtheUEwaspreviously connected. If the UE is a dualstack device with its IPv4 and IPv6 stack simultaneously active, a handover may haveimpactonitsoperations.IftheUEishandedovertoanR8compliantUMTSnetwork,thereare noconsequences,astheR8PDPContextcancarrybothIPv4andIPv6traffic.However,iftheUEis handed over to an R7compliant UMTS network (which is the more likely scenario), this does not work,sinceanR7PDPContextcarrieseitherIPv4trafficorIPv6traffic,butnotboth. 3GPPstandardsspecifyaonetoonemappingbetweenEPSbearersandPDPcontexts.Thisimplies thatanoperatoreitherneedstoupgradeallSGSNs(connectedtotheEPC)toRel8,ordisabledual stackoperationovertheEPSnetwork.Inthelattercase,aUEthatrequestsdualstackoperationat attachment to the EPS network will only receive a singlestack bearer, say for IPv4, and it will subsequentlyneedtoinitiateasecondbearerestablishmenttowardsthesameAPNforIPv6.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

3.

VOICECORENETWORK

Voicetelephonyservicesina3GPPnetworkaretraditionallyprovidedbyaMobileservicesSwitching Centre(andsupportinginfrastructure)and/oranIPMultimediaSystem. As the name implies, IP Multimedia Subsystems (IMS) rely heavily on IP protocol. Per 3GPPP standards,IMSequipmentshouldbedeployedusingIPv6therebyavoidingtheneedforafutureIPv4 toIPV6migration. WhereasnewIMSequipmentwilltypicallybedeployedwithIPv6,existingvoicecoreequipmentwill still be utilizing IPv4. Since the MSC is at the heart of any existing 3GPP voice core, this section focuses on the use of IP in the Mobileservices Switching Centre (MSC). As part of the MSC discussion,IPinterfacestosubtendingvoicecorenetworkelementsarealsocovered. 3.1 IPADDRESSUSAGEINTHEDISTRIBUTEDMSC

The Mobileservices Switching Centre (MSC) performs all CS domain switching and signalling functionsforGSMandUMTSmobilestationslocatedinaspecificgeographicalarea.TheMSCcan beimplementedinanintegratedplatformorintwodistinctphysicalentities. WhendividedintotwophysicalentitiestheMSCconsistsofanMSCServer,handlingonlysignalling, and a MGW, handling user data. This architecture of dividing the signalling server from the data planeissometimesreferredtoasadistributedMSC.

BTSBaseTransceiverStation BSCBaseStationController HLRHomeLocationRegister MSCMobileSwitchingCentre MSCSMSCServer

MSCS NodeB NodeB BTS BTS RNC
Iu-CS Mc SIP-I or Nc Mc

STP

HLR

SIGTRANorSS7 Network

MSCS

A Interface

MGW

(H.248)

MGW

(H.248)

BSC

TCU

Distributed MSC

Distributed MSC

Figure4.GSM/UMTSVoiceCorewithaDistributedMSC

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

Dependentonthevendorimplementation,thedistributedMSCmaybeenhancedtofunctioninan IMS environment as a Telephony Application Server (TAS), MGCF/IMMGW, IMSSF, MRF, MSC enhancedforICS,MSCenhancedforSRVCCetc.,ormaybeextendedtoserviceSIPuserequipment directly. For interconnect, a distributed MSC will typically utilize a mix of packet or cell based protocols including IP and/or ATM. Since IP interfaces in a distributed MSC environment are generally a supersetofanintegratedMSC,thispaperassumesadistributedMSCasthereferencepoint. EveryinstanceofanIPaddressmustbeconsideredwhenmigratingfromIPv4toIPv6oroperatingin a dualstack environment. The following subsections identify where IP addresses are typically utilizedwithinthedistributedMSC. 3.1.1 MSCTOSS7NETWORKSIGTRAN

InaGSM,UMTS,or4Gnetwork,theMSCmayconnecttootherSSPs,STPs,orSCPs(suchastheHLR) viaatraditionalSS7protocolstackorviaSIGTRAN. SIGTRAN, as defined in RFC 2719 and RFC 4166, is a set of protocols that allow circuit switch telephony messages, such as Media Gateway control and SS7 messages, to be reliably transported overanIPnetwork.SIGTRANconsistsofthreecomponents:astandardIPlayer,anSCTPlayer,and useradaptationlayer(s). When migrating networks from IPv4 to IPv6, all three of the SIGTRAN components must be considered. Components above SIGTRAN are also relevant when migrating from IPv4 to IPv6; however,discussionforupperlayersignalingcomponentsisreservedforsubsequentsections.
SignalingProtocols (maycontainembeddedIP@) UserAdaptationLayer:M2PA,M2UA,M3UA,SUA (SUAmaycontainembeddedIP@) SCTP(embeddedIP@) SIGTRAN

IP L1
Figure5.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

3.1.1.1

SCTP

TomeettheperformancerequirementsofatelephonynetworkinanIPenvironment,SIGTRANuses theSCTPprotocoldefinedinRFC3257.SCTPisaconnectionorientedprotocolthatoffersmultiple servicesincluding:Multihoming,Multistreaming,Heartbeat,amongothers. WhenmigratingfromIPv4toIPv6,ofparticularnoteisSCTPsmultihomingservice.Multihoming allowsanassociationtosupportmultipleIPaddressesatagivenendpoint. Theuseofmorethan oneIPaddressatanendpointincreasesnetworkrobustnessbyprovidinganalternatepathforre transmissionsorallowingreroutingofpacketsduringfailurescenarios. AspartofSCTPsmultihomingservice,SCTPcontrolpacketscarryembeddedIPaddressesduringthe connectionsetupprocess.ThisallowstheendpointstoexchangeIPaddresslists. Although SCTPs multihoming service can provide increased network resiliency, the embedded IP addresses exchanged during connection setup complicate the use of a NATPT and the potential interworkingbetweenIPv4andIPv6networkelements. AsdiscussedinRFC4966section2.6[5],useofNATPTwithSCTPshouldgenerallybeavoided. 3.1.1.1 USERADAPTATION(UA)LAYERS

AbovetheSCTPlayer,SIGTRANoffersmultipleuseradaptationlayersincluding:M2PA,M2UA,M3UA andSUA.TheuseradaptationlayersmimictheservicesofthelowerlayersofSS7andISDN. Among the adaptation layers, M3UA and SUA are IP aware and require special attention when migratingfromIPv4toIPv6. 3.1.1.2.1 M3UA

M3UAisdefinedinRFC4666.M3UAisIPawareinthatittranslatespointcodestoIPaddressesand vice versa using a Routing Key. However, M3UA does not exchange IP address information within any of its messages. Rather, M3UA relies on point codes to identify end points and defines boundariesbetweenitselfandMTP3,SCTP,andLayerManagement. BecauseM3UAdoesnotexchangeIPaddressinformationwithinanyofitsdefinedmessages,address translatorswilloperatetransparentlywithinthenetworkwithrespecttoM3UAthereisnoneedfor an application layer gateway for M3UA. Still, IPv4 and IPv6 must be considered at the M3UA end points:attheIPprotocolportandwithintheM3UAsoftware. 3.1.1.2.2 SUA

SUAisdefinedinRFC3868.SUAsupportsbothconnectionlessandconnectionorientedoperations. SUAmaydeterminethenexthopIPaddressbasedonGlobalTitleinformation(e.g.E.164number),IP addressorpointcodecontainedinthecalledpartyaddress.Accordingly,someSUAmessagessuchas

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

10

CLDT (Connectionless Data Transfer), CLDR (Connectionless Data Response), Connection Request (CORE), Connection Refused (COREF), and COAK (Connection Acknowledge) may embed IP address informationasaparameter. 3.1.2 MSCSERVERTOMEDIAGATEWAYMCINTERFACE

InadistributedMSCenvironment,theMSCServerusesH.248ontheMcinterfacetocontrolaMedia Gateway. WhenplanningamigrationfromIPv4toIPv6ontheMcinterface,aminimumofthree layersmustbeconsidered:thenetwork/transportlayer,theSCTPlayer,andtheH.248layer. 3.1.2.1 NETWORK/TRANSPORTLAYER

Atthenetwork/transportlayer,the3GPPstandardsallowforthefollowingMcinterfaceoptions: 1.) 2.) 3.) AmixedIP&ATMconnectionH.248/M3UA/SCTP/IP/AAL5/ATMasanexample ApureIPconnectionH.248/M3UA/SCTP/IPwithM3UAasanoptionallayer. ApureATMconnectionH.248/MTP3b/SSCF/SSCOP/AAL5/ATM

ThefirsttwointerfaceoptionsbothutilizeIPandmustbeconsideredwhenmigratingfromIPv4and IPv6.ThethirdoptioninvolvesnoIPaddressingandisthereforeexcludedfromthispaper. In the first two options, the Mc interface IP connections may be either IPv4 or IPv6. The diagram below provides a protocol stack for the Mc interface in the pure IP connection and mixed IP & ATMconnectioncases.NotethattheM3UAlayerisanoptionallayerinthepureIPcase.[3GPP TS29.232V4.17.0(200706)page11]. H.248(embeddedIP@) M3UA(optionallayer) SCTP(embeddedIP@) IP L1 Figure6.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

11

3.1.2.2

SCTPANDM3UA

The Mc interface uses the SCTP protocol and may optionally use the M3UA layer as discussed in section6.1.1.TheSCTPlayerembedsIPaddressesduringconnectionsetupwhichcomplicatesthe useofNATPTforIPv4toIPv6migrations.FormoreinformationonSCTPandM3UArefertosection 6.1.1. 3.1.2.2 H.248LAYER

Above the network/transport and SCTP layers, and within H.248 layer, IP addresses are also embedded. For example, during a call setup across an IP backbone, the MSC server will send an H.248 Add requesttothelocalMGWtocreateacontext.ThelocalMGWrespondstotheMSCserverwithan H.248 Reply message. Inside the Reply message is the local descriptor which contains the local MGWsbearerIPaddress.ThelocaldescriptormakestheMSCserverawareoftheIPtermination pointforwhichitmustdirecttheincomingIPmediastream. Similarly, the remote MGW provides its bearer IP address to its controlling MSC server within the H.248messaging.ThisIPaddress(partoftheRemoteDescriptor)isrelayedtothelocalMGW.The localMGWusesthisRemoteDescriptorIPtoappropriatelyaddresstheoutgoingmediastream. ThisexchangeofIPaddresseswithintheH.248layerallowsforthedynamicswitchingofVoIPpackets betweenMGWcontexts. Asmentionedintheexampleabove,H.248commandsmayspecifyanIPv4orIPv6addressanywhere aLocal,Remoteand/oraLocalControlDescriptorareutilized[ITUTRec.H.248.1(09/2005)Annex C]. 3.1.2.3 H.248.37

BecauseH.248messagingbetweenthecallserverandMGWeffectivelyrelaysIPaddressinformation betweenMGWs,H.248byitselfdoesnotallowforNAPTtraversalbetweenMGWs.Toovercomethis limitation,H.248.37wasdeveloped. H.248.37allowstheMSCServertoinstructaMGWtolatchtoanaddressprovidedbyanincoming Internet Protocol (IP) application data stream rather than the address provided by the call/bearer control.ThisenablestheMGWtoopenapinholefordataflow.ItalsoallowstheMGWtoignore theRemoteDescriptorMGWIPaddressinformationprovidedintheH.248messaging. When the NAPT parameter on a termination/stream is set to LATCH, the MGW ignores the IP addresses received in the RemoteDescriptor. Instead, the MGW will use the source address and source port from the incoming media stream (i.e., from the other termination) as the destination addressanddestinationportoftheoutgoingapplicationdata.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

12

Ignoring the RemoteDescriptor IP addresses in the H.248 messaging, makes IP address translation within the network transparent to basic MGW operations. Thus, H.248.37 could be used to allow interworkingofanIPv4MGWwithanIPv6MGW,allowtwoIPv4MGWstocommunicateacrossan IPv6backbone,and/orhelpfacilitateanIPv4toIPv6migration.Still,H.248.37hasaseriouslimitation asdiscussedbelow. H.248.37 assumes that the media stream has already been established and VoIP traffic is already flowingbetweenMGWs.ForH.248.37andNATPTtobeeffectiveinallowinginterworkingofIPv4to IPv6capableMGWs,themediastreammustfirstbeestablishedwithanIPaddressprovidedinthe H.248 messaging. This implies that either the call server includes an Application Level Gateway ControlFunction(ALGCF)tocontroladynamicNAT[6],oritimpliesthatstaticaddresstranslationis usedbetweentheMGWs. 3.1.3 MSCTORNCFORUMTSACCESSSUPPORTIUCSINTERFACE

TheUMTSaccessnetworkisconnectedtotheMSCviatheIuCSinterface.StandardsallowforIuCS tobetransportedoverATMorIP.Witheithertransportoption,IuCSoverIPorIuCSoverATM,the IuCSinterfacecanbelogicallydividedintothreeareas: 1. 2. 3. 3.1.3.1 ControlPlane BearerControlPlane Bearer(orUser)Plane IUCSCONTROLPLANE

TheIuCScontrolplanecarriesRANAPsignalingbetweentheUTRANandMSCS.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

13

 3.1.3.2 IUCSOVERIP

For the IuCS over IP control plane, three layers must be considered when migrating from IPv4 to IPv6:thenetwork/transportlayer,theSCTPlayer,andtheRANAPlayer.Noticetheprotocolstack showninthefigurebelow(3GPPTS25.412section5.2.3). RANAP(embeddedIP@) SCCP M3UA SCTP(embeddedIP@) IP DataLinkLayer(e.g.GigE,FE) PhysicalLayer Figure7. Asdiscussedinsection6.1.1,SCTPoffersamultihomingservicewhichprovidesredundancybetween twoSCTPendpoints.Aspartofmultihoming,SCTPmessagesexchangeIPtransportlayeraddresses duringconnectionsetup[8]. IntheRANAPlayer,transportlayerIPaddressareexchangedbetweentheRNCandMGWusingthe Prepare_IP_Transportprocedure. InthePrepare_IP_Transportprocedure,theMSCserverrequeststheMGWtoprovideIPTransport AddressandanIuUDPPortandprovidestheMGWwiththebearercharacteristics.AftertheMGW has replied with the IP address and UDP Port, the MSC server requests access bearer assignment usingtheprovidedIPaddressandUDPPortinaccordancewith3GPPTS25.413. TheIPaddressesandUDPPortsoftheMGWandtheRNCareexchangedviatheRANAPprocedures. IfthebearertransportisIPandIuUPmodeisTransparent,whentheMSCreceivestheRANAPRAB assignment response it sends the RNC IP address and UDP Port to the MGW Access bearer terminationusingtheModify_IP_Transport_Addressprocedure. IfthebearertransportisIPandIuUPmodeisSupport,theMGWusesthesourceIPaddressandUDP Port of the IuUP Init packet received from the radio access network as the destination address for subsequent downlink packets. The RNC is already aware of the MGW IP address because the Call ServerprovidestheRNCtheMediaGatewaysIPaddressintheRABAssignmentRequestmessage.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

14

3.1.3.3

IUCSOVERATM

IntheIuCSoverATMconfiguration,thecontrolplaneusesbroadbandSS7signalingwhichdoesnot requireIP. It should be noted however that some vendors, in particular those who have an allIP MSC server, mayconvertM3UA/IPtobroadbandSS7inaSignalingGateway(SGW)orMGW.Becausethistypeof implementation is vendor specific, IPv4 to IPv6 migration concerns should be worked directly with thevendorfortheIuCSoverATMinterface. 3.1.3.4 IUCSBEARERCONTROLPLANE

ThebearercontrolplaneisonlyapplicableforIuCSoverATM,anddoesnotneedtobeconsidered whenplanninganIPv4toIPv6migration. 3.1.3.5 IUCSBEARER(ORUSER)PLANE

TheIuCSbearercanutilizeATMorIPatthetransportlayer.InanATMconfiguration,thebeareris transportedoverAAL2virtualcircuitconnections.InanIPconfiguration,beareristransportedover RTP/UDP/IP[9]. AprotocolstackoftheIuCSBearerusingIPtransportisprovidedbelow. RTP UDP IP DataLinkLayer(e.g.GigE) PhysicalLayer Figure8. MSCtoTCU/BSCforGSMAccesssupportAInterface At the time of the writing of this document, standards for Ainterface over IP standards were still beingdevelopedby3GPP.Previously,theAinterfaceimplementationdidnotutilizeorsupportIP. AInterfaceisthereforeexcludedfromthispaper.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

15

3.1.4 3.1.4.1

MSCTOMSCINTERFACES BICCARCHITECTURE

Bearer Independent Call Control (BICC) is a signaling protocol used to support narrowband ISDN serviceindependentofthebearertechnologyandsignalingmessagetransporttechnologyused. BICC was developed to be interoperable with any type of bearer, such as ATM, IP, and TDM. The followingsectionfocusesonBICCwhenusedinanIPnetwork. ThreeinterfacesaredefinedinaBICCarchitecture: NbMGWtoMGW Mc(G)MSCServertoMGW NcMSCServerto(G)MSCServer 3.1.4.2 NBINTERFACE

TheNbinterfacetransportsbearerinformationbetweenMGWs.The3GPPstandardssupportTDM, IP,andATMtransportontheNbinterface.TheprotocolstackoftheNbinterfaceusingIPtransport isprovidedbelow:

G.711

UMTSAMR/AMR2

NbUP[29.415] RTP[RFC3550] UDP[RFC768] IP L1 Figure9.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

16

3.1.4.3

TUNNELINGACROSSTHEMCANDNCINTERFACES

Because BICC is Bearer Independent it utilizes other protocols for exchanging media stream characteristics. In an ATM network, BICC uses ALCAP/Q.2630 signaling for bearer control of Nb. The ATM bearer controliscarrieddirectlybetweenMGWsalongsidethebearertraffic. In IP networks, the IP bearer control is not carried directly between MGWs alongside the bearer traffic. Nb bearer control is tunneled between MGWs via the Mc and Nc interfaces using IPBCP (IP BearerControlProtocolQ.1970).ThefigurebelowillustratesthepathforIPBCP.

Nc MSC MSC

Mc

IPBCP MGW Nb MGW

Mc

Figure10. IPBCP protocol allows the establishment and modification of IP bearers on the MGWs. IPBCP exchangesmediacharacteristicssuchasportnumbersandIPaddressesofthesourceandsinkofa media stream. The exchange of information with IPBCP is done during BICC call establishment and after a call has been established. IPBCP uses a subset of the Session Description Protocol (SDP) definedin3GPP29.414toencodetheinformation. Although the transport layers for the Mc and Nc interfaces may consist of various protocols, the figurebelowprovidestheprotocolstackforIPBCPwhenIPisthetransporttype.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

17

IPBCP(embeddedIP@) BCTP[Q.1990] BICC IP L1

Figure11. 3.1.5 SIPI

SIPIisanextensionoftheSIPprotocol.SIPIisusedtotransportISUPmessagesacrossaSIPnetwork asattachmentstotheSIPmessages. SimilartoBICC,SIPIprovidesamechanismbywhichtwoMSCscanbeconnectedoveranIPnetwork. Though BICC was the first protocol standardized by 3GPP for interMSC Voice over IP connectivity, BICCislimitedtooperationinaGSM/UMTSenvironment.Thus,manyoperatorshaveoptedtouse SIPIforMSCinterconnect. To exchange media stream information between MGWs, SIPI utilizes the Session Description Protocol(SDP). 3.2 MIGRATINGTHEVOICECOREFROMIPV4ANDIPV6

As described in the preceding section, migration of the voice core from IPv4 to IPv6 is a complex activityrequiringconsiderationofnumerousprotocolsandlayersabovetheIPnetworklayer. OneoftheprimarydriversforamigrationfromIPv4toIPv6istoalleviateIPaddressconsumption. SincethemajorityofIPaddressesareconsumedbyenduserdevices,andafullmigrationofthevoice corefromIPv4toIPv6ishighlycomplex,inmostcasesitwillnotbefeasibletomigrateanoperators entire3GPP voicecore toIPv6.Instead,itismuch moreprobablethata migrationofIPv4toIPv6 withinthevoicecorewillonlybetargetedatspecificinterfaces. Forexample,anoperatormayopttoleaveallIuCS/IPandintracallserverMGWtoMGWtrafficas IPv4 while making all intercall server MGW to MGW traffic IPv6. This type of architecture would allow the network operator to only require dual stack capable MGWs on the network bound (vs. access)interfacesandwouldavoidtheneedforanIPv6capableRNC.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

18

4.

IMPACTOFTHEINTRODUCTIONOFIPV6ONSECURITYINUMTS

IPv6 currently has relatively limited deployments, thus few vulnerabilities have been exploited. As adoptionexpands,likeinIPv4,attacksontheprotocolwillemergeunlesssufficientlyprotected.IPv6 securityissueshaveimplicationsdirectlyfortheIPlayer,andindirectlyforapplicationsupportand thelinklayer.Andthesesecurityissuescanbeexaminedwithrespecttoendtoendsecurity,end togatewayandgatewaytogatewayconnections.TheimplementationofIPv6requiresextensionsto theexistingsecuritypolicyaswellasintroducingnewsecuritypoliciesspecifictoIPv6.Thesecurity concerns (threats and vulnerabilities) and specific solutions comprise those issues common to IPv4 andIPv6,thosesecurityissuesspecifictothetransitiontoIPv6,andthosespecifictoIPv6.IPv6must bemanagedtoprovideanequivalentlevelofsecurityasisprovidedforIPv4. ThefollowingsubsectionprovidesaconcisesummaryofsecurityissuesrelatedtoIPv6.Sections0 and0provideanoverviewofhowtheseissuesimpactordonotimpact3GPPandLTE. 4.1 IPV6SECURITYISSUESOVERVIEW

4.1.1 SECURITYISSUESCOMMONTOIPV4ANDIPV6 ManysecurityissuesandsolutionscommoninIPv4implementationsprojectforwardintoIPv6. FirewallsarerequiredtobeupdatedtosupportfirewallrulesspecifictoIPv6,aswellasupdatesfor SSH(SecureShellprotocolforremotelogin/filetransfer). IPsec, AH (authentication header) and ESP (encapsulating security payload) function essentially the sameforbothIPv4andIPv6.IPseccanbeusedtosupporttheroutingprotocols,RoutingInformation Protocol (RIP) & Open Shortest Path First (OSPFv3), if required. The Virtual Private Network (VPN) model in use must be updated to add IPv6 support. The IPv6 configuration in IKEv2 is still being worked on in the IETF and currently is defined with limitations with respect to IKEv2 and IPv6 functionality.RefertoIETFdraft,IPv6ConfigurationinIKEv2. ForDomainNameSystem(DNS)andDNSSECthesamesecurityconcernsapplytoIPv6asIPv4.There is no new impact to Transport Layer Security (TLS) functionality with the introduction of IPv6. Applicationlayer attacks have the same vulnerabilities. No new security concerns for Border GatewayProtocol(BGP)areintroducedwithIPv6. UpdatesarerequiredtosupportIPv6for:IntrusionDetectionSystems(IDS)andIntrusionPrevention Systems(IPS). With respect to the benefits of Network Address Translation (NAT), IPv6 provides alternative mechanisms.NATisoftenusedtoperformthetasksofafirewallbyestablishingdynamicstatefor connections to protect against unauthorized, ingress traffic, and also to perform topology hiding. NATshouldnotbeusedasasubstituteforafirewall.NATisnotinvulnerableandoncecompromised itiseasyforattackerstoscantheprivateaddressspaceontheinsideoftheNATforopenports.It

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

19

shouldalsobenotedthatNATcomplicatestheuseofIPsecforendtoendencryption.Forexample, thereisadditionaloverheadrequiredtosupportUDPencapsulationandNATkeepalivemessaging. IPv6providesseveralmechanismstosupporttopologyhiding.ThesizeofasingleIPv6subnetmakes ping sweeps and port scanning for network vulnerabilities unprofitable. Simply assigning multiple IPv6 addresses to a host, difficult in IPv4 due to the limited address space and on some hosts not supported, can aid in concealing the nodes in the internal network. Unique Local IPv6 Unicast Addressingcanbeusedforaddressallocationwithinasitethistrafficisforcommunicationwithina siteandshouldneverberoutedoutsidetheinternalnetwork.UntraceableIPv6addressing(random prefix allocation within a subnet) can be used to conceal the size and topology of the network, as opposed to sequential numbering within a subnet, commonly employed in IPv4 due to the limited numberofavailableaddresses. RefertoLocalNetworkProtectionforIPv6(RFC4864),foramorecompleteunderstanding. 4.1.2 SECURITYISSUESINVOLVEDINTRANSITIONTOIPV6 TheintroductionofIPv6hasimpactsonsecurityrelatingtothetransitionmechanismsofdualstack, tunneling,andtranslation. Dualstack Active IPv4only networks may already be vulnerable to IPv6 attacks if IPv6capable devices (dual stack) are included. The security policy should determine whether IPv6 packets in the IPv4only network should be blocked as IPinIP packets (41 in protocol field of IPv4 header) that may be concealingIPv6inIPv4attacks. RefertoRFC4942,IPv6Transition/CoexistenceSecurityConsiderations,foracompletedescriptionof issueswithsupportingadualstackenvironment. Tunneling There are several tunneling mechanisms proposed to allow IPv6 traffic to traverse IPv4only networks. Some are based on static configuration and some support automatic tunneling. In general,statictunnelingismoresecurethanautomatictunneling,butdoesnotscalewell.Tunneling mechanisms that are constructed using IPinIP, as 6in4 static or 6to4 automatic tunneling, cannot traverse a NAT when port translation is required (NAPT). Many of the automatic tunneling mechanisms,as6to4,ISATAPandTeredo,useembeddedIPv4addresseswithinthe128bitsofthe IPv6address. Dependinguponthetunnelingmechanismsemployed,filteringmayberequiredatfirewallstoblock IPinIP or IPv6 addresses with embedded IPv4 addresses. Embedded addressing may introduce vulnerabilitiesthatareabletotraversefirewalls.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

20

Refer to IPv6 Operations and Softwires IETF working groups for additional RFCs and drafts on IPv6 securitymechanismsrelatedtotunneling,www.ietf.org. Translation RefertoIETFdraft,AComparisonofProposalstoReplaceNATPT,forcurrentstatusofpossibleco existencemechanisms. RefertothefollowingreportsforamorecompleteunderstandingofIPv6securityissues: NorthAmericanIPv6TaskForce(NAv6TF)TechnologyReport, http://www.6journal.org/archive/00000287/01/nav6tf.analysis_ipv6_features_and_usabilit y.pdf IPv6andIPv4ThreatComparisonandBestPracticeEvaluation, http://www.seanconvery.com/v6v4threats.pdf

4.1.3 SECURITYISSUESSPECIFICTOIPV6 IPv6addressselectionalgorithm(sourceanddestination)securityhasimpactswithrespecttoingress filtering and attempts at session hijacking. This concern also applies for dualstack nodes and tunnelingenvironments. IPv6privacyextensions,whichareusedtovarytheInterfaceIdentifybytheendnode,canbeusedto thwartdeviceprofiling. New firewall rules for IPv6 are required to support policy for ICMPv6 and IPv6 extension headers: whichICMPmessagestoallowordeny,e.g.,PacketTooLargeforPMTU,whichextensionheadersto allowordeny,e.g.,denyRoutingHeaderType0,whethertoallowRoutingHeaderType2forMIPv6 RouteOptimization.RefertoRFC4890,RecommendationsforFilteringICMPv6MessagesinFirewalls andRFC4942,IPv6Transition/CoexistenceSecurityConsiderations. IPv6 stateless address autoconfiguration uses new ICMP messages in Router Advertisements (RA)/Router Solicitations (RS) and Neighbor Advertisements (NA)/Neighbor Solicitations (NS) that assistanIPv6nodeinconstructinganIPv6address.Newvulnerabilitiesareintroducedifthelinkis compromised. NA/NS and RA/RS can be protected using a linklevel security mechanism, as, for example,theSecureNeighborProtocol(SEND)andCryptographicallyGeneratedAddresses(CGA)to determine whether a router on the link is a trusted router. However, deployment of CGA may be limited due to Intellectual Property Rights issues and some technical concerns. Refer to the IETF workinggroup,Cga&Sendmaintenance(csi)forcurrentstatus. Certain IPv6 addresses should be filtered at the firewall, for example: IPv6 loopback, IPv4mapped address, unique local address, site local address, certain multicast addresses. The IPv6 use of multicast addressing introduces the potential for new vulnerabilities. Certain resources internal to the network are identifiable by multicast addressing. These addresses should be filtered at the

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

21

network boundary, depending upon their scope. These addresses also introduce the potential for DoS attacks. Also, IPv6 anycast addresses, such as Mobile IPv6 Home Agent anycast or Subnet Routeranycast,canpotentiallybeusedinDoSattacks. IPsec support is builtin to IPv6, which will allow for more instances of endtoend encryption, consistentwiththedesignofIPv6tomovemoreoftheresponsibilityforthesessiontotheendusers. However,enduserencryptionmakesexecutionofIDSmoredifficult.Ingeneral,consistentwiththe designofIPv6,somelevelofsecuritymaybemoveddowntotheendnodes,eitherforencryptionor attheapplicationlevel.Securitymaybetransitionedfromaperimetermodeltoadistributedmodel. PerformanceconsiderationsofIPv6securitymechanismsmustbebalancedagainstrisk.
MIPv6

Severalsecurityissues/mechanismsareintroducedwithMIPv6. IPseccanbeusedtosecurecommunicationbetweenthemobilenodeandthehomeagent.Asan alternative toIPsec,securingofbindingupdatesandbindingacknowledgements can beperformed usingMIPv6signalingmessagingbetweentheMobileNode(MN)andtheHomeAgent(HA).Referto RFC4285. In MIPv6, packet loss due to egress filtering at the access router is prevented by placing the IPv6 mobilenodescareofaddressintheexternalIPheaderwheninaforeignnetwork. Dynamic Home Agent Address Discovery relies upon special ICMP messaging, which is required to passthroughthenetworkfirewalls. Route optimization allows the mobile node and the correspondent node to communicate directly (ratherthanviathehomeagent),withoutprearrangedsecurityassociations.Additionalmessaging isrequiredtoperformreturnroutabilityforrouteoptimization.Inrouteoptimization,amobilenode reveals its careof address (current point of attachment) to the correspondent node. The careof addresscanbetraceabletoaparticularlocation.Itisaconcernthatamobileuserslocationcanbe compromisedwhenrouteoptimizationisused. HierarchicalMIPv6canbeusedtomitigatelocationprivacyissueswithrouteoptimization. IssueswithMobileIPv6securityhaveconsiderableimplicationsforendusersandthenetwork,andis toolargeatopictoduejusticetohere.RefertotheIETFMobilityEXTensionsforIPv6(mext)working grouprelatedRFCsforadditionalinformation.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

22

SecuritySupportTools

Additionalconsiderationsincludethestatusofcommon,securitysupporttools:Nessus(vulnerability scanner), Nmap (port scanner), Wireshark (packet analyzer), netcat (packet read/write), hping (packet generator), Snort (packet sniffer), to list only few of the open source and commercial products which all have varying levels of support for IPv6. The Status of commercial firewalls, IDS andIPStosupportIPv6isnotmature.RefertoNationalInstituteofStandardsandTechnology(NIST) report,FirewallDesignConsiderationsforIPv6. 4.2 OVERVIEWOFUMTSSECURITYANDIPV6

4.2.1 IPV6IMPACTSTOUMTSENDUSERSECURITY InPacketDateProtocol(PDP)ContextactivationusingIPv6statelessaddressautoconfiguration,the GatewayGPRSSupportNode(GGSN)assignsbothanIPv6InterfaceIdentifierand/64prefixtothe MobileStation(MS).Theprefixisuniquewithinitsscope.TheGGSNandMSaretheonlynodeson the local link, thus Duplicate Address Detection is not required. The MS is authenticated by the network and the PDP Context is tunneled within the network. The need for additional security measures,suchasSENDandCGAarenotrequiredforthePDPContextwithinthe3GPPnetwork. TheGGSNactsasananchorforthePDPContext,eliminatingtheneedforMIPv6,priortorelease8 (LTE). 3GPPsupportsIPv6privacyextensionsforthePDPAddress.ThePDPContextisidentifiedbytheIPv6 prefixattheServingGPRSSupportNode(SGSN)andGGSNandnotbythefull128bitPDPAddress. ForIMS,theGGSNprovidestheaddressofthePCSCFtotheMSforProxyDiscovery.TheMS,GGSN and PCSCF must support the same IP version. The MS point of attachment is at the external interfaceoftheGGSN.IMSreliesuponSIPsignalingbetweenenduserandPCSCFIMS.SIPsignaling is protected by IPsec or TLS. This protection is independent of the Access Network protection mechanisms. For IMS security, refer to IMS TS 33.203. For IPv4IPv6 interworking scenarios, refer to 3GPP TS 23.981. 4.2.2 IPV6IMPACTSTOUMTSPACKETNETWORKSECURITY SecurityprotectionisspecifiedforGTPcontroltraffic.Protectionofusertrafficisconsideredoutside thescopeofthestandards. TS32.210describestheminimumsecurityfeaturesinsupportofdataintegrity,originauthentication, antireplay protection, and confidentiality. 3GPP Network Domain Security provides hopbyhop protection,whichallowsforseparatesecuritypoliciesdependinguponwhetheralinkisintradomain

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

23

or interdomain and whether between trusted or untrusted domains. Security Gateways are stationedatthenetworkboundaryalltrafficbetweensecuritydomainsisviaaSecurityGateway. Authentication and integrity protection are mandatory between two security domains and encryptionusingESPintunnelmodeisoptional.ProtectionoftrafficwithintheSecurityDomainis optional. Firewallsatnetworkboundariesarerequiredtoprotectagainstunauthorizedtraffic. TheIMSnetworktopologycanbehiddenbyencryptingtheIMSnetworkelementIPaddressesinSIP messages. RefertoTS33.102,33.203,33.210and33.310fordetailsofNetworkDomainSecurityandTS33.234 forWLANinterworkingsecurity. 4.3 IPV6IMPACTSONLTESECURITYIMPLEMENTATION

TheLTEspecificationsupportsaflatIPnetworkbaseduponTCP/IPprotocols.Generalsecurityand enduserprivacyprinciplesfortheEPSarespecifiedinTS22.278.LTEspecificsecurityisdetailedin TS33.203,33.401,33,402and33.178. TheLTEUEsupportsdualstack,whichmayusesimultaneousIPv4andIPv6addresses,overanEPS Bearer(MIPbetweenSGWandPGW)orPDPContext(GTPtunneling). LTE supports interworking between 3GPP EPS and UTRAN, WLAN, CDMA, WIMAX and GERAN. Secure handover is supported between EPS and nonEPS access networks. This incurs additional complexitywithrespecttosecuritytosupportmobility,keytransferandalgorithmnegotiation,DS MIPv6orPMIPv6,andsupportforIPv4privateaddressing. 4.4 IPV6SECURITYRECOMMENDATIONS

ItisobviousbutsignificanttostresstheimportanceoftrainingandplanningfortheadoptionofIPv6 with respect to security. Once a security policy is established, it is necessary to stay current and vigilant with security vulnerabilities and with IPv6specific updates and vulnerabilities, as IPv6 continuestobeadopted. Notallsecuritysupportisequalknowthecapabilities/limitationsofhostsandroutersinnetwork: IPv6stacksupport,privacyextensions,IPsec,andfilteringcapabilities. Determineabalanceacrossrisk,overheadandperformanceofsecuritymechanisms.

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

24

5.

CONCLUSIONS

ThegrowthofalwaysonalwaysreachableservicesandthedepletionofIPv4addressesaretwokey driversmovingcarrierstoconsidertransitioningtoIPv6.IPv4willcoexistwithIPv6forseveralyears; therefore,transitionmechanismsandcoexistencetechniqueswillbeusedasthecarrierstransition toIPv6. CarriersevolvingtheirnetworkstoLTEshouldconsidermakingIPv6arequirementfromday1.Since LTE EPCdoesnotsupport aCircuitSwitchedCoreaspartofthe 3GPPstandard,nativesupportfor voice will be supported by the IMS core. Because the transition to IMSbased VoIP will likely take severalyears,itiscriticalforthecarrierstounderstandtheimpactsofIPv6ontheexistingVoiceCore and signaling infrastructure. Lastly, it is absolutely critical that the transition to IPv6 consider networksecurity. 6. ACKNOWLEDGEMENTS

The mission of 3G Americas is to promote and facilitate the seamless deployment throughout the Americas of the GSM family of technologies, including LTE. 3G Americas' Board of Governor membersincludeAlcatelLucent,AT&T(USA),Cable&Wireless(WestIndies),Ericsson,Gemalto,HP, Huawei,Motorola,NokiaSiemensNetworks,NortelNetworks,Openwave,ResearchInMotion(RIM), RogersWireless(Canada),TMobileUSA,Telcel(Mexico),TelefonicaandTexasInstruments. We would like to recognize the significant project leadership and important contributions of Paul SmithofAT&Taswellastheothermembercompaniesfrom3GAmericasBoardofGovernorswho participatedinthedevelopmentofthiswhitepaper. 7. REFERENCES

[1] GPRSenhancementsforEUTRANaccess(Release8);3GPPTS23.401;inprogress [2] ArchitectureEnhancementsfornon3GPPaccesses(Release8);3GPPTS23.402;inprogress [3] EvolvedUniversalTerrestrialRadioAccess(EUTRA)andEvolvedUniversalTerrestrialRadio AccessNetwork(EUTRAN),3GPPTS36.300;inprogress [4] TransitioningtoIPv6;3GAmericas;February2008

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

25

8.

GLOSSARY

AAA ALG APN CDR DAD DHCP DNS EMS GGSN GPRS GTP HSS HTTP IANA ICE IMS ICID NAT NOC PCRF PCSCF PDP QoS RAB RAN RIM RIR RNC RTCP RTP SCSCF SDP SLAAC SIP SGSN UE UMTS URI VPN

Authentication,AuthorizationandAccounting ApplicationLevelGateway AccessPointName CallDetailRecord DuplicateAddressDetection DynamicHostConfigurationProtocol DomainNameServer ElementManagementSystem GatewayGPRSSupportNode GeneralPacketRadioService GPRSTunnelingProtocol HomeSubscriberServer HyperTextTransferProtocol InternetAssignedNumberAuthority InteractiveConnectivityEstablishment IPMultimediaSubsystem IMSChargingIdentity NetworkAddressTranslation NetworkOperationCenter PolicyandChargingRulesFunction ProxyCallSessionControlFunction PacketDataProtocol QualityofService RadioAccessBearer RadioAccessNetwork ResearchinMotion RegionalInternetRegistry RadioNetworkController RealTimeControlProtocol RealTimeProtocol ServingCallSessionControlFunction SessionDescriptionProtocol StatelessAddressAutoConfiguration SessionInitiationProtocol ServingGPRSSupportNode UserEquipment UniversalMobileTelecommunicationsSystem UniversalResourceIdentifier VirtualPrivateNetwork

3GAmericasIPv6LTEandEvolvedPacketCoreFebruary2009

26