8/8/2019 3G Americas IPv6 LTE
1/26
TableOfContents
8/8/2019 3G Americas IPv6 LTE
2/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 2
TableofContents
1. ExecutiveSummary............................................................................................................................3
2. Introduction.......................................................................................................................................4
2.1
EPSArchitecture
......................................................................................................................................
4
2.1.1 Simultaneousdualstacksupport.......................................................................................................5
2.1.2 Addressassignmentmechanisms......................................................................................................6
2.1.3 EvolvingpacketcoretoEPCandIPv6................................................................................................7
3. VoiceCoreNetwork............................................................................................................................8
3.1 IPAddressUsageintheDistributedMSC...............................................................................................8
3.1.1 MSCtoSS7NetworkSIGTRAN........................................................................................................9
3.1.2 MSCServertoMediaGatewayMcinterface................................................................................11
3.1.3 MSCtoRNCforUMTSAccesssupportIuCSInterface.................................................................13
3.1.4 MSCtoMSCInterfaces....................................................................................................................16
3.1.5 SIPI..................................................................................................................................................18
3.2 MigratingtheVoiceCorefromIPv4andIPv6.......................................................................................18
4. ImpactoftheIntroductionofIPv6onSecurityinUMTS....................................................................19
4.1 IPv6SecurityIssuesOverview...............................................................................................................19
4.1.1 SecurityissuescommontoIPv4andIPv6........................................................................................19
4.1.2 SecurityissuesinvolvedintransitiontoIPv6...................................................................................20
4.1.3 SecurityissuesspecifictoIPv6.........................................................................................................21
4.2 OverviewofUMTSSecurityandIPv6...................................................................................................23
4.2.1 IPv6ImpactstoUMTSEndUserSecurity.........................................................................................23
4.2.2 IPv6ImpactstoUMTSPacketNetworkSecurity..............................................................................23
4.3 IPv6ImpactsonLTESecurityImplementation.....................................................................................24
4.4 IPv6SecurityRecommendations..........................................................................................................24
5. Conclusions......................................................................................................................................25
6. Acknowledgements..........................................................................................................................25
7. References.......................................................................................................................................25
8. Glossary...........................................................................................................................................26
8/8/2019 3G Americas IPv6 LTE
3/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 3
1. EXECUTIVE SUMMARY
As the wireless networks grow and evolve, the dependency on IP addresses becomes a vital
ingredientto
rolling
out
services.
At
the
same
time
IPv4
addresses
are
being
depleted,
always
on
services(SIPbasedapplications)arealreadybeingdeployedatanincreasingrate;hence,theurgency
tomovetoIPv6continuestobeamajorissueforoperatorsandvendorsinthewirelessindustry.
ThepurposeofthispaperistobuildontheIPv6recommendationspresentedinthefirstiterationof
3GAmericasIPv6WhitePaperpublishedin2008. Thefocusofthispaperincludescommonareasof
interestthatwillaffectinteroperabilityandotherappropriateissues. Thispapercoversthefollowing
areas:
TheevolutiontotheEvolvedPacketCore
Assess
impact
of
IPv6
to
existing
Voice
Core
EnsurenetworkSecurityduringtransitiontoIPv6
8/8/2019 3G Americas IPv6 LTE
4/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 4
2. INTRODUCTION The Evolved Packet Core is the mobility core solution associated with the Evolved Universal
Terrestrial Radio Access Network (EUTRAN),whichwas formally known as Long Term Evolution
(LTE).EPCandEUTRANaredefinedby3GPPsRelease8specifications, inparticular[1],[2]and[3].
Thecombination
of
EUTRAN
and
EPC
is
called
Evolved
Packet
System
(EPS).
2.1 EPS ARCHITECTURE
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).
TheMME is responsible for controlplane functions:authentication,mobilitymanagement,paging
and signaling security.Manyof the functionsandprotocols supportedby theMMEare similar to
thosesupportedbySGSNsinUMTSdeployments.IncontrasttotheSGSN,theMMEsolelydealswith
control
protocols.
User
plane
traffic
flows
directly
between
the
eNB
and
the
gateways.
Thetwogatewaysmaybecombined inasinglenetworkelement.InthecasethatSGWandPGW
areseparatenetworkelements, thereare twooptions for theprotocolusedbetween them:GPRS
TunnelingProtocol(GTP)andProxyMobileIPv6(PMIPv6).
8/8/2019 3G Americas IPv6 LTE
5/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 5
2.1.1 SIMULTANEOUS DUALSTACKSUPPORT
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,associatedwithaspecificQoSClass.AnEPSbearercancarrymultipleServiceDataFlows
(SDF),as
long
as
these
SDFs
belong
to
the
same
QoS
class
IncontrasttothePDPContextdefinition in3GPPR7,anEPSbearercancarrybothnative IPv4and
IPv6 traffic. Therefore, a UE can support simultaneously an IPv4 and an IPv6 stack while being
connectedthroughasingleEPSbearer.
Inaprevious3GAmericaswhitepaperonIPv6([4]),itwasarguedthatinUMTSdeployments,support
ofsimultaneousdualstackwasimpractical,becausethenumberofPDPContextthatwouldneedto
be setupwouldbeunacceptablyhigh. SinceEPCallowsboth IPv4and IPv6 trafficona singleEPS
bearer,supportofsimultaneousdualstackinEPCdoesnotsufferfromthesameproblem.
Ofcourse,
allocating
both
IPv6
and
IPv4
addresses
to
adevice
does
not
solve
the
problem
of
IPv4
exhaustion.AserviceprovidermaythereforedecidetoassignonlyIPv6addressestocertaindevices,
evenwhenthedeviceisabletosupportIPv4andIPv6simultaneously. Inthatcase,NATPT(seeRFC
2766) or IPv6toIPv4 httpproxy functionalitymay be required to connect these IPv6onlydevices
with legacyIPv4endpoints.Suchadecisionneedscarefulconsiderationandthe issues identifiedin
RFC4966(NATPTIssuesAnalysis)needtobetakenintoaccount.
Note that the 3GPP R8 specs also provide updates to UMTS specifications. An R8based UMTS
networkcancarrybothIPv4andIPv6trafficoverasinglePDPContext.
8/8/2019 3G Americas IPv6 LTE
6/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 6
2.1.2 ADDRESSASSIGNMENT MECHANISMS
AUserEquipmentdevice(UE)obtainsanIPaddressinoneoftwoways:
- aspartoftheattachmentprocedure
- viasseparateassignmentprocedure,suchasDHCPorIPv6StatelessAddress
Autoconfiguration
Theattachmentprocedureisdepictedinthefollowingfigure:
Figure2:Attachmentprocedure
Theattachmentprocedureconsistsofthefollowingsteps:
1. The User Equipment (UE) requests attachment by sending amessage to theMME. This is
followedbyanauthenticationprocedurethat involvestheHSS.Aspartofthisprocedure,the
HSSsendssubscriptiondataassociatedwiththeusertotheMME.
2. TheMME is,witha fewexceptions, responsible forselecting theServingandPDNGateways
thatwillbeusedforthisUE.Itsendsarequestfortheestablishmentofthedefaultbearerto
theSGW,whichforwardsittothePGW.Thismessageexchangeresultsintheestablishment
ofaGTPtunneloraMobileIPtunnelsegmentbetweenSGWandPGW.Thissegmentremains
up,aslongastheuserisattached,evenwhentheUEenterstheidlestate.
3. Asalaststep,theMMEorchestratestheestablishmentoftheGTPtunnelsegmentbetweenS
GWand
eNB
and
the
(default)
radio
bearer
between
eNB
and
UE.
The
bearer
between
SGW
andUE is torn downwhenever theUE goes to idle state. If the SGW receives IP packets
destined fortheUEwhile it is in idlestate,theSGWtriggerstheMMEwhichstartsapaging
procedure.
In the case IP addressassignment ispartof theattachmentprocedure, thePGWallocatesan IP
addresstotheUEaspartofstep2.ThisaddressisconveyedtotheUEintheGTPcontrolmessages
thatareusedtoestablishtheEPSbearerinstep3.
8/8/2019 3G Americas IPv6 LTE
7/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 7
Onceadefaultbearer isestablished (withorwithout IPaddressassignment), theUE canperform
DHCPorIPv6StatelessAddressAutoconfiguration(SLAAC)toobtainanIPaddress.Thus,forexample,
aUEcouldobtainanIPv4addressaspartoftheattachmentprocedureandanIPv6addressthrough
anadditionalIPv6SLAACprocedure.
2.1.3
EVOLVINGPACKET
CORE
TO
EPC
AND
IPV6
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
WhenaUE,afterattaching throughanLTE radio link,movesoutof the reachofLTEeNBs, itmay
havetofallbacktoUMTS.ThehandovertoUMTSisorchestratedbytheMME,whichinterfaceswith
thetargetSGSN.ThePDPContextisroutedviatheSGSNtotheSGWtowhichtheUEwaspreviously
connected.
If theUE isadualstackdevicewith its IPv4and IPv6stacksimultaneouslyactive,ahandovermay
haveimpactonitsoperations.IftheUEishandedovertoanR8compliantUMTSnetwork,thereare
noconsequences,astheR8PDPContextcancarryboth IPv4and IPv6traffic.However, iftheUE is
handedover to anR7compliantUMTSnetwork (which is themore likely scenario), thisdoesnot
work,sinceanR7PDPContextcarrieseitherIPv4trafficorIPv6traffic,butnotboth.
3GPPstandards
specify
aone
to
one
mapping
between
EPS
bearers
and
PDP
contexts.
This
implies
thatanoperatoreitherneedstoupgradeallSGSNs(connectedtotheEPC)toRel8,ordisabledual
stackoperationovertheEPSnetwork.Inthe lattercase,aUEthatrequestsdualstackoperationat
attachment to the EPS network will only receive a singlestack bearer, say for IPv4, and it will
subsequentlyneedtoinitiateasecondbearerestablishmenttowardsthesameAPNforIPv6.
8/8/2019 3G Americas IPv6 LTE
8/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 8
3. VOICECORENETWORKVoicetelephonyservicesina3GPPnetworkaretraditionallyprovidedbyaMobileservicesSwitching
Centre(andsupportinginfrastructure)and/oranIPMultimediaSystem.
Asthe
name
implies,
IP
Multimedia
Subsystems
(IMS)
rely
heavily
on
IP
protocol.
Per
3GPPP
standards,IMSequipmentshouldbedeployedusingIPv6therebyavoidingtheneedforafutureIPv4
toIPV6migration.
WhereasnewIMSequipmentwilltypicallybedeployedwithIPv6,existingvoicecoreequipmentwill
stillbeutilizing IPv4. Since theMSC is at theheartof 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 IP ADDRESSUSAGE IN THE DISTRIBUTED MSC
The Mobileservices Switching Centre (MSC) performs all CS domain switching and signalling
functionsforGSMandUMTSmobilestations located inaspecificgeographicalarea. TheMSCcan
beimplementedinanintegratedplatformorintwodistinctphysicalentities.
WhendividedintotwophysicalentitiestheMSCconsistsofanMSCServer,handlingonlysignalling,
andaMGW,handlinguserdata. Thisarchitectureofdividing the signalling server from thedata
planeissometimesreferredtoasadistributedMSC.
Figure4. GSM/UMTSVoiceCorewithaDistributedMSC
STP HLR
NodeB
BTS
BSC
BTSBaseTransceiverStation
BSCBaseStationController
HLRHomeLocationRegister
MSCMobileSwitchingCentre
MSCSMSCServer
Distributed MSC
MSCS
MGW
TCUBTS
RNC
MSCS
Distributed MSC
MGW
NodeB
SIGTRANorSS7
Network
Mc
(H.248)
SIP-I or
Nc
Iu-CSMc
(H.248)
A Interface
8/8/2019 3G Americas IPv6 LTE
9/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 9
Dependentonthevendor implementation,thedistributedMSCmaybeenhancedtofunction inan
IMS environment as a Telephony Application Server (TAS), MGCF/IMMGW, IMSSF, MRF, MSC
enhancedforICS,MSCenhancedforSRVCCetc.,ormaybeextendedtoserviceSIPuserequipment
directly.
Forinterconnect,
adistributed
MSC
will
typically
utilize
amix
of
packet
or
cell
based
protocols
including IP and/or ATM. Since IP interfaces in a distributedMSC environment are generally a
supersetofanintegratedMSC,thispaperassumesadistributedMSCasthereferencepoint.
EveryinstanceofanIPaddressmustbeconsideredwhenmigratingfromIPv4toIPv6oroperatingin
a dualstack environment. The following subsections identifywhere IP addresses are typically
utilizedwithinthedistributedMSC.
3.1.1 MSC TO SS7 NETWORK SIGTRAN
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
telephonymessages,suchasMediaGatewaycontrolandSS7messages, tobe 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@)
IP
L1
Figure5.
SIGTRAN
8/8/2019 3G Americas IPv6 LTE
10/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 10
3.1.1.1 SCTP
TomeettheperformancerequirementsofatelephonynetworkinanIPenvironment,SIGTRANuses
theSCTPprotocoldefined inRFC3257. SCTP isaconnectionorientedprotocolthatoffersmultiple
servicesincluding:Multihoming,Multistreaming,Heartbeat,amongothers.
Whenmigrating from IPv4to IPv6,ofparticularnote isSCTPsmultihomingservice. Multihoming
allowsanassociationtosupportmultiple IPaddressesatagivenendpoint. Theuseofmorethan
one IPaddressatanendpoint increasesnetworkrobustnessbyprovidinganalternatepathforre
transmissionsorallowingreroutingofpacketsduringfailurescenarios.
AspartofSCTPsmultihomingservice,SCTPcontrolpacketscarryembeddedIPaddressesduringthe
connectionsetupprocess. ThisallowstheendpointstoexchangeIPaddresslists.
Although SCTPsmultihoming service canprovide increasednetwork resiliency, the embedded IP
addresses exchanged during connection setup complicate the use of aNATPT and the potential
interworking
between
IPv4
and
IPv6
network
elements.
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
viceversausingaRoutingKey. However,M3UAdoesnotexchange IPaddress informationwithin
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
8/8/2019 3G Americas IPv6 LTE
11/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 11
CLDT (Connectionless Data Transfer), CLDR (Connectionless Data Response), Connection Request
(CORE),ConnectionRefused (COREF),andCOAK (ConnectionAcknowledge)mayembed IPaddress
informationasaparameter.
3.1.2 MSC SERVER TOMEDIA GATEWAYMC INTERFACE
InadistributedMSCenvironment,theMSCServerusesH.248ontheMcinterfacetocontrolaMedia
Gateway. Whenplanningamigration from IPv4to IPv6ontheMc interface,aminimumofthree
layersmustbeconsidered: thenetwork/transportlayer,theSCTPlayer,andtheH.248layer.
3.1.2.1 NETWORK/TRANSPORTLAYER
Atthenetwork/transportlayer,the3GPPstandardsallowforthefollowingMcinterfaceoptions:
1.) AmixedIP&ATMconnectionH.248/M3UA/SCTP/IP/AAL5/ATMasanexample
2.)
Apure
IP
connection
H.248/M3UA/SCTP/IP
with
M3UA
as
an
optional
layer.
3.) ApureATMconnection H.248/MTP3b/SSCF/SSCOP/AAL5/ATM
ThefirsttwointerfaceoptionsbothutilizeIPandmustbeconsideredwhenmigratingfromIPv4and
IPv6. ThethirdoptioninvolvesnoIPaddressingandisthereforeexcludedfromthispaper.
In the first twooptions, theMc interface IP connectionsmaybeeither IPv4or IPv6.Thediagram
belowprovidesaprotocol stack for theMc interface in thepure IPconnectionandmixed IP&
ATMconnectioncases. NotethattheM3UAlayerisanoptionallayerinthepureIPcase. [3GPP
TS29.232V4.17.0(200706)page11].
H.248(embeddedIP@)
M3UA (optionallayer)
SCTP(embeddedIP@)
IP
L1
Figure6.
8/8/2019 3G Americas IPv6 LTE
12/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 12
3.1.2.2 SCTPANDM3UA
TheMc interfaceuses the SCTPprotocol andmayoptionallyuse theM3UA layer asdiscussed in
section6.1.1. TheSCTP layerembeds IPaddressesduringconnectionsetupwhichcomplicatesthe
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, theMSC serverwill send anH.248 Add
requesttothelocalMGWtocreateacontext. ThelocalMGWrespondstotheMSCserverwithan
H.248 Replymessage. Inside the Replymessage is the local descriptorwhich contains the local
MGWsbearer IPaddress. The localdescriptormakestheMSCserverawareofthe IPtermination
pointforwhichitmustdirecttheincomingIPmediastream.
Similarly, the remoteMGWprovides itsbearer IPaddress to its controllingMSC serverwithin 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.37allowstheMSCServerto instructaMGWto latchtoanaddressprovidedbyan incoming
InternetProtocol (IP)applicationdata stream rather than theaddressprovidedby the call/bearer
control.This
enables
the
MGW
to
open
apinhole
for
data
flow.
It
also
allows
the
MGW
to
ignore
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, theMGWwilluse the source address and
sourceport from the incomingmedia stream (i.e., from theother termination)as thedestination
addressanddestinationportoftheoutgoingapplicationdata.
8/8/2019 3G Americas IPv6 LTE
13/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 13
Ignoring theRemoteDescriptor IPaddresses in theH.248messaging,makes IPaddress translation
within thenetwork transparent tobasicMGWoperations. Thus,H.248.37couldbeused toallow
interworkingofanIPv4MGWwithanIPv6MGW,allowtwoIPv4MGWstocommunicateacrossan
IPv6backbone,and/orhelpfacilitateanIPv4toIPv6migration.Still,H.248.37hasaseriouslimitation
asdiscussedbelow.
H.248.37assumes that themedia streamhas alreadybeen establishedandVoIP traffic is already
flowingbetweenMGWs. ForH.248.37andNATPTtobeeffectiveinallowinginterworkingofIPv4to
IPv6capableMGWs,themediastreammustfirstbeestablishedwithan IPaddressprovided inthe
H.248messaging. This implies thateither the call server includesanApplication LevelGateway
ControlFunction(ALGCF)tocontroladynamicNAT[6],oritimpliesthatstaticaddresstranslationis
usedbetweentheMGWs.
3.1.3 MSC TO RNC FOR UMTS ACCESSSUPPORT IUCS INTERFACE
The
UMTS
access
network
is
connected
to
the
MSC
via
the
Iu
CS
interface.
Standards
allow
for
Iu
CS
tobetransportedoverATMorIP.Witheithertransportoption,IuCSoverIPorIuCSoverATM,the
IuCSinterfacecanbelogicallydividedintothreeareas:
1. ControlPlane
2. BearerControlPlane
3. Bearer(orUser)Plane
3.1.3.1 IU CS CONTROL PLANE
TheIuCScontrolplanecarriesRANAPsignalingbetweentheUTRANandMSCS.
8/8/2019 3G Americas IPv6 LTE
14/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 14
3.1.3.2 IU CS OVERIP
For the IuCSover IP controlplane, three layersmustbe consideredwhenmigrating from IPv4 to
IPv6:the
network/transport
layer,
the
SCTP
layer,
and
the
RANAP
layer.
Notice
the
protocol
stack
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
duringconnection
setup
[8].
IntheRANAPlayer,transportlayerIPaddressareexchangedbetweentheRNCandMGWusingthe
Prepare_IP_Transportprocedure.
InthePrepare_IP_Transportprocedure,theMSCserverrequeststheMGWtoprovide IPTransport
AddressandanIuUDPPortandprovidestheMGWwiththebearercharacteristics.AftertheMGW
has repliedwith the IPaddressandUDPPort, theMSC server requestsaccessbearerassignment
usingtheprovidedIPaddressandUDPPortinaccordancewith3GPPTS25.413.
TheIPaddressesandUDPPortsoftheMGWandtheRNCareexchangedviatheRANAPprocedures.
Ifthe
bearer
transport
is
IP
and
IuUP
mode
is
Transparent,
when
the
MSC
receives
the
RANAP
RAB
assignment response it sends the RNC IP address and UDP Port to the MGW Access bearer
terminationusingtheModify_IP_Transport_Addressprocedure.
IfthebearertransportisIPandIuUPmodeisSupport,theMGWusesthesourceIPaddressandUDP
Portof the IuUP Initpacket received from theradioaccessnetworkasthedestinationaddress for
subsequentdownlinkpackets. TheRNC isalreadyawareof theMGW IPaddressbecause theCall
ServerprovidestheRNCtheMediaGatewaysIPaddressintheRABAssignmentRequestmessage.
8/8/2019 3G Americas IPv6 LTE
15/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 15
3.1.3.3 IU CS OVERATM
IntheIuCSoverATMconfiguration,thecontrolplaneusesbroadbandSS7signalingwhichdoesnot
requireIP.
It
should
be
noted
however
that
some
vendors,
in
particular
those
who
have
an
all
IP
MSC
server,
mayconvertM3UA/IPtobroadbandSS7inaSignalingGateway(SGW)orMGW. Becausethistypeof
implementation isvendor specific, IPv4 to IPv6migrationconcerns shouldbeworkeddirectlywith
thevendorfortheIuCSoverATMinterface.
3.1.3.4 IU CS BEARER CONTROLPLANE
ThebearercontrolplaneisonlyapplicableforIuCSoverATM,anddoesnotneedtobeconsidered
whenplanninganIPv4toIPv6migration.
3.1.3.5
IU
CS
BEARER
(OR
USER)
PLANE
TheIuCSbearercanutilizeATMorIPatthetransportlayer. InanATMconfiguration,thebeareris
transportedoverAAL2virtualcircuitconnections. Inan IPconfiguration,bearer istransportedover
RTP/UDP/IP[9].
AprotocolstackoftheIuCSBearerusingIPtransportisprovidedbelow.
RTP
UDP
IP
DataLinkLayer(e.g.GigE)
PhysicalLayer
Figure8.
MSCtoTCU/BSCforGSMAccesssupportAInterface
At the timeof thewritingof thisdocument, standards forAinterfaceover IP standardswere still
beingdevelopedby3GPP. Previously,theA interfaceimplementationdidnotutilizeorsupportIP.
AInterfaceisthereforeexcludedfromthispaper.
8/8/2019 3G Americas IPv6 LTE
16/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 16
3.1.4 MSC TO MSC INTERFACES
3.1.4.1 BICCARCHITECTURE
Bearer Independent Call Control (BICC) is a signaling protocol used to support narrowband ISDN
serviceindependent
of
the
bearer
technology
and
signaling
message
transport
technology
used.
BICCwasdeveloped tobe interoperablewithany typeofbearer, suchasATM, IP,andTDM.The
followingsectionfocusesonBICCwhenusedinanIPnetwork.
ThreeinterfacesaredefinedinaBICCarchitecture:
NbMGWtoMGW
Mc (G)MSCServertoMGW
Nc MSCServerto(G)MSCServer
3.1.4.2 NB INTERFACE
TheNb interfacetransportsbearer informationbetweenMGWs.The3GPPstandardssupportTDM,
IP,andATMtransportontheNbinterface. TheprotocolstackoftheNbinterfaceusingIPtransport
isprovidedbelow:
G.711 UMTSAMR/AMR2
NbUP[29.415]
RTP[RFC3550]
UDP[RFC768]
IP
L1
Figure9.
8/8/2019 3G Americas IPv6 LTE
17/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 17
3.1.4.3 TUNNELING ACROSSTHEMC ANDNC INTERFACES
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 IPnetworks, the IP bearer control isnot carrieddirectly betweenMGWs alongside the bearer
traffic.Nbbearercontrol istunneledbetweenMGWsvia theMcandNc interfacesusing IPBCP (IP
BearerControlProtocolQ.1970). ThefigurebelowillustratesthepathforIPBCP.
Figure10.
IPBCP protocol allows the establishment and modification of IP bearers on theMGWs. IPBCP
exchangesmediacharacteristicssuchasportnumbersand IPaddressesofthesourceandsinkofa
mediastream.Theexchangeof informationwith IPBCP isdoneduringBICCcallestablishmentand
afteracall
has
been
established.
IPBCP
uses
asubset
of
the
Session
Description
Protocol
(SDP)
definedin3GPP29.414toencodetheinformation.
Although the transport layers for theMc andNc interfacesmay consistof variousprotocols, the
figurebelowprovidestheprotocolstackforIPBCPwhenIPisthetransporttype.
MGW
Nb
MSCMSC
MGW
McMc
Nc
IPBCP
8/8/2019 3G Americas IPv6 LTE
18/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 18
IPBCP(embeddedIP@)
BCTP[Q.1990]
BICC
IP
L1
Figure11.
3.1.5 SIP I
SIPIisanextensionoftheSIPprotocol. SIPIisusedtotransportISUPmessagesacrossaSIPnetwork
asattachmentstotheSIPmessages.
SimilartoBICC,SIPIprovidesamechanismbywhichtwoMSCscanbeconnectedoveranIPnetwork.
ThoughBICCwas the firstprotocolstandardizedby3GPP for interMSCVoiceover IPconnectivity,
BICCislimitedtooperationinaGSM/UMTSenvironment. Thus,manyoperatorshaveoptedtouse
SIPIforMSCinterconnect.
To exchange media stream information between MGWs, SIPI utilizes the Session Description
Protocol(SDP).
3.2 MIGRATING THE VOICE CORE FROMIPV4 ANDIPV6
Asdescribed in thepreceding section,migrationof the voice core from IPv4 to IPv6 isa complex
activityrequiringconsiderationofnumerousprotocolsandlayersabovetheIPnetworklayer.
Oneoftheprimarydriversforamigrationfrom IPv4toIPv6 istoalleviateIPaddressconsumption.
SincethemajorityofIPaddressesareconsumedbyenduserdevices,andafullmigrationofthevoice
corefromIPv4toIPv6ishighlycomplex,inmostcasesitwillnotbefeasibletomigrateanoperators
entire3GPPvoicecore to IPv6. Instead, it ismuchmoreprobablethatamigrationof IPv4to IPv6
withinthe
voice
core
will
only
be
targeted
at
specific
interfaces.
Forexample,anoperatormayopttoleaveallIuCS/IPandintracallserverMGWtoMGWtrafficas
IPv4whilemakingall intercall serverMGW toMGW traffic IPv6.This typeofarchitecturewould
allow thenetworkoperator toonly requiredual stack capableMGWson thenetworkbound (vs.
access)interfacesandwouldavoidtheneedforanIPv6capableRNC.
8/8/2019 3G Americas IPv6 LTE
19/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 19
4. IMPACT OF THEINTRODUCTION OF IPV6 ONSECURITY IN UMTS IPv6currentlyhas relatively limiteddeployments, thus fewvulnerabilitieshavebeenexploited. As
adoptionexpands,likeinIPv4,attacksontheprotocolwillemergeunlesssufficientlyprotected. IPv6
security issueshave implicationsdirectly for the IP layer,and indirectly forapplicationsupportand
thelink
layer.
And
these
security
issues
can
be
examined
with
respect
to
end
to
end
security,
end
togatewayandgatewaytogatewayconnections. TheimplementationofIPv6requiresextensionsto
theexistingsecuritypolicyaswellas introducingnewsecuritypoliciesspecifictoIPv6. Thesecurity
concerns (threatsandvulnerabilities)andspecific solutionscomprise those issuescommon to IPv4
andIPv6,thosesecurityissuesspecifictothetransitiontoIPv6,andthosespecifictoIPv6. IPv6must
bemanagedtoprovideanequivalentlevelofsecurityasisprovidedforIPv4.
Thefollowingsubsectionprovidesaconcisesummaryofsecurity issuesrelatedtoIPv6. Sections0
and0provideanoverviewofhowtheseissuesimpactordonotimpact3GPPandLTE.
4.1
IPV6SECURITY
ISSUES
OVERVIEW
4.1.1 SECURITYISSUES COMMON TO IPV4AND IPV6
ManysecurityissuesandsolutionscommoninIPv4implementationsprojectforwardintoIPv6.
FirewallsarerequiredtobeupdatedtosupportfirewallrulesspecifictoIPv6,aswellasupdatesfor
SSH(SecureShellprotocolforremotelogin/filetransfer).
IPsec,AH (authenticationheader)andESP (encapsulatingsecuritypayload) functionessentially the
sameforbothIPv4andIPv6. IPseccanbeusedtosupporttheroutingprotocols,RoutingInformation
Protocol(RIP)
&
Open
Shortest
Path
First
(OSPFv3),
ifrequired.
The
Virtual
Private
Network
(VPN)
model inusemustbeupdated toadd IPv6 support. The IPv6 configuration in IKEv2 is stillbeing
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. NAT isoftenusedtoperformthetasksofafirewallbyestablishingdynamicstatefor
connections to protect againstunauthorized, ingress traffic, and also to perform topology hiding.
NATshouldnotbeusedasasubstituteforafirewall. NATisnotinvulnerableandoncecompromised
itiseasyforattackerstoscantheprivateaddressspaceontheinsideoftheNATforopenports. It
8/8/2019 3G Americas IPv6 LTE
20/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 20
shouldalsobenotedthatNATcomplicatestheuseofIPsecforendtoendencryption. Forexample,
thereisadditionaloverheadrequiredtosupportUDPencapsulationandNATkeepalivemessaging.
IPv6providesseveralmechanismstosupporttopologyhiding. ThesizeofasingleIPv6subnetmakes
ping sweepsandport scanning fornetworkvulnerabilitiesunprofitable. Simplyassigningmultiple
IPv6addresses
to
ahost,
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
Addressingcanbeusedforaddressallocationwithinasite thistrafficisforcommunicationwithina
siteandshouldneverberoutedoutsidetheinternalnetwork. UntraceableIPv6addressing(random
prefixallocationwithina subnet)canbeused toconceal thesizeand topologyof thenetwork,as
opposed tosequentialnumberingwithina subnet,commonlyemployed in IPv4due to the limited
numberofavailableaddresses.
RefertoLocalNetworkProtectionforIPv6(RFC4864),foramorecompleteunderstanding.
4.1.2
SECURITY
ISSUES
INVOLVED
IN
TRANSITION
TO
IPV6
TheintroductionofIPv6hasimpactsonsecurityrelatingtothetransitionmechanismsofdualstack,
tunneling,andtranslation.
Dualstack
Active IPv4onlynetworksmayalreadybevulnerable to IPv6attacks if IPv6capabledevices (dual
stack) are included. The security policy should determinewhether IPv6 packets in the IPv4only
network should be blocked as IPinIP packets (41 in protocol field of IPv4 header) thatmay 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 thatareconstructedusing IPinIP,as6in4 staticor6to4automatic tunneling,cannot
traverse a NAT when port translation is required (NAPT). Many of the automatic tunneling
mechanisms,as
6to4,
ISATAP
and
Teredo,
use
embedded
IPv4
addresses
within
the
128
bits
of
the
IPv6address.
Dependinguponthetunnelingmechanismsemployed,filteringmayberequiredatfirewallstoblock
IPinIP or IPv6 addresseswith embedded IPv4 addresses. Embedded addressingmay introduce
vulnerabilitiesthatareabletotraversefirewalls.
8/8/2019 3G Americas IPv6 LTE
21/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 21
Refer to IPv6OperationsandSoftwires IETFworkinggroups foradditionalRFCsanddraftson IPv6
securitymechanismsrelatedtotunneling,www.ietf.org.
Translation
Referto IETFdraft,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 SECURITYISSUES SPECIFICTO IPV6
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 IPv6are required to supportpolicy for ICMPv6and IPv6extensionheaders:
which
ICMP
messages
to
allow
or
deny,
e.g.,
Packet
Too
Large
for
PMTU,
which
extension
headers
to
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
assistanIPv6node inconstructinganIPv6address. Newvulnerabilitiesare introduced ifthelink is
compromised. NA/NS and RA/RS can be protected using a linklevel securitymechanism, as, for
example,theSecureNeighborProtocol(SEND)andCryptographicallyGeneratedAddresses(CGA)to
determinewhethera routeron the link isa trusted router. However,deploymentofCGAmaybe
limiteddue to IntellectualPropertyRights issuesand some technical concerns. Refer to the IETF
workinggroup,Cga&Sendmaintenance(csi)forcurrentstatus.
Certain IPv6addresses shouldbe filteredat the firewall, forexample: IPv6 loopback, IPv4mapped
address, unique local address, site local address, certain multicast addresses. The IPv6 use of
multicastaddressing introduces thepotential fornewvulnerabilities. Certainresources internal to
the network are identifiable bymulticast addressing. These addresses should be filtered at the
8/8/2019 3G Americas IPv6 LTE
22/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 22
networkboundary,dependingupon their scope. Theseaddressesalso introduce thepotential for
DoS attacks. Also, IPv6 anycast addresses, such asMobile IPv6Home Agent anycast or Subnet
Routeranycast,canpotentiallybeusedinDoSattacks.
IPsec support is builtin to IPv6, which will allow for more instances of endtoend encryption,
consistentwith
the
design
of
IPv6
to
move
more
of
the
responsibility
for
the
session
to
the
end
users.
However,enduserencryptionmakesexecutionofIDSmoredifficult. Ingeneral,consistentwiththe
designofIPv6,somelevelofsecuritymaybemoveddowntotheendnodes,eitherforencryptionor
attheapplicationlevel. Securitymaybetransitionedfromaperimetermodeltoadistributedmodel.
PerformanceconsiderationsofIPv6securitymechanismsmustbebalancedagainstrisk.
MIPv6
Severalsecurityissues/mechanismsareintroducedwithMIPv6.
IPseccanbeusedtosecurecommunicationbetweenthemobilenodeandthehomeagent. Asan
alternative to IPsec,securingofbindingupdatesandbindingacknowledgementscanbeperformed
usingMIPv6signalingmessagingbetweentheMobileNode(MN)andtheHomeAgent(HA). Referto
RFC4285.
InMIPv6,packet lossdue toegress filteringat theaccess router ispreventedbyplacing the IPv6
mobilenodescareofaddressintheexternalIPheaderwheninaforeignnetwork.
DynamicHomeAgentAddressDiscovery reliesupon special ICMPmessaging,which is required to
passthroughthenetworkfirewalls.
Routeoptimizationallows themobilenode and the correspondentnode to communicatedirectly
(ratherthanviathehomeagent),withoutprearrangedsecurityassociations. Additionalmessaging
isrequiredtoperformreturnroutabilityforrouteoptimization. Inrouteoptimization,amobilenode
reveals its careofaddress (currentpointof attachment) to the correspondentnode. The careof
addresscanbetraceabletoaparticularlocation. Itisaconcernthatamobileuserslocationcanbe
compromisedwhenrouteoptimizationisused.
HierarchicalMIPv6canbeusedtomitigatelocationprivacyissueswithrouteoptimization.
IssueswithMobileIPv6securityhaveconsiderableimplicationsforendusersandthenetwork,andis
toolargeatopictoduejusticetohere. RefertotheIETFMobilityEXTensionsforIPv6(mext)working
grouprelated
RFCs
for
additional
information.
8/8/2019 3G Americas IPv6 LTE
23/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 23
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
productswhich
all
have
varying
levels
of
support
for
IPv6.
The
Status
of
commercial
firewalls,
IDS
andIPStosupportIPv6isnotmature. RefertoNationalInstituteofStandardsandTechnology(NIST)
report,FirewallDesignConsiderationsforIPv6.
4.2 OVERVIEW OFUMTS SECURITY ANDIPV6
4.2.1 IPV6IMPACTSTO UMTSENDUSER SECURITY
InPacketDateProtocol(PDP)ContextactivationusingIPv6statelessaddressautoconfiguration,the
GatewayGPRSSupportNode (GGSN)assignsbothan IPv6 Interface Identifierand/64prefixtothe
MobileStation(MS). Theprefixisuniquewithinitsscope. TheGGSNandMSaretheonlynodeson
the local link, thusDuplicateAddressDetection is not required. TheMS is authenticated by the
network and the PDP Context is tunneledwithin the network. The need for additional security
measures,suchasSENDandCGAarenotrequiredforthePDPContextwithinthe3GPPnetwork.
TheGGSNactsasananchorforthePDPContext,eliminatingtheneedforMIPv6,priortorelease8
(LTE).
3GPPsupportsIPv6privacyextensionsforthePDPAddress. ThePDPContextisidentifiedbytheIPv6
prefixat
the
Serving
GPRS
Support
Node
(SGSN)
and
GGSN
and
not
by
the
full
128
bit
PDP
Address.
ForIMS,theGGSNprovidestheaddressofthePCSCFtotheMSforProxyDiscovery. TheMS,GGSN
and PCSCFmust support the same IP version. TheMS 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 IPV6IMPACTSTO UMTSPACKETNETWORK SECURITY
SecurityprotectionisspecifiedforGTPcontroltraffic. Protectionofusertrafficisconsideredoutside
thescopeofthestandards.
TS32.210describestheminimumsecurityfeaturesinsupportofdataintegrity,originauthentication,
antireplay protection, and confidentiality. 3GPP Network Domain Security provides hopbyhop
protection,whichallowsforseparatesecuritypoliciesdependinguponwhetheralinkisintradomain
8/8/2019 3G Americas IPv6 LTE
24/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 24
or interdomain and whether between trusted or untrusted domains. Security Gateways are
stationedatthenetworkboundary alltrafficbetweensecuritydomains isviaaSecurityGateway.
Authentication and integrity protection are mandatory between two security domains and
encryptionusingESP intunnelmode isoptional. ProtectionoftrafficwithintheSecurityDomain is
optional.
Firewallsatnetworkboundariesarerequiredtoprotectagainstunauthorizedtraffic.
TheIMSnetworktopologycanbehiddenbyencryptingtheIMSnetworkelementIPaddressesinSIP
messages.
RefertoTS33.102,33.203,33.210and33.310fordetailsofNetworkDomainSecurityandTS33.234
forWLANinterworkingsecurity.
4.3 IPV6 IMPACTSON LTESECURITY IMPLEMENTATION
TheLTE
specification
supports
aflat
IP
network
based
upon
TCP/IP
protocols.
General
security
and
enduserprivacyprinciplesfortheEPSarespecified inTS22.278. LTEspecificsecurityisdetailedin
TS33.203,33.401,33,402and33.178.
TheLTEUEsupportsdualstack,whichmayusesimultaneous IPv4and IPv6addresses,overanEPS
Bearer(MIPbetweenSGWandPGW)orPDPContext(GTPtunneling).
LTE supports interworking between 3GPP EPS and UTRAN, WLAN, CDMA, WIMAX and GERAN.
Securehandover is supportedbetweenEPS andnonEPSaccessnetworks. This incursadditional
complexitywithrespecttosecuritytosupportmobility,keytransferandalgorithmnegotiation,DS
MIPv6orPMIPv6,andsupportforIPv4privateaddressing.
4.4 IPV6 SECURITY RECOMMENDATIONS
ItisobviousbutsignificanttostresstheimportanceoftrainingandplanningfortheadoptionofIPv6
with respect to security. Oncea securitypolicy isestablished, it isnecessary to stay currentand
vigilant with security vulnerabilities and with IPv6specific updates and vulnerabilities, as IPv6
continuestobeadopted.
Notallsecuritysupport isequal knowthecapabilities/limitationsofhostsandrouters innetwork:
IPv6stacksupport,privacyextensions,IPsec,andfilteringcapabilities.
Determineabalanceacrossrisk,overheadandperformanceofsecuritymechanisms.
8/8/2019 3G Americas IPv6 LTE
25/26
3GAmericas IPv6LTEandEvolvedPacketCoreFebruary2009 25
5. CONCLUSIONS ThegrowthofalwaysonalwaysreachableservicesandthedepletionofIPv4addressesaretwokey
driversmovingcarrierstoconsidertransitioningtoIPv6. IPv4willcoexistwithIPv6forseveralyears;
therefore,transitionmechanismsandcoexistencetechniqueswillbeusedasthecarrierstransition
toIPv6.
CarriersevolvingtheirnetworkstoLTEshouldconsidermakingIPv6arequirementfromday1. Since
LTEEPCdoesnotsupportaCircuitSwitchedCoreaspartofthe3GPPstandard,nativesupport for
voicewillbesupportedby the IMScore. Becausethe transition to IMSbasedVoIPwill likely take
severalyears,itiscriticalforthecarrierstounderstandtheimpactsofIPv6ontheexistingVoiceCore
and signaling infrastructure. Lastly, it is absolutely critical that the transition to IPv6 consider
networksecurity.
6. ACKNOWLEDGEMENTS Themissionof3GAmericas is topromoteand facilitate the seamlessdeployment 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.
Wewould like to recognize the significantproject leadershipand important contributionsof Paul
SmithofAT&Taswellastheothermembercompaniesfrom3GAmericasBoardofGovernorswho
participatedin
the
development
of
this
white
paper.
7. REFERENCES[1] GPRSenhancementsforEUTRANaccess(Release8);3GPPTS23.401;inprogress
[2] ArchitectureEnhancementsfornon3GPPaccesses(Release8);3GPPTS23.402;inprogress
[3] EvolvedUniversalTerrestrialRadioAccess(EUTRA)andEvolvedUniversalTerrestrialRadio
AccessNetwork
(E
UTRAN),
3GPP
TS
36.300;
in
progress
[4] TransitioningtoIPv6;3GAmericas;February2008
8/8/2019 3G Americas IPv6 LTE
26/26
8. GLOSSARY
AAA Authentication,AuthorizationandAccounting
ALG ApplicationLevelGateway
APN AccessPointName
CDR CallDetailRecord
DAD DuplicateAddressDetection
DHCP DynamicHostConfigurationProtocol
DNS DomainNameServer
EMS ElementManagementSystem
GGSN GatewayGPRSSupportNode
GPRS GeneralPacketRadioService
GTP GPRSTunnelingProtocol
HSS
HomeSubscriber
Server
HTTP HyperTextTransferProtocol
IANA InternetAssignedNumberAuthority
ICE InteractiveConnectivityEstablishment
IMS IPMultimediaSubsystem
ICID IMSChargingIdentity
NAT NetworkAddressTranslation
NOC NetworkOperationCenter
PCRF PolicyandChargingRulesFunction
PCSCF ProxyCallSessionControlFunction
PDP PacketDataProtocol
QoS
Qualityof
Service
RAB RadioAccessBearer
RAN RadioAccessNetwork
RIM ResearchinMotion
RIR RegionalInternetRegistry
RNC RadioNetworkController
RTCP RealTimeControlProtocol
RTP RealTimeProtocol
SCSCF ServingCallSessionControlFunction
SDP SessionDescriptionProtocol
SLAAC StatelessAddressAutoConfiguration
SIP SessionInitiationProtocol
SGSN ServingGPRSSupportNode
UE UserEquipment
UMTS UniversalMobileTelecommunicationsSystem
URI UniversalResourceIdentifier
VPN VirtualPrivateNetwork