Internet DRAFT - draft-ietf-v6ops-3gpp-ipv6use
draft-ietf-v6ops-3gpp-ipv6use
IPv6 Operations Working Group
Internet Draft J.P. Yoo
Document: draft-ietf-v6ops-3gpp-ipv6use-00.txt K. C. Kim
Konkuk University
J.P. Hong
HUFS
K. J. Lee
Hyoung-Jun Kim
ETRI
Expires: May 2002 October 2003
IPv6 in 3GPP networks satisfying IETF's recommendations
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Abstract
3GPP PS (Packet Switched) domain Standard states the usage of IPv6 as
its network protocol to compensate the shortage of Internet address
and to use the enhanced network protocol functions. In case of the
current IPv6 usage in 3GPP packet domain standards, they have unique
IPv6 address allocation scheme which is somewhat different from the
one of IETF due to its 3G equipments and packet network elements.
Meanwhile, IETF presents " recommendations to 3GPP networks (RFC3314
[2])" to satisfy compatibility between IETF IPv6 and IPv6 of 3GPP
networks and to lift up the IPv6 capabilities. In this situation,
this document provides a new IPv6 address allocation scheme in 3GPP
networks satisfying IETF' recommendations. Provided scheme keeps
rules of recommendations of IETF standards and guarantees backward
compatibility with the legacy 3GPP IPv6 autoconfiguration.
Conventions used in this document
<Lastname> Expires - May 2003-10-17 [Page 1]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [ii].
Table of Contents
1. Introduction...................................................2
1.1 Terminology................................................2
1.2 3GPP network architecture..................................3
2. IPv6 in 3GPP and IETF Recommendations..........................3
2.1 3GPP IPv6 Address Allocation Scheme........................3
2.2 IETF Recommendation for 3GPP IPv6 Address Allocation.......5
3. IPv6 in 3GPP networks satisfying IETFÆs Recommendations........5
3.1 Address allocation procedures..............................5
3.2 Network elements actions...................................7
3.3 Autoconfiguration steps for Backward compatibility.........8
4. Security Considerations.......................................10
5. References....................................................10
Author's Addresses...............................................10
1. Introduction
Currently, 3GPP networks optionally use IPv6 and IETF IPv6 working
group helps 3GPP networks for the efficient protocol usage. In
addition, IPv6 working group gives advices to 3GPP networks for
protocol compatibility. As a result, IETF RFC standard (RFC 3314) was
provided to recommend the correct usage of IPv6 to 3GPP networks. In
this situation, this draft document provides an IPv6 usage scheme for
3GPP networks. This document has the following contents.
1. Introduction to this documents and terminology.
2. 3GPP IPv6 address allocation scheme and recommendations of
IETF to 3GPP networks.
3. IPv6 usage in IPv6 in 3GPP networks satisfying IETF's
recommendations.
1.1 Terminology
GGSN Gateway GPRS Support Node. A router between the GPRS
network and an external network (i.e., the Internet).
GPRS General Packet Radio Services
GTP-U General Tunneling Protocol - User Plane
<Yoo> Expires - May 2003-10-17 [Page 2]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
GSN GPRS support Node (GGSN, SGSN)
IMSI International Mobile Subscriber Identity. A unique
15-digit number which designates the subscriber. This
number is used for provisioning in network elements.
MT Mobile Termination. For example, a mobile phone
handset.
MS Mobile Station. (MT + TE)
PDP Packet Data Protocol
PDP Context A PDP connection between the UE and the GGSN.
PS Packet Switched
SGSN Serving GPRS Support Node
TE Terminal Equipment. For example, a laptop attached
through a 3GPP handset.
UE User Equipment (TE + MT + USIM). An example would be
a mobile handset with a USIM card inserted and a
laptop attached.
UMTS Universal Mobile Telecommunications System
USIM Universal Subscriber Identity Module. Typically, a
card that is inserted into a mobile phone handset.
UTRAN Universal Terrestrial Radio Access Network
1.2 3GPP network architecture
We recommend to refer to IETF documents and 3GPP documents(RFC3314,
TS 23.060[3])in order to understand 3GPP basic network architecture
2. IPv6 in 3GPP and IETF Recommendations
2.1 3GPP IPv6 Address Allocation Scheme
3GPP address allocation steps are composed of two phases. In the
first phase, MS gets its interface identification from GGSN. That is
why 3GPP equipments can't make an unique identification. In this
<Yoo> Expires - May 2003-10-17 [Page 3]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
phase, 3GPP PDP context setup procedure is used. In the second phase,
MS gets IPv6 network prefix that is required for global address from
GGSN. In this phase, RS (Router Solicitation) and RA (Router
advertisement) messages are required.
3GPP address autoconfiguration has the following steps:
1. The Activate PDP Context message is sent to the SGSN (PDP
Type=IPv6, PDP Address = 0, etc.).
2. The SGSN sends a Create PDP Context message to the GGSN with
the above parameters.
3. GGSN chooses an interface identifier for the PDP Context and
creates the link-local address. It answers the SGSN with a
Create PDP Context response (PDP Address = link-local
Address).
4. SGSN sends an Activate PDP Context accept message to
the UE (PDP Address = link-local address).
5. UE keeps the link-local address, and extracts the
interface identifier for later use. UE may send a Router
Solicitation message to the GGSN (first hop router).
6. After PDP Context Activation, GGSN sends a Router
Advertisement to the UE. The UE should be configured not to
send a Neighbor Solicitation message. However, if one is sent,
the GGSN will silently discard it. The GGSN updates the SGSN
with the whole IPv6 address.
MS BSS/UTRAN SGSN GGSN
| | | |
|1. Active PDP Context Request | |
|----------------------------------->| |
| | | |
| | 2. Create PDP Context Request
| | |---------------->|
| | | |
| | 3. Create PDP Context Response
| | |<----------------|
| | | |
|4. Active PDP Context Accept | |
|<-----------------------------------| |
| | | |
|5. Router Solicitation | |
|- - - - - - - - - - - - - - - - - - - - - - - - - - ->|
<Yoo> Expires - May 2003-10-17 [Page 4]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
| | | |
|6. Router Advertisement | |
|<-----------------------------------------------------|
| | | |
Figure 1: 3GPP IPv6 Address Autoconfiguration steps
2.2 IETF Recommendation for 3GPP IPv6 Address Allocation
IPv6 Working Group recommends following three changes regarding the
use of IPv6 within 3GPP networks for a productive cooperation.
1. Specify that multiple prefixes may be assigned to each
primary PDP context,
2. Require that a given prefix must not be assigned to more
than one primary PDP context, and
3. Allow 3GPP nodes to use multiple identifiers within those
prefixes, including randomly generated identifiers.
For further understanding about IETF recommendation, refer to RFC3314.
3. IPv6 in 3GPP networks satisfying IETF' Recommendations.
3.1 Address allocation procedures
This section describes IPv6 autoconfiguration procedure satisfying
IETF's recommendation. This procedure is made of two phases. In the
first phase, MS gets multiple prefix from GGSN using RS/RA message by
IMSI based interface identification. In the second phase, MS
associates the selected prefix and interface identification created
by itself and register IPv6 address to GSNs using PDP context
activation.
MS BSS/UTRAN SGSN GGSN
| | | |
|1. Router Solicitation | |
|----------------------------------------------------->|
| | | |
|2. Router Advertisement | |
|<-----------------------------------------------------|
| | | |
|3. Active PDP Context Request | |
|----------------------------------->| |
<Yoo> Expires - May 2003-10-17 [Page 5]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
| | | |
| | 4. Create PDP Context Request
| | |---------------->|
| | | |
| | 5. Create PDP Context Response
| | |<----------------|
| | | |
|6. Active PDP Context Accept | |
|<-----------------------------------| |
| | | |
|(7. Router Solicitation : Backward Compatibility) |
|----------------------------------------------------->|
| | | |
|(8. Router Advertisement : Backward Compatibility) |
|<-----------------------------------------------------|
Figure 2: 3GPP Address Autoconfiguration steps satisfying IETFÆs
Recommendations to the 3GPP
1. RA message is sent to GGSN.
At this time, IMSI number is used for lower 64bit portion
(Interface Identification) in IPv6 address to identify each RA
message. Note that this IMSI based interface identification is
not the lower potion of IPv6 source address used in user
traffic connection. Since IMSI number is an unique 15-digit
number, it can be converted into about 50-bit length binary
number. This length is very close to the length of 48bit MAC
address . So, It is natural to map IMSI number into lower
64bit portion in IPv6 address field. In this case, we cannot
omit RA message different from 3GPP standard shown in section
2.1. As we can see from figure 2, the procedure starts with RA
message from MS to satisfy the IETF's recommendation different
from 3GPP legacy procedure.
2. After receiving RS message from MS, GGSN sends a RA message to
MS.
In this step, GGSN selects multiple /64 prefix for MS and
includes these multiple prefix in RA message in a precedence
sequence. Undoubtedly, the prefix must not be assigned to
other MS. The GSSN can identify the MS uniquely by IMSI based
interface identification.
3. The Activate PDP Context message is sent to the SGSN (PDP
Type=IPv6, PDP Address = IPv6 address selected by MS, etc.).
In this case, PDP address means full global IPv6 address and
is made of the following combination.
<Yoo> Expires - May 2003-10-17 [Page 6]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
PDP Address = prefix selected by MS in RA message + interface
identification selected by MS from TE or MT itself.
or
PDP Address can be 0 for backward compatibility
4. SGSN sends a Create PDP Context message to the GGSN with
the above parameters(parameters used in step 3).
5. GGSN updates context from MS. Especially, GGSN only
updates the prefix information extracted from PDP address
information not the whole IPv6 address. It is possible because
the GGSN has sent a multiple prefix not assigned to other MS.
It also means that each MS can be identified by just only
prefix not the whole IPv6 address. After that, the GGSN sends
Create PDP Context response to the SGSN with the parameters
(PDP address=prefix selected by MS + interface identification
->0). If the GGSN gets PDP address with '0', the GGSN follows
legacy 3GPP address auto-configuration steps. Section 3.3
explains backward compatibility. We can avoid the ambiguity
between the new steps and the legacy steps by using ?Æpadding
in an interface identification field.
6. SGSN updates the context based on the Create PDP Context
response message from GGSN. SGSN extracts prefix information
and keeps it for routing information. After that, SGSN sends
an Activate PDP Context Accept to the MS with the
parameters(PDP address=prefix selected by MS + interface
identification ->0). If the SGSN checks that interface
identification is not 0, the SGSN follows legacy 3GPP address
auto-configuration steps. Refer to 3.3 for backward
compatibility.
7. for Backward Compatibility. Refer to section 3.3
8. for Backward Compatibility. Refer to section 3.3
3.2 Network elements actions
MS Actions
When starts a session, MS prepares RS message with the
interface identification based on its IMSI number. GGSN will
reply MS with RA message including multiple /64 prefix. After
receiving a multiple /64 prefix, MS selects one /64 prefix for
a primary PDP context and stores the rest of prefix(s) for
<Yoo> Expires - May 2003-10-17 [Page 7]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
later use. For an Activate PDP context, MS prepares an
interface identification. In order to prepare this, MS must
have a capability to create a randomly chosen interface
identification by way of MT, TE or MS itself. With the chosen
/64 prefix and interface identification produced by MS, MS
composes PDP address and sends it to GGSN.
GGSN Actions
When receiving RS from MS, GGSN prepares multiple /64 prefix
for MS. These selected multiple prefix(s) must not be pre-
assigned to other MS. Prefix sets must be always unique to MS.
After preparing prefix(s), GGSN replys to MS with RA message
including selected prefix(s). If GGSN receives PDP context
from MS through SGSN, it must find whether PDP context means
the start of a session(legacy procedure) or the continuity of
a session. Those steps shown in figure 1 must go on in the
former case and the steps in figure 2 must be followed in the
later case. If GGSN finds that PDP address with /64
prefix(figure 2 steps), it stores only /64 prefix information
in its memory not the whole IPv6 address for efficiency. If
GGSN finds the PDP address with 0, it replys to MS with PDP
address including link-local address.
SGSN Actions
When receiving an Activate PDP Context message from MS, the
SGSN does not modify PDP type and PDP address information,
just relay to GGSN. If it receives a Create PDP Context
message from GGSN, it must find whether the interface
identification field is empty or not. If not empty, SGSN
notice that this session is for a legacy process. So, SGSN
just relay to MS with a Activate Context Accept message
without storing any information in PDP Context message. If
empty, SGSN notices that this session is for steps satisfying
IETF's recommendations. So, SGSN stores /64 prefix information
and replays toMS with an Activate Context Accept message.
3.3 Autoconfiguration steps for Backward compatibility
This section describes a backward compatibility supporting legacy
3GPP MS which is compatible with the process in section 2.1
MS BSS/UTRAN SGSN GGSN
| | | |
|(0. Router Solicitation : not used )| |
|----------------------------------------------------->|
<Yoo> Expires - May 2003-10-17 [Page 8]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
| | | |
|(0. Router Advertisement : not used ) |
|<-----------------------------------------------------|
| | | |
|1. Active PDP Context Request | |
|----------------------------------->| |
| | | |
| | 2. Create PDP Context Request
| | |---------------->|
| | | |
| | 3. Create PDP Context Response
| | |<----------------|
| | | |
|4. Active PDP Context Accept | |
|<-----------------------------------| |
| | | |
|5. Router Solicitation | |
|----------------------------------------------------->|
| | | |
|6. Router Advertisement | |
|<-----------------------------------------------------|
Figure 3: 3GPP Address Autoconfiguration steps for backward
compatibility
3GPP address autoconfiguration for backward compatibility has the
following steps:
0. Not used in backward compatibility steps.
1. The Activate PDP Context message is sent to SGSN (PDP
Type=IPv6, PDP Address = 0, etc.).
2. The SGSN sends a Create PDP Context message to GGSN with
the above parameters.
3. If GGSN gets PDP address with 0, GGSN chooses an interface
identifier for the PDP Context and creates a link-local
address. It answers to SGSN with a Create PDP Context response
(PDP Address = link-local Address). If GGSN gets a PDP address
with not 0, the GGSN follows step 5 in section 3.1
4. SGSN sends an Activate PDP Context accept message to
the MS (PDP Address = link-local address). If SGNS gets an
Interface identification with 0, the SGSN follows step 6 in
section 3.1
5. MS keeps the link-local address, and extracts the
<Yoo> Expires - May 2003-10-17 [Page 9]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
interface identifier for later use. UE may send a Router
Solicitation message to GGSN (first hop router).
6. After the PDP Context Activation, the GGSN sends a Router
Advertisement to MS. MS should be configured not to send a
Neighbor Solicitation message. However, if one is sent,
the GGSN will silently discard it. The GGSN updates the SGSN
with the whole IPv6 address. In case of GGSN actions, some
classification method needs whether RS message is a start of a
session(in steps satisfying IETF recommendation) or the rest
of the session(in steps of legacy 3GPP autoconfiguration).
This can be possible for GGSN by checking the interface
identification whether it is allocated by GGSN itself or not.
4. Security Considerations
The description of IPv6 usage in 3GPP networks does not have any
security considerations.
5. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
[2] M Wasserman, "Recommendations for IPv6 in Third Generation
Partnership Project(3GPP) Standards", RFC 3314, September 2002
[3] 3GPP TS Group, "GPRS Service Description State2? 3GPP 23.060,
March, 2003
Author' Addresses
Jae-Pil Yoo
Ph. D. Student in Konkuk University
Konkuk University Kwangjin gu Hwayangdong Seoul Korea
Email: willow@konkuk.ac.kr
Kee-cheon Kim
Professor in Konkuk University
Konkuk University Kwangjin gu Hwayangdong Seoul Korea
Email: kckim@konkuk.ac.kr
Jin-Pyo Hong
Professor in Hankook University of Foreign Study
89. Wangsan-ri Mohyun-myon. Yongin-shi. Kyongki-do. Korea
Email: jphong@hufs.ac.kr
Kyeong-Jin Lee
<Yoo> Expires - May 2003-10-17 [Page 10]
IPv6 in 3GPP networks satisfying IETF's recommendations
October 2003
ETRI / PEC
161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea
Phone: +82 42 860 6484
EMail: leekj@etri.re.kr
Hyoung-Jun Kim
ETRI / PEC
161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea
Phone: +82 42 860 6576
EMail: khj@etri.re.kr
<Yoo> Expires - May 2003-10-17 [Page 11]
