Mobile IP Working Group Hossam Afifi INTERNET DRAFT INT Evry 13 February 2002 Charles E. Perkins Hannu Flinck Nokia Research Center Lionel Morand France Telecom RD Internet General Packet Radio Service (IGPRS) Service Description draft-hossam-igprs-01.txt Status of this Memo This document is an individual contribution for consideration by the Mobile IP Working Group of the Internet Engineering Task Force. Comments should be submitted to the mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract We describe a protocol architecture for the integration of Mobile IPv6 into the GPRS architecture (UMTS version). The goal of this architecture is to provide mobility management and authentication to native IP protocols through the legacy cellular signaling. It co-exists with the cellular protocols and re-uses a certain set of them. Moreover, the IGPR architecture supports GPRS roaming by keeping its database (HLR) consistent. The IGPRS architecture is based on a set of servers that co-exist with the GPRS entities and Afifi Perkins Flinck Morand Expires 13 August 2002 [Page i] Internet Draft IGPRS 13 February 2002 hence support GPRS terminals by maintaining the air interface and the necessary state machines. IGPRS is hence a data protocol stack for operators who want to use the UMTS air interface combined with Mobile IP. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page ii] Internet Draft IGPRS 13 February 2002 Contents 1. Introduction 1 2. Scope and Scenario of Operation 1 3. Abbreviations and Terminology 1 3.1. MAP Messages List . . . . . . . . . . . . . . . . . . . . 3 3.2. Functions List . . . . . . . . . . . . . . . . . . . . . 3 3.3. Errors List . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Timers List . . . . . . . . . . . . . . . . . . . . . . . 4 3.5. State List . . . . . . . . . . . . . . . . . . . . . . . 4 3.6. Mobile IPv6 Sub-Options List . . . . . . . . . . . . . . 4 4. Protocol and Architecture Overview 6 4.1. Protocol Entities and Identification . . . . . . . . . . 6 4.1.1. Identification . . . . . . . . . . . . . . . . . 8 4.1.2. Address Assignment and Lower Layer Assumptions . 8 4.2. The Mobile Node and IGSS State Machines . . . . . . . . . 8 4.2.1. PMM-DETACHED State . . . . . . . . . . . . . . . 8 4.2.2. PMM-IDLE State . . . . . . . . . . . . . . . . . 9 4.2.3. PMM-CONNECTED State . . . . . . . . . . . . . . . 9 4.3. State transition in the MN and IGSS . . . . . . . . . . . 9 4.3.1. Moving from PMM-DETACHED to PMM-CONNECTED . . . . 10 4.3.2. Moving to PMM-DETACHED . . . . . . . . . . . . . 10 4.3.3. Moving from PMM-IDLE to PMM-CONNECTED . . . . . . 11 5. Migrating GPRS to IGPRS 11 6. IGPRS Procedures and Functions 11 6.1. Periodic RA Update Timer Function . . . . . . . . . . . . 11 6.2. Mobile Reachable Timer Function . . . . . . . . . . . . . 12 6.3. Attach Function . . . . . . . . . . . . . . . . . . . . . 12 6.3.1. Stateless Address Autoconfiguration . . . . . . . 12 6.3.2. Same Domain Routing Update . . . . . . . . . . . 13 6.3.3. Inter-IGSS Attach . . . . . . . . . . . . . . . . 14 6.3.4. Erroneous Attach . . . . . . . . . . . . . . . . 15 6.4. Detach Function . . . . . . . . . . . . . . . . . . . . . 16 6.5. Updating the HLR . . . . . . . . . . . . . . . . . . . . 16 7. Security Functions and Data Elements 17 7.1. Authentication of Subscriber . . . . . . . . . . . . . . 17 7.2. P-TMSI Signature . . . . . . . . . . . . . . . . . . . . 19 8. Message Formats 20 8.1. IMSI/MSISDN transport in NAI . . . . . . . . . . . . . . 20 Afifi Perkins Flinck Morand Expires 13 August 2002 [Page iii] Internet Draft IGPRS 13 February 2002 8.2. Messages for an attach procedure: first time . . . . . . 20 8.2.1. Messages for attach within the AAA domain . . . . 21 8.2.2. IGSS to HA and HLR . . . . . . . . . . . . . . . 21 8.2.3. AAAH to AAAF IGSS . . . . . . . . . . . . . . . . 23 8.2.4. IGSS to AR . . . . . . . . . . . . . . . . . . . 23 8.2.5. Authentication Error . . . . . . . . . . . . . . 23 8.2.6. Detach . . . . . . . . . . . . . . . . . . . . . 23 8.3. Messages for an attach procedure: inter-IGSS . . . . . . 24 8.3.1. Second Time Attach . . . . . . . . . . . . . . . 24 8.3.2. IGSS Response . . . . . . . . . . . . . . . . . . 24 8.4. Link Layer messages . . . . . . . . . . . . . . . . . . . 24 8.4.1. Router Advertisements . . . . . . . . . . . . . . 24 8.4.2. Link layer indications . . . . . . . . . . . . . 26 8.4.3. Router Advertisements . . . . . . . . . . . . . . 26 8.4.4. Link layer Requirements . . . . . . . . . . . . . 26 9. Additional Security Considerations 27 Addresses 31 Afifi Perkins Flinck Morand Expires 13 August 2002 [Page iv] Internet Draft IGPRS 13 February 2002 1. Introduction The IGPRS architecture aims at the integration of the IPv6 protocol [IPv6 ] in the GPRS [GPRS ] infrastructure. The IGPRS data and signaling protocol suite is based on Mobile IPv6 [mipv6 ]. It uses the existing GPRS infrastructure for lower layer data and signaling transport. Since IGPRS is targeted to co-exist with GPRS, it specifies also a translation of MAP [MAP ] specifications to Internet protocols and the transport of RANAP [RANAP ] into DIAMETER messages. IGPRS uses Mobile IPv6 as the data protocol and DIAMETER [diam ] as the main signaling protocol for Authentication, Authorization, and Accounting [AAA ]. At the boundaries we interface the Internet protocols with the conventional GPRS entities (e.g. HLR) in order to keep the necessary user management consistency. The IGPRS interface will be complementary to GPRS protocols and co-exist with them. Hence, it enables a smooth migration to a Mobile IPv6 enabled network. An IGPRS terminal will be able to directly use the Internet (or intranet) infrastructure for data and signaling transmission. A GPRS Radio Network Controller that has this additional function will be able to translate all the traffic coming from an enhanced GPRS terminal to a conventional IPv6 protocol suite. We assume that the identification of the subscriber is based on the GPRS network procedures, through the use of IMSI or the MSISDN. 2. Scope and Scenario of Operation This specification will produce MIPv6 connectivity in an infrastructure that can be built on top of existing GPRS systems. This infrastructure exploits GPRS lower layer (link and physical). It interworks with HLRs/VLRs. It does not however use GPRS main data plain infrastructure (GTP) since this is provided by Mobile IPv6. This specification allows a Mobile Node to start a session in IGPRS and terminate it in GPRS or vice versa. 3. Abbreviations and Terminology 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 [rfc2119 ]. This document uses terms defined in Mobile IPv6 [mipv6 ], Neighbor Discovery [nd], and Stateless Address Autoconfiguration [AUTO ]. In addition, this document uses the following terms: Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 1] Internet Draft IGPRS 13 February 2002 Access Router (AR) the router offering connectivity to the mobile node at IP network level. HLR The active database storing AAA information in public cellular networks. IGSS Internet GPRS Support Server. The main authentication node. AAAF IMEI Terminal H/W identification. IMSI International Mobile Subscriber Identity. Kc The key used for GSM/GPRS ciphering (8 bytes). Ki The secret key related to an IMSI stored in HLR and MN. NAI Network Access Identifier. MIPv6 Mobile IPv6. MN Mobile Node. MSISDN Mobile Station International ISDN Number RA Routing Area; space of administration for a single IGSS server. RAC Routing Area Code; AR IPv6 address. RAND Random number (16 bytes) used to authenticate GSM/GPRS users. RNC Radio Network Controller. SIM SIM Subscriber Identity Module. SRES Authentication result (4 bytes) obtained by hashing RAND with a secret key. TBF Temporary Block Flows. TLLI Temporary Logical Link Identity. TMSI Temporary Mobile Subscriber Identity (5 bytes). Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 2] Internet Draft IGPRS 13 February 2002 3.1. MAP Messages List The messages in this section are the relevant messages from the MAP specification [MAP ]. Send_Authentic_Info_Ind Sent to the HLR to request authentication information for a given IMSI. Send_Authentic_Info_Pos_Rsp Authentication set list response containing necessary authentication keys for a given IMSI. Check_IMEI_Ind Message Sent to verify the terminal identity through the IMEI identifier. Check_IMEI_Pos_Rsp Answer from the EIR about equipment status SendParameters Operation done by the AAAH to request the MN secret key Ki Update_Location_Ind Message sent to update the HLR for a given IMSI. Update_Location_Pos_Rsp Response to UpdateLocationInd from the HLR. Insert_Subscriber_Data_Req Message sent from the HLR to assert a subscriber in a new authentication server. Cancel_Location_Req Message sent from the HLR to cancel a IMSI entry. Open_Req Message sent to begin a new MAP dialogue between two MAP service users. Close_Req Message sent to release an active MAP dialogue. 3.2. Functions List Attach A set of procedures that enable the mobile node to configure a valid global address. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 3] Internet Draft IGPRS 13 February 2002 Detach A set of procedures to disconnect the mobile node. 3.3. Errors List DIAMETER_ERROR_AUTH_FAILURE Diameter Error when Authentication fails (AMAv6) IGPRS Authentication_Error_Reject Error code sent in BA (code 139). 3.4. Timers List Periodic RA Update Timer Maintained in Mobile Node to send a BU Mobile Reachable Timer Maintained in IGSS to cancel the MN entry 3.5. State List PMM-DETACHED Maintained in the MN. Means that the mobile is not communicating. PMM-IDLE Maintained in Mobile Node and IGSS. Means that the mobile was communicating but that it currently does not have a valid care-of address. PMM-CONNECTED Maintained in the Mobile and IGSS. Means that the authentication and mobility management are up to date and that the mobile can communicate. It means also that a signalling channel is established with the RNC. 3.6. Mobile IPv6 Sub-Options List IMSI Allows the MN to identify itself (BU). Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 4] Internet Draft IGPRS 13 February 2002 MSISDN An option that allows to identify a node by its ITU-T telephone number. P-TMSI An option that allows to send/receive a shared key with the MN (BU and BA). P-TMSI signature An option that enables the MN to sign the P-TMSI sub-option (BU). RAND A Nonce that protects against replay. Previous Care-of Address It allows the MN to advertise about its old address. IMSI Attach Confirm Allows the MN to send its identity and to confirm the attachment to the AR (BU) and then to the IGSS (Optional). DIAMETER Command List and Features AMRv6 AA-Mobile-Node-Request-v6 sent from the AAAF to the AAAH AMAv6 AA-Mobile-Node-Answer-v6 sent from the AAAH to the AAAF HARv6 Home-Agent-Request-v6 Update to the HA sent from the AAAH HAAv6 Home-Agent-Answer-v6 Confirmation from the HA to the AAAH Features MIPv6-Feature-Vector Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 5] Internet Draft IGPRS 13 February 2002 4. Protocol and Architecture Overview In this section we describe the main organization of IGPRS, the different entities and the organization of the overall system. 4.1. Protocol Entities and Identification The GPRS architecture is divided into a control plane and a data plane. It is mainly composed of a mobile node (MN), a base station controler (RNC in UMTS), a tunneling end-point (SGSN), a router to external data networks (GGSN) and databases (HLR and MSC/VLR). Data is tunneled through the GPRS Tunneling Protocol (GTP-U). The figures below show a simplified view of the GPRS data plane. The architecture is different for GSM than for UMTS. MS BSS SGSN GGSN HLR MSC/VLR(optional) +--------+ +------+ +------+ +-----+ +------+ +-----+ |IP | | | | IP | | IP | | MAP | | MAP | |--------| | | | GTP | | GTP | | SS7 | | SS7 | | LLC | | | +------+ +-----+ +------+ +-----+ | RLC | | RLC | | MAC | | MAC | | GSM/RF | |GSM/RF| +--------+ +------+ Figure 1: GPRS protocol and entities in the GSM The proposed IGPRS protocol suite will co-exist with the legacy GPRS (UMTS) infrastructure, re-use most of its components and lower layers and replace it in later versions. We first define the IGSS, which will co-exist with the SGSN. The IGSS is a Authentication-Authorization-Accounting (AAA) server running IPv6 with additional DIAMETER, routing and security functions. It is not simply named a AAA server because it has to support several other procedures that are not in the scope of the AAA. The MIPv6 Home Agent typically co-exists with the GGSN. The RNC implements IP routing and plays the role of an access router. The mobile node implements the GPRS layers in addition to Mobile IPv6. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 6] Internet Draft IGPRS 13 February 2002 MS RNC SGSN GGSN HLR +--------+ +------------+ +----------+ +-----+ +-----+ |IP | | | | | IP | | IP | | MAP | |--------| | | | | GTPr| | GTPr| | SS7 | | RRC | | RRC |RANAP| |RANAP | +-----+ +-----+ | RLC | | RLC |SS7 | | SS7 | | MAC | | MAC | | +----------+ | UTRAN | |UTRAN | | +--------+ +------+-----+ Figure 2: GPRS protocol and entities in the UMTS (Control Plane) AAAF MN RNC IGSS@SGSN HA@GGSN AAAH HLR +------+ +----------+ +--------+ +-----+ +--------+---+ |MIPv6 | |(MIPv6) | |DIAMETER| |MIPv6| |DIAMETER|MAP| |------| |----------| | | | | | | | | PDCP | |PDCP| | +-----+--+ +-----+ +--------+---+ +------+ +----|RANAP| |RANAP| | | UMTS | |UMTS| | +-----+--+ +------+ +----|-----+ @ means co-resident with Figure 3: IGPRS protocols and entities In our design, IPv6 is implemented on top of the physical layer and layer 2 of the GPRS protocol. We identify the Mobile node MN, RNC, IGSS, HLR interface and MSC/VLR interface as the entities representing IGPRS. The MN interacts with the RNC and with its Home Agent. Mobile IPv6 is only seen between the MN, the IGSS (through DIAMETER) and the HA. The rest of the entities are not part of the mobility process. We describe in the following section the interaction of the IPv6 layer with GPRS states. Two groups of procedures in the IGPRS proposal are affected by timers from the GPRS. The first procedures are necessary to save air interface resources and to rapidly detect any MN disappearance. They are the same functions used in the GPRS. The second set of procedures corresponds to mobility management at Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 7] Internet Draft IGPRS 13 February 2002 the network level. The IGSS initiates security functions and updates the HLR with any necessary mobility management information. 4.1.1. Identification The identification of a MN is based on information built in the subscriber identification module. IGPRS can use two different identifiers. The first is the IMSI [imsi ]. It is a number usually assigned with the subscription of the MN to the network. It usually remains hidden in the network and is mainly used in the GPRS/GSM network. The second is the MSISDN. It corresponds to the telephone number assigned to the MN and is a public information. The MN may use two identifications if it needs to authenticate itself to a different ISP than the public operator. 4.1.2. Address Assignment and Lower Layer Assumptions The MN uses Stateless Address Autoconfiguration [AUTO ] and Router Advertisements [nd] to get its careof address. It is to be noted that IGPRS uses one address only for signalling (mobility and authentication). This does not mean that the MN is unable to obtain additionnal addresses. IGPRS is based on the IPv6 specifications and hence a MN can create as many as addresses as necessary by the normal IPv6 configuration procedures. 4.2. The Mobile Node and IGSS State Machines IGPRS Mobility Management for IPv6 is compatible with the three different GPRS states, maintained in both the MN and SGSN. IGPRS uses the same state transition diagram as GPRS. The goal of maintaining these states tight is to piggyback IPv6 mobility management (BU, BA, RA,...) into GPRS Radio Resource (RRC) signaling. Each state describes a certain level of activity and information management. When the mobile node expects to send or receive user data, it configures a valid IPv6 care-of address. The network layer in both the mobile node and IGSS will be able to maintain the current state of the entity along with the related state variables and to achieve the necessary procedures. 4.2.1. PMM-DETACHED State In GPRS PMM-DETACHED state, the subscriber does not execute mobility management procedures. Cached information in the MN and IGSS is not valid. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 8] Internet Draft IGPRS 13 February 2002 Data transmission to and from the mobile node as well as the paging of the MN are not possible in PMM-DETACHED state. The IGPRS mobile node is seen as not reachable in this case. The mobile node does not necessarily have a care-of address or valid default router. It typically maintains its existing home agent and home addresses. In order to establish contexts in the MN and the IGSS, the MN performs the IGPRS Attach procedure explained in Section 6.3. 4.2.2. PMM-IDLE State The PMM-IDLE state is temporary. The MN has been authenticated by IGPRS. The MN and IGSS have established contexts for the user based on the selected identifier (IMSI or MSISDN). Pages for data or signaling information may be received. Data transmission is not possible in this state. The MN listens for router advertisements. Either the MN or the network may initiate the IGPRS Detach procedure (see section 6.4) to move to the PMM-DETACHED state. After the ``mobile-reachable'' timer expires the IGSS may perform an implicit detach in order to return to PMM-DETACHED state. 4.2.3. PMM-CONNECTED State In PMM-CONNECTED state, the IGSS updates the MN state stored locally with its care-of address. The IGSS receives the MN care-of address through DIAMETER extensions as explained in Section 6.3.1. When a mobile node makes a hand-over to a new cell, the default router may change according to the network topology. The MN learns its new default router through router advertisements. It has to periodically authenticate itself through BU messages. The MN may send and receive IPv6 packets in PMM-CONNECTED state. Whether or not a radio resource is allocated to the subscriber, the MN remains in the PMM-CONNECTED state even when no data is being communicated. The PMM-CONNECTED state is controlled by a timer. When the mobile node transitions from PMM-CONNECTED state to PMM-DETACHED state, the information stored in its routing tables node SHOULD be invalidated. The IGSS may also flush the information it has stored concerning the MN. In order to transit from PMM-CONNECTED state to PMM-DETACHED state, the MN initiates the IGPRS Detach procedure (see section 6.4). This means that the mobile node's care-of address is no longer valid. 4.3. State transition in the MN and IGSS This section gives details on the events when a MN changes its state. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 9] Internet Draft IGPRS 13 February 2002 A state transition depends on the current state (PMM-DETACHED, PMM-IDLE, or PMM-CONNECTED) and the event which occurred (e.g., IGPRS attach). We describe the necessary IPv6 actions when each such transition happens. +------------+ +------------+ /|PMM-DETACHED| /|PMM-DETACHED| / +------------+ / +------------+ / / \ / / \ | V ^ | V ^ | | | ^ | | | \ / | \ / | +-------------+ | +-------------+/ \ ^ |PMM-CONNECTED| ^ |PMM-CONNECTED| v | +-------------+ | +-------------+\_/ | / \ | / \ | V ^ | V ^ | | | | | | \ \ / \ \ / \ +--------------+ \ +----------+ \|PMM-IDLE | \| PMM-IDLE| +--------------+ +----------+ MN IGSS Figure 4: MM state diagrams for MN and IGSS 4.3.1. Moving from PMM-DETACHED to PMM-CONNECTED This requires executing the IGPRS Attach procedure. The MN requests access, and a logical link to the AR is set up (see Section 8.4.4). DIAMETER authentication MAY be initiated if necessary (see the different cases in Section 6.3.1). After the state transition is complete, the MN is ready to send and receive data. 4.3.2. Moving to PMM-DETACHED After moving to the PMM-DETACHED state, the MN is not allowed to use its care-of address. A router advertisement with lifetime set to zero will be sent to the node. The care-of address SHOULD be obsoleted by sending a ICMPv6 ``host unreachable'' to the HA. The AR when advised by the IGSS that it should detach the MN will send this ICMPv6 packet. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 10] Internet Draft IGPRS 13 February 2002 The MN goes into PMM-DETACHED state after executing either of these functions: - Detach: The IGSS returns to PMM-DETACHED after expiration of the Mobile Reachable timer. This can happen also in the MN by receiving a ``PMM-IDLE failure'' signal from the MAC layer. The MN may ask explicitly to detach itself by sending a zero lifetime BU to the HA (See Section 6.4). - Cancel_Location: The IGSS acting as a AAAH receives a MAP Cancel_Location_Req message from the HLR. The AAAH forwards a Session Termination DIAMETER message to the HA, a Session Termination DIAMETER message to AAAF and in turn to the access router. The AR sends a ``Router Advertisement'' message with Lifetime set to zero to the MN. 4.3.3. Moving from PMM-IDLE to PMM-CONNECTED The mobile node moves from PMM-IDLE to PMM-CONNECTED state when it sends any packet with IGPRS specific authentication information (note that the packet should contain a BU with P-TMSI, P-TMSI signature sub-options). 5. Migrating GPRS to IGPRS The scope of this section is to define the necessary gateways and protocol conversion functions to let a soft migration between current GPRS Release 99 and Release 4 to IGPRS. This work is in progress. Refer to authors. 6. IGPRS Procedures and Functions This section describes functions related to timers and to mobility management maintained for IGPRS in both the MN and network sides. 6.1. Periodic RA Update Timer Function When the MN sends IPv6 packets to the AR, they are normally routed to their destination. When the MN sends BUs with IGPRS authentication sub-options, they SHOULD be sent to the AR. In this case the AR has to take a specific action concerning IGPRS and build DIAMETER AMR messages as described later. The Periodic Routing Area Update Timer function controls the periodic transmission of BU with IGPRS Authentication messages from the MN. The BU messages containing IGPRS Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 11] Internet Draft IGPRS 13 February 2002 specific authentication data are sent to the AR. They are forwarded through DIAMETER extensions to the IGSS acting as the AAAF for this routing area (this is the same terminology used in GPRS). When the Routing Area update timer expires, the MN starts a Periodic Routing Area Update procedure by sending a binding update to the AR (see Section 6.3.2) with the P-TMSI authentication. 6.2. Mobile Reachable Timer Function The Mobile Reachable Timer function resides in the IGSS. It controls the transition from the PMM-IDLE state to the PMM-DETACHED state. The ``Mobile Reachable Timer'' is slightly longer than the periodic Routing Area update timer used by an MN. It is stopped when the PMM-CONNECTED state is entered, reset and started when the state returns to PMM-IDLE. When the timer expires, no more IGPRS messages are sent to the MN. Therefore, the IGSS acting as AAAF sends a DIAMETER message to the IGSS acting as AAAH that forwards the Session Termination to the HA. 6.3. Attach Function An IGPRS attach is made with the access router, local IGSS, HA and results in validating the MN global IPv6 address. In the attach procedures, the MN provides its identity as explained in Section 7.1. A Temporary identification should also be used (P-TMSI). After having executed the IGPRS attach, the MN is in PMM-CONNECTED state. If the Attach Request cannot be accepted, the IGSS returns a Result code AVP with DIAMETER_ERROR_AUTH_FAILURE error code (see section 8.2.5) in a DIAMETER session termination message. This is sent to the AAAF and AR. The AR sends a BA with Status field set with the Authentication Error code. 6.3.1. Stateless Address Autoconfiguration The attach function covers several situations. The first happens when the MN is attached to the network for the first time. We assume that the MN has pre-configured HA and Home Addresses. If this is not the case, the MN uses the extensions described in [diammip ] in order to ask for a permanent HA. The attach procedure is then augmented in the IGPRS system with an access to the HLR (AAAH may request from its HLR information about the most appropriate HA for the current MN location). Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 12] Internet Draft IGPRS 13 February 2002 Authentication (optional in this version) is performed between the MN and access router using the MIPv6 sub-options field as described in Section 7.1. It is continued between the access router and IGSS with DIAMETER extensions. The current draft specification uses the same authentication procedures as in the GPRS. This leads to an efficient unique authentication. It is also to be noted that ciphering should not be used in the GPRS since it can be replaced by an IPv6 level ciphering according to users needs. In the attach procedure, the MN sends a Binding Update to the HA with a signature involving its secret key. This signature (called SRES in GPRS) is forwarded in a DIAMETER AMRv6 message to the IGSS. After the MN is authenticated, the IGSS may send back a P-TMSI that will be used for any subsequent authentication to the same IGSS. +-------+ MAP +-------+ HAR +-------+ | HLR |------| AAAH |--------| HA | +-------+ +-------+ HAA +-------+ \ \ AMA \AMR \ +------+ BU,BA +----+ AMR +------+ | MN |-------| AR |-----| IGSS | +------+ +----+ AMA +------+ Figure 5: Attach function for a first time 6.3.2. Same Domain Routing Update The attach function in the same AAA domain is faster. The AR receives the BU destination option with the IMSI, P-TMSI, P-TMSI signature and Old Prefix sub-option fields. It is translated to an AMRv6 DIAMETER message and sent to the IGSS acting as the AAAF. This BU is sent to the AR as a destination of the packet. The IGSS validates directly the request without going to the HLR. Upon approving the MN, the IGSS (AAAF) sends back a DIAMETER reply (AMAv6) to the access router to update the MN. The AMRv6 is forwarded in the same time to the HA (across the AAAH) to establish the necessary IPv6 data forwarding. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 13] Internet Draft IGPRS 13 February 2002 AAAF AAAH +------+ BU +----+ AMR +------+ +------+ +----+ | MN |------| AR |------| IGSS |--| IGSS |--| HA | +------+ BA +----+ AMA +------+ +------+ +----+ Figure 6: Attach function for a second time. 6.3.3. Inter-IGSS Attach This function is called an Inter-IGSS attach because it consists in a change of AAAF server for the mobile node. Note that the HA typically SHOULD not change. The MN sends a BU destination option (IMSI, P-TMSI, P-TMSI signature, old prefix) to the access router. The access router builds a DIAMETER AMRv6 message and sends it to the IGSS. The new AAAF IGSS sends DIAMETER Mobile IPv6 Request message to the home IGSS (AAAH) containing its new address. Application level routing in the DIAMETER protocol should be used to force the AMRv6 to go through the previous IGSS. If the MN is still authenticated in this previous IGSS it shall answer with a AMA message. The new IGSS knows about the old one by the Old Prefix information. Application level routing is optional. It corresponds to the GPRS design model and may improve the authentication procedure response time. The AMRv6 message is still forwarded to the AAAH to let the HA update the forwarding tables. An Authentication Request MAP message (see section 6.5) is sent to the HLR to retrieve the necessary information. AAAH sends a DIAMETER Session Termination Indication (STI) to the old IGSS (old AAAF). AAAH updates the HLR with the new AAAF address (MAP Update Location). If the HLR sends back a Insert Subscriber Data with the GPRS subscription information, the AAAH will have to answer back and either confirm or reject the presence of the MN in its routing area (Insert Subscriber Data Ack MAP message). If the security functions fail to authenticate the MN or the MN is not allowed to roam in the area, then the AMRv6 message is rejected, and the new IGSS returns a DIAMETER AMAv6 with Result-Code AVP set to DIAMETER_ERROR_AUTH_FAILURE. The Access Router sends a BA with the IGPRS-authentication-Reject error code (139) Status Field. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 14] Internet Draft IGPRS 13 February 2002 HAAv6 +-------+ MAP +-------+ HARv6+-------+ | |-----+ IGSS +------+ | | HLR | ---+ AAAH |--- | HA | +-------+ / +-------+ \ +-------+ / \ / \ AMRv6 / AMAv6 AMRv6 \ AMAv6 / \ AAAF / \ +----------+ +-----------+ | New IGSS | | Old IGSS | +----------+ +-----------+ | AAAF AMRv6|AMAv6 | +------+ | AR | +------+ RS | RA BU | BA | +-------+ | MN | +-------+ Figure 7: Attach function in a new domain When authentication succeeds the new IGSS updates its own registers with the MN entry (new care-of address and P-TMSI). It sends an AMA message to the access router. The access router returns the BA to the MN containing the new P-TMSI suboption. The MN optionally acknowledges the new P-TMSI by returning an IMSI-Attach confirm sub-option (see section ?? ) to the AR. An access router that receives the packet will have to forward a DIAMETER AMR message to the IGSS containing the MN confirmation in a MIPv6-Feature-AVP. 6.3.4. Erroneous Attach If for any reason, or during an intrusion trial, the MN sends in the BU destination option, a wrong P-TMSI or a wrong signature, the authentication procedure will be longer. The MN will have to authenticate itself like for a first time attach. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 15] Internet Draft IGPRS 13 February 2002 6.4. Detach Function The Detach Function allows an MN to inform the network that it wants to make a IGPRS IMSI detach, and it allows the network to disconnect/inform an MN that it has been IMSI-detached by the network. The Detach is important since it releases air resources and affects charging procedures. The MN is detached from IGPRS either explicitly or implicitly. - Explicit detach: The network or the MN explicitly requests detach. - Implicit detach: The network detaches the MN, without notifying the MN, a configuration-dependent time after the mobile reachable timer expires, or after an unrecoverable radio error causes disconnection of the logical link. In the explicit detach case sent by the node, a BU with Lifetime set to zero is sent to the access router by the MN. The AR sends a Session Termination indication to the AAAF. The DIAMETER message is forwarded to the AAAH that has to notify the HA of detach request in order to stop forwarding packets to the MN. The HA receives an ICMP-Host unreachable message from the Home IGSS (AAAH) for that purpose. In the explicit detach initiated by the network. The same procedure updates the HA and the AR. An ICMP Router Advertisement with Lifetime=0 is sent to the MN IPv6 destination address in order to de-allocate the routing information. 6.5. Updating the HLR When the AAAH receives a DIAMETER AMRv6 message to update the new MN location, it has to update the HLR and the old IGSS. The HLR operations happen before AAAH sends the HARv6 to the mobile node's home agent. The Update Location message contains the SGSN number, IGSS address and IMSI (as required by the GPRS specifications). When the HLR responds with a Cancel Location, the message is proxied by the AAAH and transformed into a DIAMETER Session Termination message. It is sent to the old IGSS. The Session Termination Ack triggers a Cancel Location Ack from the AAAH to the HLR with the IMSI parameter. The Insert Subscriber Data message is necessary to confirm that both mobility and authentication were valid in the HLR side. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 16] Internet Draft IGPRS 13 February 2002 AAAH HA HLR Old-AAAF New-AAAF --------- --- ------ -------- ------- +--- MAP Update Location--->+ +<-----Cancel Location------+ + + +----- HARv6---> +<-----HAAv6---+ +-------DIAMETER Session Termination------>+ +<-----DIAMETER Session Termination Ack----+ + + +----Cancel Location Ack--->+ +<--Insert Subscriber Data--+ +----------------- DIAMETER AMAv6---------------------->+ +-Insert Subscr. Data Ack-->+ Figure 8: AAAH dialogue with HLR, using MAP messages, for mobility management 7. Security Functions and Data Elements IGPRS provides a number of security functions serving the following purposes: - Guard against unauthorized IGPRS service usage (authentication and service request validation from the HLR). - Enable user identity confidentiality by providing P-TMSI. (see section 7.1). It is optional in this version of draft. It can complement GPRS authentication [SEC ] by using some of its parameters (IMSI, P-TMSI) and it can replace it. A dual authentication is also possible (GPRS-UMTS and IGPRS) and it can help in situation where the operator is different than the ISP, keeping still one single authentication. 7.1. Authentication of Subscriber Authentication procedures already defined in GSM and in the DIAMETER will be used, with the distinction that the procedures executed between the Home IGSS and the HLR are the GSM functions and those executed between the IGSS and the MN (passing by the AR) are those defined in the AAA framework. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 17] Internet Draft IGPRS 13 February 2002 AAAH HLR Old-AAAF New-AAAF --------- ------ -------- ------- + + +<--------------------DIAMETER AMRv6-------------------+ + + +--- Send Authentication--->+ + + (when the MN is new to the AAAH) +<---Send Authent. Ack------+ + + + + +----------------- DIAMETER AMAv6---------------------->+ Figure 9: AAAH dialogue with HLR, using MAP messages, for authentication When a mobile node camps on a new cell (with new prefix), it will receive the router advertisement. The MN proceeds like in the GSM/GPRS system and uses the Ki to crypt the challange. The MN issues a BU with the following sub-option: IMSI, P-TMSI, P-TMSI signature, SRES and old prefix. The AR should build a DIAMETER AMRv6 message with the following AVPs: - The IMSI should be inserted in the MN NAI. If the MSISDN is used then we add another NAI. - The P-TMSI should be inserted as a P-TMSI NAI. - The P-TMSI signature sould be inserted as a MN-Reg-Request AVP. - The Challange is inserted in a Nonce AVP. - The Challenge response (SRES) is sent in the Reg. Req Avp. If the AAAF has already authenticated the MN (it compares the IMSI (or MSISDN), P-TMSI with its local information) it will issue an AMA message to the AR and the AR forwards a BA to the MN. If not, the AAAF forwards this information to the AAAH. The AAAH obtains information about the subscriber using the IMSI (or MSISDN). It sends a Authentication_Info_Request MAP message to the HLR. The HLR responds with an Authentication_Info_Ack. The AAAH proceeds further and asks for the MN secret key with the SendParameters MAP operation where the ``Ki Requested'' argument is set. When the HLR gives back the secret key to the AAAH, the AAAH will be able to apply the secret key on the random number (Nonce or RAND) and to compare it with SRES. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 18] Internet Draft IGPRS 13 February 2002 MN AR AAAF AAAH HLR --------- ---- ----- ---- --- Periodic RA+RAND +<-----------------------+ + + + + +-BU (IMSI,PTMSI,SRES)-->+ + +---AMR---->+ + + (when the + + MN is new + to the AAAH) ++---AMR------>+ + Request_Ki + Authenticate ++<--AMA-------+ + +<--AMA-----+ +<--------BA(PTMSI)------+ Figure 10: AAA Procedure in details If this comparison is successful the AAAH proceeds with the HARv6 and AMAv6 messages. If the comparison fails the AAAH sends back a failure to the AAAF as described in the DIAMETER protocol with the Authentication_Failure error. In case of failure the AR sends a BA with the status field set to the appropriate error. Upon success, the AAAF will receive an AMAv6 message. It may construct a P-TMSI and a P-TMSI signature. They are forwarded to the AR in the same AVPs described in the previous paragraph. The AR constructs a BA, inserts the P-TMSI and P-TMSI signature. It sends the BA to the MN. 7.2. P-TMSI Signature P-TMSI Signature is optionally sent by the IGSS to the MN. If the P-TMSI Signature has been sent by the IGSS to the MN since the current P-TMSI was allocated, then the MN includes the P-TMSI Signature in future Binding Updates for identification checking purposes. The access router forwards this sub-option in the DIAMETER AMR message. In the Routing Update procedure, the IGSS compares the P-TMSI Signature sent by the MN with the signature stored in the IGSS. If the values do not match, the IGSS should send a DIAMETER AMA Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 19] Internet Draft IGPRS 13 February 2002 error to the AR. The AR sends back the BA with Authentication error (Status field) to the MN. The P-TMSI Signature parameter has only local significance in the IGSS that allocated the signature. 8. Message Formats This section describes the format for IGPRS messages. We identify messages from the MN to AR, from the AR to the IGSS, between IGSS (serving either as AAAF or AAAH) and from the IGSS to the HLR. AAAH translates DIAMETER messages into the MAP protocol. Finally we identify messages from the Home IGSS (AAAH) to the HA. 8.1. IMSI/MSISDN transport in NAI The IMSI and P-TMSI are sent in Sub-Options from the MN to the AR, and as an NAI in the DIAMETER messages. The IMSI is a 15 digits maximum length number. The coded form for the IMSI in BU is the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| status| IMSI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ status: 4 bits field 0000 Normal Operation 0001 Attach Confirm Figure 11: Sub-Option Type should contain the IMSI-Attach Type 8.2. Messages for an attach procedure: first time As described earlier, the attach can happen in these three contexts: 1. first time attach, 2. intra-IGSS attach, and 3. the inter-IGSS attach. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 20] Internet Draft IGPRS 13 February 2002 We describe the messages sent from and to the MN in the first case. 8.2.1. Messages for attach within the AAA domain The MN uses a P-TMSI and a P-TMSI signature to authenticate itself when it is not the first time attach. This is carried in two separate Sub-Options in BUs. The Sub-Option length should be expressed as in the GPRS [24.08 ] standard. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P-TMSI | Sub-Option Len| padding | octet 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 3 | 4 | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The signature Sub-Option contains hexadecimal code obtained by hashing the P-TMSI and by using the IMSI related secret code algorithms. The Sub-Option length should be expressed in bytes (this is typically three bytes). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P-TMSI Sign | Sub-Option Len| hexadecimal value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the BU is received in the AR. The IGPRS specific sub-options are extracted. The IMSI, MSISDN and P-TMSI are coded as NAIs as follows: IMSI(in decimal digits notation)@imsi.gprs MSISDN (in decimal)@msisdn.gprs P-TMSI (in hexadecimal)@p-tmsi.gprs 8.2.2. IGSS to HA and HLR The IGSS acting as AAAF sends through DIAMETER Mobile IP Registration request the received parameters to the AAAH. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 21] Internet Draft IGPRS 13 February 2002 ::= [ // IMSI or MSISDN ] // SRES [] [] [] [ | // Old P-TMSI ] // Old Prefix // RAND //P-TMSIsigna* *ture It is to be noted that for minimizing additional protocol extensions to IGPRS, the SRES field is sent in the MIP-Reg-Request AVP. Specifically in the Identification field as shown in the figure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification = SRES + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- It sends a Send_Authentication_Info message to the HLR and receives a Send_Authentication_Info_Ack message. The AAAH updates the HA with the new MN address after receiving Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 22] Internet Draft IGPRS 13 February 2002 the confirmation from the HLR through the HARv6 message. ::= ] 8.2.3. AAAH to AAAF IGSS When the HLR sends an answer to the AAAH. It is forwarded to the AAAF with a AA-Mobile-Node-v6-Answer: ::= [] [] [] // New P-TMSI [ ] //P-TMSI Sign. 8.2.4. IGSS to AR The IGSS will make the necessary authentication locally and send Binding Acknowledgment with the new P-TMSI sub-option (Section 7.2). 8.2.5. Authentication Error In case of authentication failure or denial of service, the IGSS sends back an Authentication Error Result AVP. It is forwarded in the BA with the status field set to Authentication Error. 8.2.6. Detach The MN may detach itself by sending a BU to the HA with Lifetime set to zero. Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 23] Internet Draft IGPRS 13 February 2002 8.3. Messages for an attach procedure: inter-IGSS 8.3.1. Second Time Attach When the MN has already a valid P-TMSI, it will send it along with the signature in two Sub-Options to the IGSS. 8.3.2. IGSS Response The response contains the same information as in the first attach, i.e. the P-TMSI and P-TMSI signature. 8.4. Link Layer messages This section describes the procedures that have to be implemented in the MAC layer to fulfill the necessary IGPRS functions. We identify two messages carrying IGPRS signalling. The first is the Activate PDP Context. It is sent simultaneously with the GPRS attach message. It corresponds to the first BU sent from the mobile node. The second is the Routeing Area Update Request. It is sent twice from the MN to the Network. In the first Routeing Area Update, a normal GPRS message is sent. In the second, the information related to the BU is inserted in the message. Before we give the details of these RRC messages, we have to describe the mapping between Routeing Area Identity and IPv6 prefix. 8.4.1. Router Advertisements The periodic physical broadcast layer messages corresponding to the GPRS information have to be translated in the MN into Router Advertisement messages in IPv6. RAC has hence to be translated into IPv6 prefix. The structure of a Routeing Area Identity is as follows. +----------------------------------------------+-------+ | 8 7 6 4 3 2 1 | | |------------------------------------------------------| | Routing Area Identification IEI |octet 1| | MCC digit 2 MCC digit 1 |octet 2| | MNC digit 3 MCC digit 3 |octet 3| | MNC digit 2 MNC digit 1 |octet 4| | LAC |octet 5| | LAC contd |octet 6| | RAC |octet 7| +------------------------------------------------------+ Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 24] Internet Draft IGPRS 13 February 2002 The first BU sent from the node is encapsulated in a ACTIVATE PDP Context message. +------------------------------------------+ |IEI Information Element Length| |Protocol discriminator 1/2 | |Transaction identifier 1/2- 3/2| |Activate PDP context req. message id. 1 | |Requested NSAPI 1 | |Requested LLC SAPI 1 | |Requested QoS 12 | |Requested PDP address(Home Address) 17 | |Access point name (BU) 102 | |Protocol configuration options 3-253 | +------------------------------------------+ As we can see from the ACTIVATE PDP CONTEXT message, the BU is inserted in the field usually reserved for a domain name. Additionnally, the Home Address corresponding to the Mobile Node is inserted in the Requested PDP Address. The PDP Type ``IGPRS'' will have to be inserted in the Protocol Configuration Option in order to inform the network that this is not a normal GPRS terminal but one supporting IGPRS specifications. The remaining procedure corresponds to the periodic Routeing Area Updates and to Routeing Area Updates sent when the MN camps in a new routing are. When the GPRS layers are notified by a change in the Routeing Area Identity, a router advertisement is generated locally to inform the IPv6 layer of the change in the routing subnet. This triggres the normal GPRS Routeing Area Update Request procedure and triggers the IGPRS Routeing Area Request message. +---------------------------------------------------------------+ | Field Type Length | | Protocol discriminator 1/2 | | Skip indicator 1/2 | | Routing area update request message identity 1 | | Update type 1/2 | | GPRS ciphering key sequence number 1/2 | | Old routing area identification 6 | | MS Radio Access capability 6-52 | | Old P-TMSI signature 4 | | Requested READY timer value 2 | | DRX parameter 3 | | TMSI status 1 | Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 25] Internet Draft IGPRS 13 February 2002 | P-TMSI Mobile identity 7 | | MS network capability 4/10 | | Access point name (BU) 102 | +---------------------------------------------------------------+ Note also that in the Routeing Area Update used for IGPRS, the Update Type is set to IGPRS (bits=111) so that there is no possible confusion with other messages or syntax errors. The BU is sent in the Access point Name field that is not usually used in the routeing area update. 8.4.2. Link layer indications The GPRS layer has to send Network Unreachable and Link layer failure whenever this happens. The mobile node receives these messages and responses by the appropriate MIPv6 signalling as described in the document. 8.4.3. Router Advertisements The periodic physical broadcast layer messages corresponding to the GPRS information have to be translated in the MN into Router Advertisement messages in IPv6. RAI has hence to be translated into IPv6 addresses. When this message is refreshed in the lower layers a MAC layer frame is constructed and furnished to the IPv6 layer. For IPv6 protocol integrity, this function has to be implemented on both sides on of the link. The router advertisement contains also the RAND number used to generate SRES in the MN. 8.4.4. Link layer Requirements In the GPRS system, the layer 2 for GPRS services is composed of four sublayers comprising : - Radio Resource Management (RR) functions; - Mobility Management (GMM and GMM-AA); - Logical Link Control (LLC); - Connection Management (CM) functions. - Session Management (SM) functions to activate, modify and delete the contexts for packet data protocols (PDP) Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 26] Internet Draft IGPRS 13 February* * 2002 - supporting functions for short messages service conrol. Since IGPRS replaces many of the GPRS functions, all the described messages will be sent from the MN as GRR-Data-Req messages, with SAPI=signalling and LLC-UNI parameters. The normal data messages will go through the User services (SNDCP) payload as described in [4.07 ]. A Temporary Block Flow (TBF) is a physical connection used by the two Radio Resource entities to support the unidirectional transfer of LLC PDUs on packet data physical channels. 9. Additional Security Considerations The security of IGPRS depends on the security functions provided in Mobile IPv6 as well as the basic security architecture defined for GPRS. References [3gpp] . All the documents and drafts are available at http://www.3gpp.or* *g/3G_Specs/spec_series.htm . [RANAP] 3GPP TS 25.413 V3.3.0 (2000-09). Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface RANAP Signalling (Release 1999). [imsi] . ETSI EN 300 927 V5.4.0 (2000-08) Digital cellular telecommunications system (Phase 2+); Numbering, addressing and identification (GSM 03.03 version 5.4.0 Release 1996). [SEC] 3GPP TS 33.102 V3.6.0 (2000-10) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (Release 1999). [nai] B. Aboba, M. Beadles. January The Network Access Identifier. RFC 2486. [dhcp] J. Bound, M. Carney, C. Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Internet Draft. 5 May 2000. [diammip] . Calhoun, C. Perkins. DIAMETER Mobile IP Extensions. Internet Draft. September 2000. [diam] P. Calhoun, A. Rubens, H. Akhtar. E. Guttman. DIAMETER Base Protocol. Internet Draft. July 2000 Afifi Perkins Flinck Morand Expires 13 August 2002 [Page* * 27] Internet Draft IGPRS 13 February * *2002 [AAA] S. Farrell et Al. "AAA Authorization Requirements," , October 1999. [AUTO] S. Thomson, T. Narten. Request For Comments: 2462. IPv6 Stateless Address Autoconfiguration [GPRS] 3GPP TS 23.060 V3.5.0 (2000-10). Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2 (Release 1999). [imsi] SM ETSI TS 100 977 V8.3.0 (2000-08). RTS/SMG-091111Q8R1. Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface (GSM 11.11 version 8.3.0 Release 1999). [ICMPv6] A. Conta, S. Deering.Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Request for Comments: 2463 [IPv6] B. Hinden, S. Deering. IP Version 6 Addressing Architecture. Request for Comments: 2373. July 1998 [mipv6] D. Johnson, C. Perkins. Mobility Support in IPv6. Internet Draft. 27 April 2000 ETSI ETS 300 599 ed.9 (2000-08) Draft [MAP] RE/TSGN-040902PR9. Digital cellular telecommunications system (Phase 2); Mobile Application Part (MAP) specification (GSM 09.02 version 4.19.0) [nd] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments: 2461. December 1998 [imsi] . ETSI EN 300 927 V5.4.0 (2000-08) Digital cellular telecommunications system (Phase 2+); Numbering, addressing and identification (GSM 03.03 version 5.4.0 Release 1996). [4.07] Digital cellular telecommunications system (Phase 2+); Mobile radio interface signalling layer 3; General aspects (GSM 04.07 version 7.3.0 Release 1998). [24.08] 3GPP TS 24.008 V3.5.0 (2000-09). Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface layer 3 specification; Core Network Protocols - Stage 3 (Release 1999) [4.60] ETSI EN 301 349 V8.4.0 (2000-05) Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control/ Medium Access Control (RLC/MAC) protocol (GSM 04.60 version 8.4.0 Release 1999). Afifi Perkins Flinck Morand Expires 13 August 2002 [Page * *28] Internet Draft IGPRS 13 February* * 2002 [NAI] B. Aboba, M. Beadles. January The Network Access Identifier. RFC 2486. [dhcp] J. Bound, M. Carney, C. Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Internet Draft. 5 May 2000. [rfc2119] S. Bradner Key words for use in RFCs to Indicate Requirement Levels.Request for Comments: 2119. IETF. [diammip] P. Calhoun, C. Perkins. DIAMETER Mobile IPv6 Extensions. Internet Draft. Work in Progress. September 2000. [nasreq] P. Calhoun, W. Bulley, A. Rubens, J. Haag. DIAMETER NASREQ Extensions Internet Draft. IETF. [mipnai] P. Calhoun, C. Perkins. Mobile IP Network Access Identifier Extension for IPv4. Request for Comments: 2794. March 2000 [diam] P. Calhoun, A. Rubens, H. Akhtar. E. Guttman. DIAMETER Base Protocol. Internet Draft. July 2000 [AAA] S. Farrell et Al. "AAA Authorization Requirements," , October 1999. [MIPCHAP] C. Perkins, P. Calhoun. Mobile IPv4 Challenge/Response Extensions. INTERNET DRAFT June 2000. [IGUA] R. Hinden, M. O'Dell, S. Deering. An IPv6 Aggregatable Global Unicast Address Format. Request for Comments: 2374. [AUTO] S. Thomson, T. Narten. Request For Comments: 2462. IPv6 Stateless Address Autoconfiguration [GPRS] ETSI EN 301 113 V6.3.0 (2000-07). REN/TSGS-010260Q6R2. Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Service description; Stage 1 (GSM 02.60 version 6.3.0 Release 1997) [imsi] SM ETSI TS 100 977 V8.3.0 (2000-08). RTS/SMG-091111Q8R1. Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface (GSM 11.11 version 8.3.0 Release 1999). [ICMPv6] A. Conta, S. Deering.Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Request for Comments: 2463 [IPv6] B. Hinden, S. Deering. IP Version 6 Addressing Architecture. Request for Comments: 2373. July 1998 Afifi Perkins Flinck Morand Expires 13 August 2002 [Page* * 29] Internet Draft IGPRS 13 February 2* *002 [mipv6] D. Johnson, C. Perkins. Mobility Support in IPv6. Internet Draft. 27 April 2000 ETSI ETS 300 599 ed.9 (2000-08) Draft [MAP] RE/TSGN-040902PR9. Digital cellular telecommunications system (Phase 2); Mobile Application Part (MAP) specification (GSM 09.02 version 4.19.0) [nd] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments: 2461. December 1998 Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 3* *0] Internet Draft IGPRS 13 February 2002 Addresses Questions about this memo can also be directed to the authors: Hossam Afifi Charles E. Perkins Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2768 Phone: +1-650 625-2986 EMail: hossam@iprg.nokia.com EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Hannu Flinck Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2402 EMail: hannu.flinck@nokia.com Fax: +1 650 625-2502 Afifi Perkins Flinck Morand Expires 13 August 2002 [Page 31]