draft-ietf-ipv6-3gpp-recommend-00.txt   draft-ietf-ipv6-3gpp-recommend-01.txt 
Internet-Draft M. Wasserman, Editor Internet-Draft M. Wasserman, Editor
Document: draft-ietf-ipv6-3gpp-recommend-00.txt Wind River Document: draft-ietf-ipv6-3gpp-recommend-01.txt Wind River
Expires: July 2002 January 2002 Expires: October 2002 April 2002
Recommendations for IPv6 in 3GPP Standards Recommendations for IPv6 in 3GPP Standards
1 Status of this Memo 1 Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026]. all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 34 skipping to change at line 34
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2 Abstract 2 Abstract
This document contains recommendations from the Internet This document contains recommendations from the Internet
Engineering Task Force (IETF) IPv6 Working Group to the Third Engineering Task Force (IETF) IPv6 Working Group to the Third
Generation Partnership Project (3GPP) community regarding the use Generation Partnership Project (3GPP) community regarding the use
of IPv6 in the 3GPP standards. The IPv6 Working Group supports the of IPv6 in the 3GPP standards. Specifically, this document
use of IPv6 within 3GPP and offers these recommendations in a recommends that the 3GPP:
spirit of open cooperation between the IPv6 Working Group and the
3GPP community. 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.
The IPv6 Working Group supports the use of IPv6 within 3GPP and
offers these recommendations in a spirit of open cooperation
between the IPv6 Working Group and the 3GPP community. Since the
original publication of this document as an Internet-Draft, the
3GPP has adopted the primary recommendations of this document.
3 Copyright Notice 3 Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Wasserman, Editor Expires May 2002 1
Recommendations for IPv6 in 3GPP Standards April 2002
4 Conventions Used In This Document 4 Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 this document are to be interpreted as described in RFC 2119
[KEYWORD]. [KEYWORD].
Wasserman, Editor Expires May 2002 1
Recommendations for IPv6 in 3GPP Standards January 2002
5 Table of Contents 5 Table of Contents
1 Status of this Memo.......................................1 1 Status of this Memo.......................................1
2 Abstract..................................................1 2 Abstract..................................................1
3 Copyright Notice..........................................1 3 Copyright Notice..........................................1
4 Conventions Used In This Document.........................1 4 Conventions Used In This Document.........................2
5 Table of Contents.........................................2 5 Table of Contents.........................................2
6 Introduction..............................................3 6 Introduction..............................................3
6.1 What is the 3GPP?.........................................3 6.1 What is the 3GPP?.........................................3
6.2 What is the IETF?.........................................4 6.2 What is the IETF?.........................................4
6.3 Terminology...............................................4 6.3 Terminology...............................................4
6.3.1 3GPP Terminology..........................................4 6.3.1 3GPP Terminology..........................................5
6.3.2 IETF Terminology..........................................5 6.3.2 IETF Terminology..........................................5
6.4 Overview of the IPv6 Addressing Architecture..............5 6.4 Overview of the IPv6 Addressing Architecture..............6
6.5 An IP-Centric View of the 3GPP System.....................6 6.5 An IP-Centric View of the 3GPP System.....................7
6.5.1 Overview of the UMTS Architecture.........................7 6.5.1 Overview of the UMTS Architecture.........................7
6.5.2 The PDP Context...........................................9 6.5.2 The PDP Context...........................................9
6.5.3 IPv6 Address Autoconfiguration in GPRS...................10 6.5.3 IPv6 Address Autoconfiguration in GPRS...................11
7 Recommendations to the 3GPP..............................12 7 Recommendations to the 3GPP..............................13
7.1 Limitations of 3GPP Address Assignment...................12 7.1 Limitations of 3GPP Address Assignment...................13
7.2 Advertising Multiple Prefixes............................13 7.2 Advertising Multiple Prefixes............................14
7.3 Assigning a Prefix to Only One Primary PDP Context.......13 7.3 Assigning a Prefix to Only One Primary PDP Context.......14
7.3.1 Is a /64 per PDP Context Too Much?.......................13 7.3.1 Is a /64 per PDP Context Too Much?.......................14
7.3.2 Prefix Information in the SGSN...........................14 7.3.2 Prefix Information in the SGSN...........................15
7.4 Multiple Identifiers per PDP Context.....................14 7.4 Multiple Identifiers per PDP Context.....................15
8 Additional IPv6 Work Items...............................16 8 Additional IPv6 Work Items...............................17
9 Security Considerations..................................16 9 Security Considerations..................................17
10 Appendix A: Analysis of Findings........................17 10 Appendix A: Analysis of Findings........................18
10.1 Address Assignment Solutions.............................17 10.1 Address Assignment Solutions.............................18
11 References...............................................19 11 References...............................................20
12 Authors and Acknowledgements.............................21 12 Authors and Acknowledgements.............................22
13 Editor's Contact Information.............................21 13 Editor's Contact Information.............................22
Wasserman, Editor Expires May 2002 2 Wasserman, Editor Expires May 2002 2
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
6 Introduction 6 Introduction
In May 2001, the IPv6 Working Group (WG) held an interim meeting in
Redmond, WA to discuss the use of IPv6 within the 3GPP standards.
An architectural overview of 3GPP was presented, and there was much
discussion regarding the use of IPv6 within 3GPP. At that meeting,
a decision was made to form a design team to write a document
offering advice from the IPv6 WG to the 3GPP community regarding
their use of IPv6. This document is the result of that effort.
This document offers recommendations to the 3GPP community from the This document offers recommendations to the 3GPP community from the
IETF IPv6 Working Group. It is organized into three main sections: IETF IPv6 Working Group. It is organized into three main sections:
1. An introduction (this section) that provides background 1. An introduction (this section) that provides background
information regarding the IETF IPv6 WG and the 3GPP and information regarding the IETF IPv6 WG and the 3GPP and
includes a high-level overview of the technologies discussed includes a high-level overview of the technologies discussed
in this document. in this document.
2. Recommendations from the IPv6 WG to the 3GPP community. 2. Recommendations from the IPv6 WG to the 3GPP community.
These can be found in section 7. These can be found in section 7.
skipping to change at line 121 skipping to change at line 140
protocols (i.e. SIP, IPv4, etc.), as they are outside the scope of protocols (i.e. SIP, IPv4, etc.), as they are outside the scope of
the IPv6 Working Group. the IPv6 Working Group.
The IPv6 Working Group fully supports the use of IPv6 within 3GPP, The IPv6 Working Group fully supports the use of IPv6 within 3GPP,
and we encourage 3GPP implementers and operators to participate in and we encourage 3GPP implementers and operators to participate in
the IETF process. We are offering these suggestions in a spirit of the IETF process. We are offering these suggestions in a spirit of
open cooperation between the IPv6 Working Group and the 3GPP open cooperation between the IPv6 Working Group and the 3GPP
community, and we hope that our ongoing cooperation will help to community, and we hope that our ongoing cooperation will help to
strengthen both sets of standards. strengthen both sets of standards.
The 3GPP address allocation information in this document is based
on the 3GPP document TS 23.060 version 4.1.0 [OLD-TS23060]. At the
3GPP plenary meeting TSG #15 in March 2002, the 3GPP adopted the
two primary recommendations contained in this document, allocating
a unique prefix to each primary PDP context when IPv6 stateless
address autoconfiguration is used, and to allow the terminals to
use multiple interface identifiers. These changes were
retroactively applied from 3GPP release 99 onwards, in TS23.060
versions 3.11.0, 4.4.0 and 5.1.0 [NEW-TS23060].
6.1 What is the 3GPP? 6.1 What is the 3GPP?
The Third Generation Partnership Project (3GPP) is a global The Third Generation Partnership Project (3GPP) is a global
standardization partnership founded in late 1998. Its standardization partnership founded in late 1998. Its
Wasserman, Editor Expires May 2002 3
Recommendations for IPv6 in 3GPP Standards April 2002
Organizational Partners have agreed to co-operate in the production Organizational Partners have agreed to co-operate in the production
of technical specifications for a Third Generation Mobile System of technical specifications for a Third Generation Mobile System
based on the evolved GSM core networks. based on the evolved GSM core networks.
The 3GPP Organizational Partners consist of several different The 3GPP Organizational Partners consist of several different
standardization organizations: ETSI from Europe, Standards standardization organizations: ETSI from Europe, Standards
Committee T1 Telecommunications (T1) in the USA, China Wireless Committee T1 Telecommunications (T1) in the USA, China Wireless
Telecommunication Standard Group (CWTS), Korean Telecommunications Telecommunication Standard Group (CWTS), Korean Telecommunications
Technology Association (TTA), the Association of Radio Industries Technology Association (TTA), the Association of Radio Industries
and Businesses (ARIB) and the Telecommunication Technology and Businesses (ARIB) and the Telecommunication Technology
Committee(TTC) in Japan. Committee(TTC) in Japan.
The work is coordinated by a Project Co-ordination Group (PCG), and The work is coordinated by a Project Co-ordination Group (PCG), and
structured into Technical Specification Groups (TSGs). There are structured into Technical Specification Groups (TSGs). There are
five TSGs: Core Network (TSG CN), Radio Access Networks (TSG RAN), five TSGs: Core Network (TSG CN), Radio Access Networks (TSG RAN),
Services and System Aspects (TSG SA), GSM/EDGE Radio Access Network Services and System Aspects (TSG SA), GSM/EDGE Radio Access Network
(GERAN), and the Terminals (TSG T). The TSGs are further divided (GERAN), and the Terminals (TSG T). The TSGs are further divided
Wasserman, Editor Expires May 2002 3
Recommendations for IPv6 in 3GPP Standards January 2002
into Working Groups (WGs). The technical work is done in the into Working Groups (WGs). The technical work is done in the
working groups, and later approved in the TSGs. working groups, and later approved in the TSGs.
3GPP working methods are different from IETF working methods. The 3GPP working methods are different from IETF working methods. The
major difference is where the major part of the work is done. In major difference is where the major part of the work is done. In
3GPP, the work is done in face-to-face meetings, and the mailing 3GPP, the work is done in face-to-face meetings, and the mailing
list is used mainly for distributing contributions, and for list is used mainly for distributing contributions, and for
handling documents that were not handled in the meeting due to lack handling documents that were not handled in the meeting due to lack
of time. Decisions are usually made by consensus, though voting of time. Decisions are usually made by consensus, though voting
does exist. However, it is rather rare to vote. 3GPP documents are does exist. However, it is rather rare to vote. 3GPP documents are
public and can be accessed at http://www.3gpp.org/. public and can be accessed via the 3GPP web site [3GPP-URL].
6.2 What is the IETF? 6.2 What is the IETF?
The Internet Engineering Task Force (IETF) is a large open The Internet Engineering Task Force (IETF) is a large open
international community of network designers, operators, vendors, international community of network designers, operators, vendors,
and researchers concerned with the evolution of the Internet and researchers concerned with the evolution of the Internet
architecture and the smooth operation of the Internet. The IETF is architecture and the smooth operation of the Internet. The IETF is
also the primary standards body developing Internet protocols and also the primary standards body developing Internet protocols and
standards. It is open to any interested individual. More standards. It is open to any interested individual. More
information about the IETF can be found at http://www.ietf.org. information about the IETF can be found at the IETF web site [IETF-
URL].
The actual technical work of the IETF is done in working groups, The actual technical work of the IETF is done in working groups,
which are organized by topic into several areas (e.g., routing, which are organized by topic into several areas (e.g., routing,
transport, security, etc.). The IPv6 Working Group is chartered transport, security, etc.). The IPv6 Working Group is chartered
within the Internet area of the IETF. Much of the work is handled within the Internet area of the IETF. Much of the work is handled
via mailing lists, and the IETF holds meetings three times per via mailing lists, and the IETF holds meetings three times per
year. year.
6.3 Terminology 6.3 Terminology
This section defines the 3GPP and IETF terminology used in this This section defines the 3GPP and IETF terminology used in this
document. The 3GPP terms and their meanings have been taken from document. The 3GPP terms and their meanings have been taken from
[TR21905]. [TR21905].
Wasserman, Editor Expires May 2002 4
Recommendations for IPv6 in 3GPP Standards April 2002
6.3.1 3GPP Terminology 6.3.1 3GPP Terminology
APN Access Point Name. The APN is a logical name referring APN Access Point Name. The APN is a logical name referring
to a GGSN and an external network. to a GGSN and an external network.
CS Circuit Switched CS Circuit Switched
GERAN GSM/EDGE Radio Access Network GERAN GSM/EDGE Radio Access Network
GGSN Gateway GPRS Support Node. A router between the GPRS GGSN Gateway GPRS Support Node. A router between the GPRS
network and an external network (i.e. the Internet). network and an external network (i.e. the Internet).
GPRS General Packet Radio Services GPRS General Packet Radio Services
GTP-U General Tunneling Protocol - User Plane GTP-U General Tunneling Protocol - User Plane
MT Mobile Termination. For example, a mobile phone MT Mobile Termination. For example, a mobile phone
handset. handset.
Wasserman, Editor Expires May 2002 4
Recommendations for IPv6 in 3GPP Standards January 2002
PDP Packet Data Protocol PDP Packet Data Protocol
PDP Context A PDP connection between the UE and the GGSN. PDP Context A PDP connection between the UE and the GGSN.
PS Packet Switched PS Packet Switched
SGSN Serving GPRS Support Node SGSN Serving GPRS Support Node
TE Terminal Equipment. For example, a laptop attached TE Terminal Equipment. For example, a laptop attached
through a 3GPP handset. through a 3GPP handset.
skipping to change at line 227 skipping to change at line 257
UMTS Universal Mobile Telecommunications System UMTS Universal Mobile Telecommunications System
USIM Universal Subscriber Identity Module. Typically, a USIM Universal Subscriber Identity Module. Typically, a
card that is inserted into a mobile phone handset. card that is inserted into a mobile phone handset.
UTRAN Universal Terrestrial Radio Access Network UTRAN Universal Terrestrial Radio Access Network
6.3.2 IETF Terminology 6.3.2 IETF Terminology
IPv6 Internet Protocol version 6 IPv6 Internet Protocol version 6 [RFC 2460]
NAS Network Access Server NAS Network Access Server
NAT Network Address Translator NAT Network Address Translator
NAT-PT Network Address Translation with Protocol Translation. NAT-PT Network Address Translation with Protocol Translation.
An IPv6 transition mechanism. An IPv6 transition mechanism. [NAT-PT]
PPP Point-to-Point Protocol PPP Point-to-Point Protocol [PPP]
SIIT Stateless IP/ICMP Transition Mechanism Wasserman, Editor Expires May 2002 5
Recommendations for IPv6 in 3GPP Standards April 2002
SIIT Stateless IP/ICMP Transition Mechanism [SIIT]
6.4 Overview of the IPv6 Addressing Architecture 6.4 Overview of the IPv6 Addressing Architecture
The recommendations in this document are primarily related to IPv6 The recommendations in this document are primarily related to IPv6
address assignment. To fully understand the recommended changes, address assignment. To fully understand the recommended changes,
it is necessary to understand the IPv6 addressing architecture, and it is necessary to understand the IPv6 addressing architecture, and
current IPv6 address assignment mechanisms. current IPv6 address assignment mechanisms.
The IPv6 addressing architecture represents a significant evolution The IPv6 addressing architecture represents a significant evolution
from IPv4 addressing [ADDRARCH]. It is required that all IPv6 nodes from IPv4 addressing [ADDRARCH]. It is required that all IPv6 nodes
be able to assemble their own addresses from interface identifiers be able to assemble their own addresses from interface identifiers
and prefix information. This mechanism is called IPv6 Host and prefix information. This mechanism is called IPv6 Host
Autoconfiguration [AUTOCONF], and it allows IPv6 nodes to configure Autoconfiguration [AUTOCONF], and it allows IPv6 nodes to configure
themselves without the need for stateful configuration servers themselves without the need for stateful configuration servers
(i.e. DHCPv6) or statically configured addresses. (i.e. DHCPv6) or statically configured addresses.
Wasserman, Editor Expires May 2002 5
Recommendations for IPv6 in 3GPP Standards January 2002
Interface identifiers can be globally unique, such as modified EUI- Interface identifiers can be globally unique, such as modified EUI-
64 addresses [ADDRARCH], or non-unique, such as randomly generated 64 addresses [ADDRARCH], or non-unique, such as randomly generated
identifiers. Hosts that have a globally unique identifier identifiers. Hosts that have a globally unique identifier
available may also choose to use randomly generated addresses for available may also choose to use randomly generated addresses for
privacy [PRIVADDR] or for other reasons. IPv6 hosts are free to privacy [PRIVADDR] or for other reasons. IPv6 hosts are free to
generate new identifiers at any time, and Duplicate Address generate new identifiers at any time, and Duplicate Address
Detection (DAD) is used to protect against the use of duplicate Detection (DAD) is used to protect against the use of duplicate
identifiers on a single link [IPV6ND]. identifiers on a single link [IPV6ND].
A constant link-local prefix can be combined with any interface A constant link-local prefix can be combined with any interface
skipping to change at line 294 skipping to change at line 324
IPv6 explicitly associates each address with an interface. IPv6 explicitly associates each address with an interface.
Multiple-interface hosts may have interfaces on more than one link Multiple-interface hosts may have interfaces on more than one link
or in more than one site. Links and sites are internally or in more than one site. Links and sites are internally
identified using zone identifiers. Proper routing of non-global identified using zone identifiers. Proper routing of non-global
traffic and proper address selection are ensured by the IPv6 scoped traffic and proper address selection are ensured by the IPv6 scoped
addressing architecture [SCOPARCH]. addressing architecture [SCOPARCH].
IPv6 introduces the concept of privacy addresses [PRIVADDR]. These IPv6 introduces the concept of privacy addresses [PRIVADDR]. These
addresses are generated from an advertised global prefix and a addresses are generated from an advertised global prefix and a
Wasserman, Editor Expires May 2002 6
Recommendations for IPv6 in 3GPP Standards April 2002
randomly generated identifier, and are used for anonymous access to randomly generated identifier, and are used for anonymous access to
Internet services. Applications control the generation of privacy Internet services. Applications control the generation of privacy
addresses, and new addresses can be generated at any time. addresses, and new addresses can be generated at any time.
The IPv6 site renumbering specification [SITEREN] relies upon the The IPv6 site renumbering specification [SITEREN] relies upon the
fact that IPv6 nodes will generate new addresses when new prefixes fact that IPv6 nodes will generate new addresses when new prefixes
are advertised on the link, and that they will deprecate addresses are advertised on the link, and that they will deprecate addresses
that use deprecated prefixes. that use deprecated prefixes.
In the future, additional IPv6 specifications may rely upon the In the future, additional IPv6 specifications may rely upon the
ability of IPv6 nodes to use multiple prefixes and/or multiple ability of IPv6 nodes to use multiple prefixes and/or multiple
identifiers to dynamically create new addresses. identifiers to dynamically create new addresses.
6.5 An IP-Centric View of the 3GPP System 6.5 An IP-Centric View of the 3GPP System
The 3GPP specifications define a Third Generation Mobile System. The 3GPP specifications define a Third Generation Mobile System.
An overview of the packet switched (PS) domain of the 3GPP Release An overview of the packet switched (PS) domain of the 3GPP Release
99 system is described in the following sections. The authors hope 99 system is described in the following sections. The authors hope
Wasserman, Editor Expires May 2002 6
Recommendations for IPv6 in 3GPP Standards January 2002
that this description is sufficient for the reader who is that this description is sufficient for the reader who is
unfamiliar with the UMTS packet switched service to understand how unfamiliar with the UMTS packet switched service to understand how
the UMTS system works, and how IPv6 is currently defined to be used the UMTS system works, and how IPv6 is currently defined to be used
within it. within it.
6.5.1 Overview of the UMTS Architecture 6.5.1 Overview of the UMTS Architecture
The UMTS architecture can be divided into two main domains -- the The UMTS architecture can be divided into two main domains -- the
packet switched (PS) domain, and the circuit switched (CS) domain. packet switched (PS) domain, and the circuit switched (CS) domain.
In this document, we will concentrate on the PS domain, or General In this document, we will concentrate on the PS domain, or General
skipping to change at line 341 skipping to change at line 371
| |
+R +R
| |
------ Uu ----------- Iu ----------- Gn ----------- Gi ------ Uu ----------- Iu ----------- Gn ----------- Gi
| MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+-- | MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+--
------ ----------- ----------- ----------- ------ ----------- ----------- -----------
(UE) (UE)
Figure 1: Simplified GPRS Architecture Figure 1: Simplified GPRS Architecture
Wasserman, Editor Expires May 2002 7
Recommendations for IPv6 in 3GPP Standards April 2002
------ ------
| | | |
| App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer) | App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer)
| | | |
|------| ------------- |------| -------------
| IP |- - - - - - - - - - - - - - - - - - - - - - -| IP |-> | IP |- - - - - - - - - - - - - - - - - - - - - - -| IP |->
| v4/6 | | v4/6 | | v4/6 | | v4/6 |
|------| ------------- ------------- |------ | |------| ------------- ------------- |------ |
| | | \ Relay / | | \ Relay / | | | | | | | \ Relay / | | \ Relay / | | | |
| | | \ / | | \ / | | | | | | | \ / | | \ / | | | |
skipping to change at line 367 skipping to change at line 400
| RLC |- - -| RLC | IP |- - -| IP | IP |- - -| IP | | | RLC |- - -| RLC | IP |- - -| IP | IP |- - -| IP | |
| | | | v4/6 | | v4/6 | v4/6 | |v4/6 | | | | | | v4/6 | | v4/6 | v4/6 | |v4/6 | |
|------| |------|------| |------|------| |------|------| |------| |------|------| |------|------| |------|------|
| MAC | | MAC | AAL5 |- - -| AAL5 | L2 |- - -| L2 | L2 | | MAC | | MAC | AAL5 |- - -| AAL5 | L2 |- - -| L2 | L2 |
|------| |------|------| |------|------| |------|------| |------| |------|------| |------|------| |------|------|
| L1 |- - -| L1 | ATM |- - -| ATM | L1 |- - -| L1 | L1 | | L1 |- - -| L1 | ATM |- - -| ATM | L1 |- - -| L1 | L1 |
------ ------------- ------------- ------------- ------ ------------- ------------- -------------
UE UTRAN SGSN GGSN UE UTRAN SGSN GGSN
(handset) (handset)
Figure 2: GPRS Protocol Stacks Figure 2: GPRS Protocol Stacks
Wasserman, Editor Expires May 2002 7
Recommendations for IPv6 in 3GPP Standards January 2002
------ ------
| | | |
| App. |- - - - - - - - - - - - - - - - - - - - - - (to app peer) | App. |- - - - - - - - - - - - - - - - - - - - - - (to app peer)
| | | |
|------| |------|
| | | |
| IP |- - - - - - - - - - - - - - - - - - - - - - (to GGSN) | IP |- - - - - - - - - - - - - - - - - - - - - - (to GGSN)
| v4/6 | | v4/6 |
| | | | | | | |
|------| |-------------| |------| |-------------|
skipping to change at line 395 skipping to change at line 424
| | | \ / | | | | \ / |
| | | \ / PDCP|- - - (to UTRAN) | | | \ / PDCP|- - - (to UTRAN)
| | | | | | | | | |
| PPP |- - -| PPP |------| | PPP |- - -| PPP |------|
| | | | RLC |- - - (to UTRAN) | | | | RLC |- - - (to UTRAN)
| | | |------| | | | |------|
| | | | MAC | | | | | MAC |
|------| |------|------| |------| |------|------|
| L1a |- - -| L1a | L1b |- - - (to UTRAN) | L1a |- - -| L1a | L1b |- - - (to UTRAN)
------ ------------- ------ -------------
TE MT TE MT
(laptop) (handset) (laptop) (handset)
Figure 3: Laptop Attached to 3GPP Handset Figure 3: Laptop Attached to 3GPP Handset
The GRPS core network elements shown in Figures 1 and 2 are the Wasserman, Editor Expires May 2002 8
Recommendations for IPv6 in 3GPP Standards April 2002
The GPRS core network elements shown in Figures 1 and 2 are the
User Equipment (UE), Serving GPRS Support Node (SGSN) and Gateway User Equipment (UE), Serving GPRS Support Node (SGSN) and Gateway
GPRS Support Node (GGSN). The UTRAN comprises Radio Access Network GPRS Support Node (GGSN). The UTRAN comprises Radio Access Network
Controllers (RNC) and the UTRAN base stations. Controllers (RNC) and the UTRAN base stations.
GGSN A specialized router that functions as the gateway between the GGSN A specialized router that functions as the gateway between the
GPRS network and the external networks, e.g. Internet. It also GPRS network and the external networks, e.g. Internet. It also
gathers charging information about the connections. In many gathers charging information about the connections. In many
ways the GGSN is similar to a Network Access Server (NAS). ways the GGSN is similar to a Network Access Server (NAS).
SGSN The SGSN's main functions include authentication, SGSN The SGSN's main functions include authentication,
skipping to change at line 423 skipping to change at line 454
information. The SGSN is connected to the SS7 network and information. The SGSN is connected to the SS7 network and
through that to the Home Location Register (HLR), so that it through that to the Home Location Register (HLR), so that it
can perform user profile handling, authentication, and can perform user profile handling, authentication, and
authorization. authorization.
GTP-U is a simple tunnelling protocol running over UDP/IP GTP-U is a simple tunnelling protocol running over UDP/IP
and used to route packets between RNC, SGSN and GGSN within the and used to route packets between RNC, SGSN and GGSN within the
same, or between different, UMTS backbone(s). A GTP-U tunnel is same, or between different, UMTS backbone(s). A GTP-U tunnel is
identified at each end by a Tunnel Endpoint Identifier (TEID). identified at each end by a Tunnel Endpoint Identifier (TEID).
Wasserman, Editor Expires May 2002 8
Recommendations for IPv6 in 3GPP Standards January 2002
Only the most significant elements of the GPRS system are discussed Only the most significant elements of the GPRS system are discussed
in this document. More information about the GPRS system can be in this document. More information about the GPRS system can be
found in [TS23060]. found in [OLD-TS23060].
6.5.2 The PDP Context 6.5.2 The PDP Context
The most important 3GPP concept in this context is a PDP Context. A The most important 3GPP concept in this context is a PDP Context. A
PDP Context is a connection between the UE and the GGSN, over which PDP Context is a connection between the UE and the GGSN, over which
the packets are transferred. There are two kinds of PDP Contexts -- the packets are transferred. There are two kinds of PDP Contexts --
primary, and secondary. primary, and secondary.
The primary PDP Context initially defines the link to the GGSN. For The primary PDP Context initially defines the link to the GGSN. For
instance, an IP address is assigned to each primary PDP Context. In instance, an IP address is assigned to each primary PDP Context. In
skipping to change at line 458 skipping to change at line 486
between the UE and the GGSN, as long as there are other (secondary) between the UE and the GGSN, as long as there are other (secondary)
PDP contexts active for the same IP address. PDP contexts active for the same IP address.
There are currently three PDP Types supported in GPRS -- IPv4, There are currently three PDP Types supported in GPRS -- IPv4,
IPv6, and PPP. This document will only discuss the IPv6 PDP Type. IPv6, and PPP. This document will only discuss the IPv6 PDP Type.
There are three basic actions that can be performed on a PDP There are three basic actions that can be performed on a PDP
Context: PDP Context Activation, Modification, and Deactivation. Context: PDP Context Activation, Modification, and Deactivation.
These actions are described in the following. These actions are described in the following.
Wasserman, Editor Expires May 2002 9
Recommendations for IPv6 in 3GPP Standards April 2002
Activate PDP Context Activate PDP Context
Opens a new PDP Context to a GGSN. If a new primary Opens a new PDP Context to a GGSN. If a new primary
PDP Context is activated, there is a new link created PDP Context is activated, there is a new link created
between a UE and a GGSN. A UE can open multiple between a UE and a GGSN. A UE can open multiple
primary PDP Contexts to one or more GGSNs. primary PDP Contexts to one or more GGSNs.
Modify PDP Context Modify PDP Context
Changes the characteristics of a PDP Context, for Changes the characteristics of a PDP Context, for
skipping to change at line 480 skipping to change at line 511
Deactivate PDP Context Deactivate PDP Context
Deactivates a PDP Context. If a primary PDP Context Deactivates a PDP Context. If a primary PDP Context
and all secondary PDP contexts associated with it are and all secondary PDP contexts associated with it are
deactivated, a link between the UE and the GGSN is deactivated, a link between the UE and the GGSN is
removed. removed.
The APN is a name which is logically linked to a GGSN. The APN may The APN is a name which is logically linked to a GGSN. The APN may
identify a service or an external network. The syntax of the APN identify a service or an external network. The syntax of the APN
corresponds to a fully qualified domain name. At PDP context corresponds to a fully qualified domain name. At PDP context
Wasserman, Editor Expires May 2002 9
Recommendations for IPv6 in 3GPP Standards January 2002
activation, the SGSN performs a DNS query to find out the GGSN(s) activation, the SGSN performs a DNS query to find out the GGSN(s)
serving the APN requested by the terminal. The DNS response serving the APN requested by the terminal. The DNS response
contains a list of GGSN addresses from which the SGSN selects one contains a list of GGSN addresses from which the SGSN selects one
(in a round-robin fashion). (in a round-robin fashion).
--------- -------- --------- --------
| | | GGSN | | | | GGSN |
| | LINK 1 | | | | LINK 1 | |
| -======== PDP Context A ========- - - -> ISP X | -======== PDP Context A ========- - - -> ISP X
| | | | | | | |
| | | | | | | |
| | | | | | | |
| /======= PDP Context B =======\ | | /======= PDP Context B =======\ |
| - | LINK 2 | - - - -> ISP Y | - | LINK 2 | - - - -> ISP Y
| \======= PDP Context C =======/ | | \======= PDP Context C =======/ |
| | | | | | | |
| | | |
| MT | -------- | MT | --------
|(handset)| |(handset)|
| | -------- | | --------
-------- | | | GGSN | -------- | | | GGSN |
| | | | LINK 3 | | | | | | LINK 3 | |
| | | -======== PDP Context D ========- | | | | -======== PDP Context D ========- |
| TE | | | | | | TE | | | | |
|(laptop)| | | | - - -> ISP Z |(laptop)| | | | - - -> ISP Z
| | | | LINK 4 | | | | | | LINK 4 | |
| -====PPP====-----======== PDP Context E ========- | | -====PPP====-----======== PDP Context E ========- |
| | | | | | | | | | | |
| | | | | | | | | | | |
-------- --------- -------- -------- --------- --------
Figure 3: Correspondence of PDP Contexts to IPv6 Links Figure 3: Correspondence of PDP Contexts to IPv6 Links
Wasserman, Editor Expires May 2002 10
Recommendations for IPv6 in 3GPP Standards April 2002
6.5.3 IPv6 Address Autoconfiguration in GPRS 6.5.3 IPv6 Address Autoconfiguration in GPRS
GPRS supports static and dynamic address allocation. Two types of GPRS supports static and dynamic address allocation. Two types of
dynamic address allocation are supported -- stateless, and dynamic address allocation are supported -- stateless, and
stateful. Stateful address configuration uses an external protocol stateful. Stateful address configuration uses an external protocol
to connect to a server that gives the IP address, e.g. DHCP. to connect to a server that gives the IP address, e.g. DHCP.
The stateless IPv6 autoconfiguration works differently in GPRS than The stateless IPv6 autoconfiguration works differently in GPRS than
in Ethernet networks. GPRS nodes have no unique identifier, whereas in Ethernet networks. GPRS nodes have no unique identifier, whereas
Ethernet nodes can create an identifier from their EUI-48 address. Ethernet nodes can create an identifier from their EUI-48 address.
Because GPRS networks are similar to dialup networks, the stateless Because GPRS networks are similar to dialup networks, the stateless
address autoconfiguration in GPRS was based on PPPv6 [PPPV6]. address autoconfiguration in GPRS was based on PPPv6 [PPPV6].
3GPP address autoconfiguration has the following steps: 3GPP address autoconfiguration has the following steps:
1. The Activate PDP Context message is sent to the SGSN (PDP 1. The Activate PDP Context message is sent to the SGSN (PDP
Type=IPv6, PDP Address = 0, etc.). Type=IPv6, PDP Address = 0, etc.).
Wasserman, Editor Expires May 2002 10
Recommendations for IPv6 in 3GPP Standards January 2002
2. The SGSN sends a Create PDP Context message to the GGSN with 2. The SGSN sends a Create PDP Context message to the GGSN with
the above parameters. the above parameters.
3. GGSN chooses an interface identifier for the PDP Context and 3. GGSN chooses an interface identifier for the PDP Context and
creates the link-local address. It answers the SGSN with a creates the link-local address. It answers the SGSN with a
Create PDP Context response (PDP Address = link-local Create PDP Context response (PDP Address = link-local
address). address).
4. The SGSN sends an Activate PDP Context accept message to the 4. The SGSN sends an Activate PDP Context accept message to the
UE (PDP Address = link-local address). UE (PDP Address = link-local address).
skipping to change at line 573 skipping to change at line 599
for communication on the Internet. A handset may create many for communication on the Internet. A handset may create many
primary and/or secondary PDP contexts throughout the life of its primary and/or secondary PDP contexts throughout the life of its
connection with a GGSN. connection with a GGSN.
Within 3GPP, the GGSN assigns a single 64-bit identifier to each Within 3GPP, the GGSN assigns a single 64-bit identifier to each
primary PDP context. The GGSN also advertises a single /64 prefix primary PDP context. The GGSN also advertises a single /64 prefix
to the handset, and these two items are assembled into a single to the handset, and these two items are assembled into a single
IPv6 address. Later, the GGSN modifies the PDP context entry in IPv6 address. Later, the GGSN modifies the PDP context entry in
the SGSN to include the whole IPv6 address, so that the SGSN can the SGSN to include the whole IPv6 address, so that the SGSN can
know the single address of each 3GPP node (e.g. for billing know the single address of each 3GPP node (e.g. for billing
Wasserman, Editor Expires May 2002 11
Recommendations for IPv6 in 3GPP Standards April 2002
purposes). This address is also used in the GGSN to identify the purposes). This address is also used in the GGSN to identify the
PDP context associated with each packet. It is assumed that 3GPP PDP context associated with each packet. It is assumed that 3GPP
nodes will not generate any addresses, except for the single nodes will not generate any addresses, except for the single
identifier/prefix combination assigned by the GGSN. DAD is not identifier/prefix combination assigned by the GGSN. DAD is not
performed, as the GGSN will not assign the same address to multiple performed, as the GGSN will not assign the same address to multiple
nodes. nodes.
Wasserman, Editor Expires May 2002 11 Wasserman, Editor Expires May 2002 12
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
7 Recommendations to the 3GPP 7 Recommendations to the 3GPP
In the spirit of productive cooperation, the IPv6 Working Group In the spirit of productive cooperation, the IPv6 Working Group
recommends that the 3GPP consider three changes regarding the use recommends that the 3GPP consider three changes regarding the use
of IPv6 within GPRS. Specifically, we recommend that the 3GPP of IPv6 within GPRS. Specifically, we recommend that the 3GPP
1. Specify that multiple prefixes may be assigned to each 1. Specify that multiple prefixes may be assigned to each
primary PDP context, primary PDP context,
skipping to change at line 635 skipping to change at line 665
The current 3GPP address assignment mechanism has the following The current 3GPP address assignment mechanism has the following
limitations: limitations:
The GGSN only advertises a single /64 prefix, rather than a The GGSN only advertises a single /64 prefix, rather than a
set of prefixes. This will prevent the participation of 3GPP set of prefixes. This will prevent the participation of 3GPP
nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site
renumbering, or in other mechanisms that expect IPv6 hosts to renumbering, or in other mechanisms that expect IPv6 hosts to
create addresses based on multiple advertised prefixes. create addresses based on multiple advertised prefixes.
Wasserman, Editor Expires May 2002 12 Wasserman, Editor Expires May 2002 13
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
A 3GPP node is assigned a single identifier and is not allowed A 3GPP node is assigned a single identifier and is not allowed
to generate additional identifiers. This will prevent the use to generate additional identifiers. This will prevent the use
of privacy addresses by 3GPP nodes. This also makes 3GPP of privacy addresses by 3GPP nodes. This also makes 3GPP
mechanisms not fully compliant with the expected behavior of mechanisms not fully compliant with the expected behavior of
IPv6 nodes, which will result in incompatibility with popular IPv6 nodes, which will result in incompatibility with popular
laptop IPv6 stacks. For example, a laptop that uses privacy laptop IPv6 stacks. For example, a laptop that uses privacy
addresses for web browser connections could not currently not addresses for web browser connections could not currently not
currently establish a web browser connection over a 3GPP link. currently establish a web browser connection over a 3GPP link.
skipping to change at line 693 skipping to change at line 723
to each primary PDP context. This will allow sufficient address to each primary PDP context. This will allow sufficient address
space for a 3GPP-attached node to allocate privacy addresses and/or space for a 3GPP-attached node to allocate privacy addresses and/or
route to a multi-link subnet [MULTLINK], and will discourage the route to a multi-link subnet [MULTLINK], and will discourage the
use of NAT within 3GPP-attached devices. use of NAT within 3GPP-attached devices.
7.3.1 Is a /64 per PDP Context Too Much? 7.3.1 Is a /64 per PDP Context Too Much?
If an operator assigns a /64 per PDP context, can we be assured If an operator assigns a /64 per PDP context, can we be assured
that there is enough address space for millions of mobile devices? that there is enough address space for millions of mobile devices?
Wasserman, Editor Expires May 2002 13 Wasserman, Editor Expires May 2002 14
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
This question can be answered in the positive using the Host This question can be answered in the positive using the Host
Density (HD) Ratio for address assignment efficiency [HD]. This is Density (HD) Ratio for address assignment efficiency [HD]. This is
a measure of the number of addresses that can practically and a measure of the number of addresses that can practically and
easily be assigned to hosts, taking into consideration the easily be assigned to hosts, taking into consideration the
inefficiencies in usage resulting from the various address inefficiencies in usage resulting from the various address
assignment processes. The HD ratio was empirically derived assignment processes. The HD ratio was empirically derived
from actual telephone number and data network address assignment from actual telephone number and data network address assignment
cases. cases.
skipping to change at line 728 skipping to change at line 758
majority of these IPv6 /64 prefixes will be used by non-3GPP majority of these IPv6 /64 prefixes will be used by non-3GPP
networks, there is still clearly a sufficient number of /64 networks, there is still clearly a sufficient number of /64
prefixes. prefixes.
Given this, it can be safely concluded that the IPv6 address space Given this, it can be safely concluded that the IPv6 address space
will not be exhausted if /64 prefixes are allocated to primary PDP will not be exhausted if /64 prefixes are allocated to primary PDP
contexts. contexts.
For more information regarding policies for IPv6 address For more information regarding policies for IPv6 address
assignment, refer to the IAB/IESG recommendations regarding address assignment, refer to the IAB/IESG recommendations regarding address
assignment [IABAA], the APNIC, ARIN and RIPE address allocation assignment [IABAA], and the APNIC, ARIN and RIPE address allocation
policy [AAPOL] and the ARIN minutes located at policy [AAPOL].
http://www.arin.net/minutes/bot/bot08152001.html.
7.3.2 Prefix Information in the SGSN 7.3.2 Prefix Information in the SGSN
Currently, the 3GPP standards allow only one prefix and one Currently, the 3GPP standards allow only one prefix and one
identifier for each PDP context. So, the GGSN can send a single identifier for each PDP context. So, the GGSN can send a single
IPv6 address to the SGSN, to be used for billing purposes, etc. IPv6 address to the SGSN, to be used for billing purposes, etc.
Instead of using the full IPv6 address to identify a PDP context, Instead of using the full IPv6 address to identify a PDP context,
the IPv6 WG recommends that the SGSN be informed of each prefix the IPv6 WG recommends that the SGSN be informed of each prefix
that is currently assigned to a PDP context. By assigning a prefix that is currently assigned to a PDP context. By assigning a prefix
to only one primary PDP context, the SGSN can associate a prefix to only one primary PDP context, the SGSN can associate a prefix
list with each PDP context. list with each PDP context.
7.4 Multiple Identifiers per PDP Context 7.4 Multiple Identifiers per PDP Context
The IPv6 WG also recommends that the 3GPP standards be modified to The IPv6 WG also recommends that the 3GPP standards be modified to
allow multiple identifiers, including randomly generated allow multiple identifiers, including randomly generated
identifiers, to be used within each assigned prefix. This would identifiers, to be used within each assigned prefix. This would
allow 3GPP nodes to generate and use privacy addresses, and would allow 3GPP nodes to generate and use privacy addresses, and would
be compatible with future IPv6 standards that may depend on the
Wasserman, Editor Expires May 2002 14 Wasserman, Editor Expires May 2002 15
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
be compatible with future IPv6 standards that may depend on the
ability of IPv6 nodes to generate new interface identifiers for ability of IPv6 nodes to generate new interface identifiers for
communication. communication.
This is a vital change, necessary to allow standards-compliant IPv6 This is a vital change, necessary to allow standards-compliant IPv6
nodes to connect to the Internet through 3GPP handsets, without nodes to connect to the Internet through 3GPP handsets, without
modification. It is expected that most IPv6 nodes, including the modification. It is expected that most IPv6 nodes, including the
most popular laptop stacks, will generate privacy addresses. The most popular laptop stacks, will generate privacy addresses. The
current 3GPP specifications will not be compatible with those current 3GPP specifications will not be compatible with those
implementations. implementations.
Wasserman, Editor Expires May 2002 15 Wasserman, Editor Expires May 2002 16
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
8 Additional IPv6 Work Items 8 Additional IPv6 Work Items
During our work on this document, we have discovered several areas During our work on this document, we have discovered several areas
that could benefit from further informational or standards-track that could benefit from further informational or standards-track
work within the IPv6 Working Group. work within the IPv6 Working Group.
The IPv6 WG should work to define a point-to-point architecture and The IPv6 WG should work to define a point-to-point architecture and
specify how the standard IPv6 address assignment mechanisms are specify how the standard IPv6 address assignment mechanisms are
applicable to IPv6 over point-to-point links. We should also applicable to IPv6 over point-to-point links. We should also
review and clarify the IPv6 over PPP specification to match the review and clarify the IPv6 over PPP specification [PPP] to match
current IPv6 addressing architecture. the current IPv6 addressing architecture [ADDRARCH].
The IPv6 WG should consider publishing an "IPv6 over PDP Contexts" The IPv6 WG should consider publishing an "IPv6 over PDP Contexts"
document. This document would be useful for developers writing (or similar) document. This document would be useful for
drivers for IPv6 stacks to work over 3GPP PDP Contexts. developers writing drivers for IPv6 stacks to work over 3GPP PDP
Contexts.
There is an ongoing effort to define a set of requirements for The IPv6 working group should undertake an effort to define the
cellular hosts [CELLREQ]. This work has been presented to the IPv6 minimal requirements for all IPv6 nodes.
WG, but has not been adopted as an IPv6 WG work item. This work
should be continued within the working group, and may feed into a
broader effort to define the requirements for all IPv6 nodes.
9 Security Considerations 9 Security Considerations
This document contains recommendations on the use of the IPv6 This document contains recommendations on the use of the IPv6
protocol in 3GPP standards. It does not specify a protocol, and it protocol in 3GPP standards. It does not specify a protocol, and it
introduces no new security considerations. introduces no new security considerations.
Wasserman, Editor Expires May 2002 16 Wasserman, Editor Expires May 2002 17
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
10 Appendix A: Analysis of Findings 10 Appendix A: Analysis of Findings
This section includes some analysis that may be useful to This section includes some analysis that may be useful to
understanding why the IPv6 working group is making the above understanding why the IPv6 working group is making the above
recommendations. It also includes some other options that were recommendations. It also includes some other options that were
explored, and the reasons why those options were less suitable than explored, and the reasons why those options were less suitable than
the recommendations outlined above. the recommendations outlined above.
10.1 Address Assignment Solutions 10.1 Address Assignment Solutions
skipping to change at line 853 skipping to change at line 880
2. Share the same prefix between multiple PDP Contexts 2. Share the same prefix between multiple PDP Contexts
connected to the same GGSN (and APN). Given that mobile connected to the same GGSN (and APN). Given that mobile
devices may generate multiple addresses using more than one devices may generate multiple addresses using more than one
interface identifier, this would require DAD for the newly interface identifier, this would require DAD for the newly
generated addresses over the air interface, and a proxy DAD generated addresses over the air interface, and a proxy DAD
function which would increase the complexity and the amount function which would increase the complexity and the amount
of state to be kept in the GGSN. Also, the GGSN would need of state to be kept in the GGSN. Also, the GGSN would need
to determine when the temporary addresses are no longer in to determine when the temporary addresses are no longer in
use which would be difficult. One possible solution could be use which would be difficult. One possible solution could be
Wasserman, Editor Expires May 2002 17 Wasserman, Editor Expires May 2002 18
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
using periodic unicast neighbor solicitations for the using periodic unicast neighbor solicitations for the
temporary addresses [IPV6ND]. temporary addresses [IPV6ND].
Considering all the factors when evaluating the solutions, the Considering all the factors when evaluating the solutions, the
recommendation is to use Solution 1a. This solution requires the recommendation is to use Solution 1a. This solution requires the
least modification to the current 3GPP standards and maintains all least modification to the current 3GPP standards and maintains all
the advantages of the other solutions. the advantages of the other solutions.
Effectively this would mean that each APN in a GGSN would have a Effectively this would mean that each APN in a GGSN would have a
skipping to change at line 884 skipping to change at line 911
Note that the recommended solution does not imply or assume that Note that the recommended solution does not imply or assume that
the mobile device is a router. The MT is expected to use the /64 the mobile device is a router. The MT is expected to use the /64
for itself and may also use this prefix for devices attached to it. for itself and may also use this prefix for devices attached to it.
However this is not necessary if each device behind the MT is However this is not necessary if each device behind the MT is
connected to a separate primary PDP Context and therefore can use a connected to a separate primary PDP Context and therefore can use a
/64 which is not shared with other devices. The MT is also expected /64 which is not shared with other devices. The MT is also expected
to handle DAD locally for devices attached to it (e.g. laptops) to handle DAD locally for devices attached to it (e.g. laptops)
without forwarding Neighbor Solicitations over the air to the GGSN. without forwarding Neighbor Solicitations over the air to the GGSN.
Wasserman, Editor Expires May 2002 18 Wasserman, Editor Expires May 2002 19
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
11 References 11 References
[OLD-TS23060]
TS 23.060, "General Packet Radio Service (GPRS); Service
description; Stage 2", V4.1.0
[NEW-TS23060]
TS 23.060 version 3.11.0 (release 99), 4.4.0 (release 4)
and 5.1.0 (release 5).
[3GPP-URL]
http://www.3gpp.org
[IETF-URL]
http://www.ietf.org
[RFC2026] [RFC2026]
S. Bradner, "The Internet Standards Process -- Revision 3", S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, BCP9, October 1996 RFC 2026, BCP9, October 1996
[KEYWORD] [KEYWORD]
S. Bradner, "Key words for use in RFCs to Indicate Requirement S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP14, March 1999. Levels", RFC 2119, BCP14, March 1999.
[TR21905] [TR21905]
3GPP TR 21.905, "Vocabulary for 3GPP Specifications", V5.0.0 3GPP TR 21.905, "Vocabulary for 3GPP Specifications", V5.0.0
[IPV6]
S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[NAT-PT]
G. Tsirtsis, P. Shrisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC2766, February 2000.
[PPP]
Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[SIIT]
E. Nordmark, "Stateless IP/ICMP Translation Algorithm", RFC
2765, February 2000.
[ADDRARCH] [ADDRARCH]
R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998 RFC 2373, July 1998
[IPV6ND] [IPV6ND]
T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP
Version 6 (IPv6)", RFC 2461, December 1998 Version 6 (IPv6)", RFC 2461, December 1998
Wasserman, Editor Expires May 2002 20
Recommendations for IPv6 in 3GPP Standards April 2002
[AUTOCONF] [AUTOCONF]
S. Thomson, T. Narten, "IPv6 Stateless Address S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998 Autoconfiguration", RFC 2462, December 1998
[TS23060]
TS 23.060, "General Packet Radio Service (GPRS); Service
description; Stage 2", V4.1.0
[PRIVADDR] [PRIVADDR]
T. Narten, R. Draves, "Privacy Extensions for Stateless T. Narten, R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001 Address Autoconfiguration in IPv6", RFC 3041, January 2001
[IPV6ETH] [IPV6ETH]
M. Crawford, "Transmission of IPv6 Packets over Ethernet M. Crawford, "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998 Networks", RFC 2464, December 1998
[PPPv6] [PPPv6]
D. Haskin, E. Allen, "IP Version 6 over PPP", RFC2472, D. Haskin, E. Allen, "IP Version 6 over PPP", RFC2472,
skipping to change at line 941 skipping to change at line 997
[SITEREN] [SITEREN]
C. Huitema, "IPv6 Site Renumbering", draft-huitema-ipv6- C. Huitema, "IPv6 Site Renumbering", draft-huitema-ipv6-
renumber-00.txt, July 2001 renumber-00.txt, July 2001
[HD] [HD]
C. Huitema, A. Durand, "The Host-Density Ratio for Address C. Huitema, A. Durand, "The Host-Density Ratio for Address
Assignment Efficiency: An update on the H ratio", draft- Assignment Efficiency: An update on the H ratio", draft-
durand-huitema-h-density-ratio-02.txt, August 2001 durand-huitema-h-density-ratio-02.txt, August 2001
Wasserman, Editor Expires May 2002 19
Recommendations for IPv6 in 3GPP Standards January 2002
[IABAA] [IABAA]
IAB, IESG, "IAB/IESG Recommendations on IPv6 Address IAB, IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC3177, September 2001. Allocations to Sites", RFC3177, September 2001.
[AAPOL] [AAPOL]
APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and Assignment APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and Assignment
Global Policy". Draft of December, 22 2001, Version 2001-12- Global Policy". Draft of December, 22 2001, Version 2001-12-
22 [ftp://ftp.cs.duke.edu/pub/narten/global-ipv6-assign-2001- 22 [ftp://ftp.cs.duke.edu/pub/narten/global-ipv6-assign-2001-
12-22.txt] 12-22.txt]
skipping to change at line 968 skipping to change at line 1021
[CELLREQ] [CELLREQ]
J. Arkko, et. al, "Minimum IPv6 Functionality for a Cellular J. Arkko, et. al, "Minimum IPv6 Functionality for a Cellular
Host", draft-manyfolks-ipv6-cellular-host-01.txt, September Host", draft-manyfolks-ipv6-cellular-host-01.txt, September
2001 2001
[PREFDEL] [PREFDEL]
J. Martin, B. Haberman, "Automatic Prefix Delegation Protocol J. Martin, B. Haberman, "Automatic Prefix Delegation Protocol
for Internet Protocol Version 6 (IPv6)", draft-haberman- for Internet Protocol Version 6 (IPv6)", draft-haberman-
ipngwg-auto-prefix-01.txt, July 2001 ipngwg-auto-prefix-01.txt, July 2001
Wasserman, Editor Expires May 2002 20 Wasserman, Editor Expires May 2002 21
Recommendations for IPv6 in 3GPP Standards January 2002 Recommendations for IPv6 in 3GPP Standards April 2002
12 Authors and Acknowledgements 12 Authors and Acknowledgements
This document was written by the IPv6 3GPP design team: This document was written by the IPv6 3GPP design team:
Steve Deering, Cisco Systems Steve Deering, Cisco Systems
<deering@cisco.com> <deering@cisco.com>
Karim El-Malki, Ericsson Radio Systems Karim El-Malki, Ericsson Radio Systems
<Karim.El-Malki@era.ericsson.se> <Karim.El-Malki@era.ericsson.se>
skipping to change at line 1015 skipping to change at line 1068
13 Editor's Contact Information 13 Editor's Contact Information
Comments or questions regarding this document should be sent to: Comments or questions regarding this document should be sent to:
Margaret Wasserman Margaret Wasserman
Wind River Wind River
10 Tara Blvd., Suite 330 Phone: (603) 897-2067 10 Tara Blvd., Suite 330 Phone: (603) 897-2067
Nashua, NH 03062 USA Email: mrw@windriver.com Nashua, NH 03062 USA Email: mrw@windriver.com
Wasserman, Editor Expires May 2002 21 Wasserman, Editor Expires May 2002 22
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/