idnits 2.17.1 draft-afifi-igprs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 857 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 285 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 432 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... to the maili...' == Line 17 has weird spacing: '...in full confo...' == Line 18 has weird spacing: '... all provi...' == Line 20 has weird spacing: '...s, and its ...' == Line 25 has weird spacing: '... at any ...' == (280 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'GPRS' on line 751 looks like a reference -- Missing reference section? 'CHAP' on line 748 looks like a reference -- Missing reference section? 'ADDRCONF' on line 756 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Charles Perkins 2 Working Group Nokia Research 3 July 30,2000 Hossam Afifi 4 expires 30 January 2001 INT Evry 6 Internet General Packet Radio Service (IGPRS); Service description 7 draft-afifi-igprs-00.txt 9 Status of this Memo 11 This document is an individual contribution for consideration by the 12 IPNG Working Group of the Internet Engineering Task Force. Comments 13 should be submitted to the mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are 19 working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 We propose an architecture (IGPRS) for the integration of the IPv6 39 protocol in the GPRS infrastructure. The data and signalling 40 protocol suite will be based on mobile IPv6 protocol (instead of 41 the GTP protocol). This new infrastructure will take advantage of 42 the available internet protocols for routing and security. Since it 43 is targetted to co-exist with the GPRS, it is a partial translation 44 of MAP specifications to Internet protocols. This document uses some 45 of the GPRS Service document and some of its terminology. 47 The IGPRS interface will be complementary to GPRS protocols and can 48 co-exist with them. It represents hence a smooth migration to an all 49 IP network. A GPRS terminal that has IGPRS functionality will be 50 able to directly use the internet infrastructure for data and 51 signalling transmission. 52 A GPRS Base Station that has this additional functionality will be 53 able to translate all the traffic coming from an enhanced GPRS 54 terminal 56 Page 1 GPRS Interface to Mobile IPv6 58 to a conventional IPv6 protocol suite. IPv4 can be used by mobile 59 applications but the underlying infrastructure will be only based on 60 IPv6. Transition mechanisms should hence be used when IPv4 is 61 required. 63 Since a large legacy of management protocols is available and 64 necessary in the GPRS/GSM+2 infrastructure and since the GPRS data 65 protocols are designed to co-exist with the GSM, we propose an 66 architecture that supports mobile Ipv6 as the data protocol and 67 diameter as the main signalling protocol (AAA). In the boundaries we 68 propose to interface the internet protocols with the conventional 69 GPRS entities (e.g. HLRs, MSC/VLRs) in order to keep the necessary 70 user management consistency. 71 The resulting architecture is then composed of enhanced Ipv6 GPRS 72 terminals, enhanced GPRS Base stations and enhanced HLR/VLR 73 functionalities capable of dealing with Internet protocols. 75 Table of Contents 77 ---------------------- 79 1. Introduction 81 2. Abbreviations and terminology 83 3. Protocol Overview 85 4. Packet formats 87 5. Procedures 89 6. Security considerations 91 7. Security Function 93 1 . Introduction and scope 95 This document gives the service description of the Internet Based 96 GPRS system (IGPRS) that represents an evolution of the current GPRS 97 service as defined in the document [GPRS]. It is hence mainly 98 compliant with the current GPRS service description principles. It 99 gives the procedures and functionalities that have to be implemented 100 in the terminals and in the network in order to operate an IPv4/IPv6 101 based mobile public data network. This system is designed to run in 102 presence of the conventional GPRS and GSM systems. 104 The base protocol in this architecture is IPv6 and does not at all 105 preclude IPv4 in the mobile node. However, all mobility and 106 signalling procedures are achieved using the v6 version only. IGPRS 107 fully relies on the normal layer 2 GPRS protocols and eventually 108 data compression. The following sections give the detailed operation 109 of the IGPRS system. The rest of this document is organized as 110 follows. Section 2 gives some definitions and abbreviations that 111 will be frequently used in the subsequent sections. Section 3 112 defines the protocol main entities and states describing a mobile 113 node and their relation to Mobile IPv6 states. In Section 4 we 114 describe the packet formats. Section 5 gives the procedures and 115 transitions between the protocol functions. Section 6 gives the 116 security functions necessary for user authentication. 118 2 . Abbreviations and terminology 120 Page 2 GPRS Interface to Mobile IPv6 122 DNS Domain Name Service 124 IGSS Internet GPRS Support Server, it must be a v6 Home Agent. 126 IMSI International Mobile Subscriber Identity 128 NAI Network Access Identifier 130 MIPv6 Mobile IP v6 132 MN Mobile Node 134 PCB Protocol Control Block. Information associated with a node. 136 PLMN Public Land Mobile Network 138 RA Routing Area, A space of administration for a single Home Agent. 140 RAC Routing Area Code; IPv6 Prefix code 142 RAI Routing Area Identity; The canonical Name of the router 143 responsible of the RAC 145 RLC Radio Link Control 147 TLLI Temporary Logical Link Identity 149 TMSI Temporary Mobile Subscriber Identity Regional Registration 150 Identity 152 The GPRS architecture is mainly composed of a mobile node (MS), a 153 base station (BSS), a home agent (SGSN) and databases (HLR). Most of 154 entities in the IGPRS protocol suite are the same as defined in the 155 GPRS infrastructure except for: IGSS, that replaces the SGSN. It is 156 a Home Agent running Ipv6 with additional Diameter, DNS, routing and 157 security functionalities. It can co-exist with an SGSN node. BSS, 158 is the same as in the GPRS network except that it implements 159 IPv4/IPv6 routing functionalities. A BSS may represent a group of 160 layer 2 bridging equipments. It may be capable of header 161 compression/decompression facilities and could be based on a 162 connection oriented layer 2 protocol. 164 The main architecture of this document is based on the integration 165 of the Home Agent entity in the SGSN. A second alternative is 166 possible with the home agent being embedded in the GGSN. We do not 167 consider this architecture in this document and we leave it for 168 further study. 170 3 . Protocol Overview 172 In this section we present the main entities implied in IGPRS. 174 Page 3 GPRS Interface to Mobile IPv6 176 +--------+ +------+ +------+ +--------+-----+ +--------+-----+ 177 |IP/MIP6 | | IP6 | | MIP6 | |Diameter| MAP | |DIAMETER| MAP | 178 |------- | | | | | | | | | | | 179 | LLC | | LLC | +------+ +--------+-----+ +--------+-----+ 180 | RLC | | RLC | 181 | MAC | | MAC | 182 | GSM/RF | |GSM/RF| 183 +--------+ +------+ 185 MN BSS IGSS HLR MSC/VLR(optional) 187 3 . 1 . Protocol Entities 189 IPv6 is implemented on the physical layer and layer 2 of the GPRS 190 protocol. We identify the Mobile node MN, BSS, IGSS, HLR interface 191 and MSC/VLR interface as the entities representing IGPRS. The MN 192 has some interactions with the BSS and others with the IGSS. The BSS 193 is responsible of informing the MN of its location area (the 194 subnetwork in IPv6) and of its Home Agent identity. The IGSS 195 initiates security functions and updates the HLR with any necessary 196 mobility management procedure. The optional dialogue between the 197 IGSS and MSC/VLR is for further study. Mobile IPv6 is only seen 198 between the MN and the IGSS. The rest of the entities are not part 199 of the mobility process. We describe in the following section the 200 interaction of the IPv6 layer with layer 2 states. Some procedures 201 in the IGPRS proposal are timer based and others location based. The 202 first procedures are necessary to save the air interface resources 203 and to rapidely detect any MN disappear. The second set of 204 procedures correspond to mobility management at the network level. 206 The Mobile Node (MN) 208 The v6 Mobility Management (MM) activities related to a IGPRS 209 subscriber are characterized by one of three different states. Each 210 state describes a certain level of functionality and information 211 allocated. It is to be noted that the MN will keep a link local 212 address whenever it has to establish any pre-authentication 213 procedure. Once it has to send user data it should obtain a valid 214 address. This will be explained later. The IPv6 layer will be able 215 to detect at each time the current state of the entity along with 216 the related state variables and to achieve the necessary procedures. 218 IDLE (IGPRS) State 220 In GPRS IDLE state, the subscriber is not attached to the IGPRS 221 mobility management. The MN and IGSS context hold no valid routing 222 information for the subscriber. The subscriber-related mobility 223 management procedures are not performed. The MN does not have a home 224 agent (IGSS) neither. Since the MN listens to multicast layer1 225 physical information it can perform locally PLMN selection and IGPRS 226 cell selection and re-selection processes. Data transmission to and 227 from the mobile node as well as the paging of the subscriber are not 228 possible. The GPRS MN is seen as not reachable in this case. From 229 an IP/IPv6 point of view the node does not have any valid address 230 (except a link local), valid default router or valid home agent 231 information (routing area). In order to establish contexts in the MN 232 and the IGSS, the MN shall perform the IGPRS Attach procedure 233 explained in the Procedures section. 235 STANDBY State 237 Page 4 GPRS Interface to Mobile IPv6 239 In STANDBY state, the subscriber is attached to IGPRS mobility 240 management. The MN and IGSS have established contexts for the 241 subscriber's IMSI/NAI. Pages for data or signalling information may 242 be received. User IPv6 reception and transmission are not possible 243 in this state. The MN performs IGPRS Home Agent selection and IGPRS 244 cell selection and re-selection locally. The MN listens on the 245 broadcast channel to learn about the router advertisement and hence 246 to know its prefix and whether it is still in the same routing area 247 (HA) or not. The MN executes mobility management procedures to 248 inform the IGSS when it has entered a new HA zone. This includes MIP 249 procedures. The MN does not inform the IGSS on a change of cell in 250 the same HA zone. Therefore, the location information in the IGSS 251 context contains only the identification of the MN but not its cell 252 location. The MN may initiate activation or deactivation of contexts 253 while in STANDBY state. A context shall be activated before data can 254 be transmitted or received for this PCB context. The IGSS may have 255 to send data or signalling information to an MN in STANDBY state. 257 Paging in the STANDBY state is accomplished by Neighbour 258 Sollicitation messages sent from the IGSS or BSS. The suffix is 259 simply set to the IMSI identifier. It should be noted that no DAD is 260 to be done on a IGPRS network. Paging may not be an efficient way 261 to reach the MN but the procedure should be implemented to solve at 262 minimum, emergency situations. An alternative to paging is to wait 263 until the node subscribes with a new IGSS or updates the old one 264 through the periodic routing updates as described in the following 265 sections. 267 The MN or the network may initiate the IGPRS Detach procedure to 268 move to the IDLE state. After expiry of the mobile reachable timer 269 the IGSS may perform an implicit detach in order to return in the 270 IGSS to IDLE state. 272 READY State 274 In READY state, the IGSS updates the MN context with its subnetwork 275 (prefix). The MN performs mobility management procedures to provide 276 the network with the actual selected cell (prefix). IGPRS cell 277 selection and re-selection is done locally by the MN, or may 278 optionally be controlled by the network. The MN Prefix is sent 279 periodically to the IGSS via the BSS (the procedure can be achieved 280 with hob-by-hop Options or ICMPv6 messages). When a mobile node 281 makes a handover to a new cell, the default router may or may not 282 change according to the network topology. Two cells may be in the 283 same routing area. However it is good to know the cell identity 284 (that would correspond to some layer two details) for a better 285 interaction with the fixed network. The mobile node learns this 286 information from the radio layer and forwards it to the BSS and IGSS 287 ( through an ICMPv6 or Destination Option). The MN may send and 288 receive Internet PDUs in this state. The network initiates no IGPRS 289 pages for an MN in READY state The IGSS transfers downlink data to 290 the BSS responsible for the subscriber's actual IGPRS cell. 291 Regardless if a radio resource is allocated to the subscriber or 292 not, the MN remains in the READY state even when there is no data 293 being communicated. The READY state is supervised by a timer. An MN 294 context moves from READY state to STANDBY state when the READY timer 295 expires. In order to move from READY state to IDLE state, the MN 296 initiates the IGPRS Detach procedure. This means that the IPv6 297 global address is no more valid. 299 Page 5 GPRS Interface to Mobile IPv6 301 Mobility management in the IGSS side 303 This section describes the additional states that have to be 304 maintained relating IPv6 to the lower layer. The states are mainly 305 related to timers. Some states are kept in both the MN and IGSS. 307 READY Timer Function 309 The READY timer function maintains the READY timer in the MN and 310 IGSS. The READY timer controls the time an MN remains in READY state 311 in the MN and the IGSS. The READY timer shall be reset and begin 312 running in the MN when a packet is transmitted, and in the IGSS when 313 it is correctly received. When the READY timer expires, the MN and 314 IGSS contexts shall return to STANDBY state. The length of the 315 READY timer shall be the same in the MN and IGSS. The initial length 316 of the READY timer shall be defined by a default value. The IGSS, 317 and only the IGSS, may change the length of the READY timer by 318 transmitting a new value in the Attach Accept, Routing Area Update 319 Accept. If the READY timer length is set to zero, the MN shall 320 immediately be forced into STANDBY state. 322 Periodic RA Update Timer Function 324 Routing Area Update functionality is directly coupled with the MIPv6 325 management. The Periodic RA Update Timer function monitors the 326 periodic RA update procedure in the MN. The periodic RA update 327 timer is unique within an RA. Upon expiry of the periodic RA update 328 timer, the MN shall start a periodic routing area update procedure. 330 Mobile Reachable Timer Function 332 The Mobile Reachable Timer function monitors the periodic RA update 333 procedure in the IGSS. The mobile reachable timer shall be slightly 334 longer than the periodic RA update timer used by an MN. The mobile 335 reachable timer is stopped when the READY state is entered. The 336 mobile reachable timer is reset and started when the state returns 337 to STANDBY. If the mobile reachable timer expires, the IGSS shall 338 stop sending IGPRS paging messages to the MN, but other features may 339 happen immediately. 341 4 . Messages Formats 343 This section describes the necessary packet and headers format for 344 IGPRS infrastructure. 345 We identify messages from the MN to the IGSS. From the IGSS to the 346 HLR and vice-versa. 348 Inter IGSS Diameter Extensions: 350 IGSS to HLR Diameter Messages: 352 IPv6 Hop-by-Hop IGSS option: 353 IPv6 Router Sollicitations Authentication Header and options: 355 5 . IGPRS Procedures and Functions 356 In this section we describe the actions that entities have to take 357 to implement the mobility management for IGPRS. We start by 358 describing the functions activated in IPv6 due to the state 359 transitions occuring in both MN and IGSS. We also explain the 360 procedures that are used to accomplish the routing update (change of 361 HA and of default router). 363 Page 6 GPRS Interface to Mobile IPv6 365 5 . 1 . State transition in the MN and IGSS 367 This section gives details on the changes that will happen when a MN 368 goes from one state to the other. These state information are 369 obtained from the lower layers. 371 The movement from one state to the next is dependent on the current 372 state (IDLE, STANDBY, or READY) and the event occurred (e.g., IGPRS 373 attach). We describe the IPv6 necessary actions when such a 374 transition happens. 376 +-------+ +-------+ 377 | IDLE | | IDLE | 378 +-------+ /+-------+ 379 / \ // \ 380 \|/ /|\ /\|/ /|\ 381 | | / | | 382 \ / | \ / 383 +-------+ | +-------+ 384 | READY | /|\ | READY | 385 +-------+ | +-------+ 386 / \ | / \ 387 \|/ /|\ | \|/ /|\ 388 | | | | | 389 \ / \ \ / 390 +-------+ \ +-------+ 391 |STANDBY| \ |STANDBY| 392 +-------+ +-------+ 394 MM states diagrams for MN and IGSS 396 Moving from IDLE to READY: 398 - IGPRS Attach: The MN requests access and a logical link to an IGSS 399 is initiated. 401 Moving from STANDBY to IDLE: 403 - Implicit Detach: The MN and the IGSS shall return to IDLE. 405 - Cancel Location: The IGSS receives a MAP Cancel Location message 406 from the HLR (through the Diameter extensions). 408 Moving from STANDBY to READY: 410 - PDU transmission: The MN sends a packet to the IGSS, possibly in 411 response to a page. 413 - PDU reception: The IGSS receives an IPv6 from the MN. 415 Moving from READY to STANDBY: 417 - READY timer expiry: The MN and the IGSS return to STANDBY state. 419 - Force to STANDBY: The IGSS indicates an immediate return to 420 STANDBY state before the READY timer expires. 422 - Abnormal RLC condition: The IGSS returns to STANDBY state in case 423 of 425 Page 7 GPRS Interface to Mobile IPv6 427 delivery problems on the radio interface or in case of irrecoverable 428 disruption of a radio transmission. 430 Moving from READY to IDLE: 432 - IGPRS Detach: The MN or the network requests to return to IDLE 433 state. The IGSS may delete the MN from its entries. 435 - Cancel Location: The IGSS receives a MAP Cancel Location message 436 from the HLR. 438 Attach Function 440 A IGPRS attach is made to the IGSS. A IGPRS-attached MN makes 441 NAI/IMSI attach via the IGSS. In the attach procedure, the MN shall 442 provide its identity and an indication of which type of attach that 443 is to be executed. The regional Registration should be used as much 444 as possible to prevent too many authentication exchanges with the 445 home IGSS. A Temporary identification should be used (P-TMSI) After 446 having executed the IGPRS attach, the MN is in READY state and the 447 IGSS also. 449 The detailed procedure of an attach function is described here- 450 after: 452 The MN initiates the attach procedure by sending an ICMPv6 router 453 sollicitation message. The BSS, using the DIAMETER Protocol Direct 454 Reboot Indication (IMSI or P-TMSI and old RAI, old P-TMSI Signature) 455 sends a message to the IGSS. On the point to point wireless link the 456 MN sends its IMSI for authentication. NAI/IMSI shall be included if 457 the MN does not have a valid P-TMSI available. If the MN has a valid 458 P-TMSI, then P-TMSI and the old RAI (Prefix) associated with P-TMSI 459 shall be included in the ICMPv6 packet. If the MN identifies itself 460 with P-TMSI and the IGSS has changed since detach, the new IGSS 461 sends an Identification Request (P-TMSI, old RAI, old P-TMSI 462 Signature) diameter message to the old IGSS to request the IMSI. The 463 old IGSS responds with Identification Response (NAI/IMSI, 464 Authentication Triplets). If the MN is not known in the old IGSS, 465 the old IGSS responds with an appropriate error cause. The old IGSS 466 also validates the old P-TMSI Signature and responds with an 467 appropriate error cause if it does not match the value stored in the 468 old IGSS. If the MN is unknown in both the old and new IGSS, the 469 IGSS sends a DIAMETER Home-Agent-MIP-Request (Identity Type = IMSI) 470 to the BSS. The MN responds and the BSS forwards with Identity 471 Response (NAI/IMSI). 473 If the IGSS address has changed since the IGPRS detach, or if it is 474 the very first attach, then the IGSS informs the HLR: The IGSS 475 sends an Update Location (IGSS IPv6 Address, NAI/IMSI) to the HLR 476 through Diameter extensions. The HLR sends Cancel Location (IMSI, 477 Cancellation Type) to the old IGSS with Cancellation Type set to 478 Update Procedure. The old IGSS acknowledges with Cancel Location 479 Ack (IMSI). If there are any ongoing procedures for that MN, the old 480 IGSS shall wait until these procedures are finished before removing 481 the contexts. The HLR sends Insert Subscriber Data (IMSI, IGPRS 482 subscription data) to the new IGSS. The new IGSS validates the MN 483 presence in the (new) RA. If due to regional subscription 484 restrictions the MN is not allowed to attach in the RA, the IGSS 485 rejects the Attach Request with an appropriate cause, and may return 486 an Insert Subscriber Data Ack (IMSI, ) message 487 to the HLR. If subscription checking fails for other reasons, the 488 IGSS 490 Page 8 GPRS Interface to Mobile IPv6 492 rejects the Attach Request with an appropriate cause and returns an 493 Insert Subscriber Data Ack (IMSI, Cause) message to the HLR. If all 494 checks are successful then the IGSS constructs a context for the MN 495 and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 496 The HLR acknowledges the Update Location message by sending an 497 Update Location Ack to the SGSN after the cancelling of old context 498 and insertion of new context are finished. If the Update Location is 499 rejected by the HLR, the IGSS rejects the Attach Request from the MS 500 with an appropriate cause. If the Attach Request cannot be 501 accepted, the IGSS returns an Attach Reject (IMSI, Cause) message to 502 the MN. 504 Detach Function 506 The Detach function allows an MN to inform the network that it wants 507 to make a IGPRS and/or NAI/IMSI detach, and it allows the network to 508 inform an MN that it has been IGPRS-detached or IMSI-detached by the 509 network. The only proposed detach procedure is: - IGPRS detach; 511 The MN is detached from IGPRS either explicitly or implicitly: - 512 Explicit detach: The network or the MN explicitly requests detach. 513 - Implicit detach: The network detaches the MN, without notifying 514 the MN, a configuration-dependent time after the mobile reachable 515 timer expired, or after an irrecoverable radio error causes 516 disconnection of the logical link. In the explicit detach case, a 517 Detach Request (Cause) is sent by the IGSS to the MN, or by the MN 518 to the IGSS. 520 5 . 2 Mobility Management procedures 522 Cell Update Procedure 524 A cell update takes place when the MN enters a new cell inside the 525 current RA and the MN is in READY state. If the RA has changed, a 526 routing area update is executed instead of a cell update. The MN 527 performs the cell update procedure by sending an uplink packet of 528 any type containing the MN identity to the IGSS with a Hop-by-Hop 529 option. In the direction towards the IGSS, the BSS shall add the 530 Cell Global Identity including RAC to all packets. A cell update is 531 any correctly received and valid IPv6 PDU. The IGSS records this 532 change of cell so that further traffic directed towards the MN is 533 conveyed over the new cell. 535 Routing Area Update Procedure 537 A routing area update takes place when a IGPRS-attached MN detects 538 that it has entered a new RA i.e a different Home Agent domain, when 539 the periodic RA update timer has expired, or when a suspended MN is 540 not resumed by the BSS. The IGSS detects that it is the same sub- 541 network. In this case, the IGSS has the necessary information about 542 the MN and there is no need to inform HLR about the new MN location. 543 A periodic RA update is always an intra IGSS routing area update. 545 Intra IGSS Routing Area Update 547 The Intra IGSS Routing Area Update procedure consists in a change of 548 the default router for the MN while keeping the same HA. The MN 549 sends a Routing Area Update Request (it is done via a v6 binding 550 update) (old RAI, old P-TMSI Signature, Update Type) to the IGSS. 551 Update Type shall indicate RA update or periodic RA update. The BSS 552 shall add the Cell Identity as a Hop-by-hop option. The IGSS 553 validates 555 Page 9 GPRS Interface to Mobile IPv6 557 the MN presence in the new RA (sub-network). If due to regional 558 subscription restrictions the MN is not allowed to be attached in 559 the RA, or if subscription checking fails, then the IGSS rejects the 560 routing area update. If all checks are successful then the IGSS 561 updates the MN record. A new P-TMSI may be allocated. A 562 confirmation is sent back to the mobile node (P-TMSI, P-TMSI 563 Signature). If P-TMSI was reallocated, the MN acknowledges the new 564 P-TMSI by returning a routing Area Update Complete AVP to the IGSS. 565 If the routing area update procedure fails a maximum allowable 566 number of times, or if the IGSS returns a routing Area Update Reject 567 (Cause) AVP, the MN shall enter IDLE state. 569 Inter IGSS Routing Area Update 571 The Inter IGSS Routing Area Update procedure is explained in the 572 following list. It consists in a change in the HA for the mobile 573 node. The MN sends a Routing Area Update Request (binding update 574 with the old HA address, old P-TMSI Signature, Update Type) to the 575 new IGSS. Update Type shall indicate RA update or periodic RA 576 update. The BSS shall add the Cell Global Identity in the Hop-by-hop 577 option. The new IGSS sends Diameter AVP containing IGSS Context 578 Request (old RAI, TLLI, old P-TMSI Signature, New IGSS Address) to 579 the old IGSS for this MN. The old IGSS validates the old P-TMSI 580 Signature and responds with an appropriate error cause if it does 581 not match the value stored in the old IGSS. This should initiate the 582 security functions in the new IGSS. If the security functions 583 authenticate the MN correctly, the new IGSS shall send an IGSS 584 Context Request (old RAI, TLLI, MN Validated, New IGSS Address) 585 Diameter message to the old IGSS. MN Validated indicates that the 586 new SGSN has authenticated the MN. These procedures are described in 587 the context of the Diameter extensions in details. If the old P-TMSI 588 Signature was valid or if the new IGSS indicates that it has 589 authenticated the MN, the old IGSS stops assigning forwarding the 590 traffic downlink, and responds with IGSS Context Response. If the MN 591 is not known in the old IGSS, the old IGSS responds with an 592 appropriate error cause. Contrary to the original GPRS mechanism 593 where the SGSN adds a new entity in the chain, the IGSS which is a 594 home agent cannot be changed while active contexts are present. In 595 the absence of active contexts the inter IGSS procedure can be 596 applied. A timer is triggered in the old IGSS. 598 The new IGSS sends an IGSS Context Acknowledge message in the 599 appropriate Diameter format to the old IGSS. This informs the old 600 IGSS that the new IGSS is ready to receive data packets belonging to 601 MN and the necessary DNS procedure are executed to change the MN 602 prefix to the one belonging to the new IGSS. The old IGSS marks in 603 its context that the information in the HLR is invalid. 604 If the security functions do not authenticate the MN correctly, 605 then the routing area update shall be rejected, and the new IGSS 606 shall send a reject indication to the old IGSS. The old IGSS shall 607 continue as if the IGSS Context Request was never received. The new 608 IGSS updates the MN entry (new IGSS Address HA) The new IGSS informs 609 the HLR of the change by sending Update Location (IGSS v6 address, 610 IMSI) to the HLR. The HLR sends Cancel Location (IMSI, Cancellation 611 Type) to the old IGSS with Cancellation Type set to Update Procedure 612 (This is done with the Diameter protocol). Then the old IGSS removes 613 the contexts. Otherwise, the contexts are removed only when the 614 timer expires. This allows the old IGSS to ensure that the contexts 615 are kept in the old SGSN in case the MN initiates another inter IGSS 616 routing area update before completing the ongoing routing area 617 update to the new IGSS. The old IGSS acknowledges with Cancel 618 Location 620 Page 10 GPRS Interface to Mobile IPv6 622 Ack (IMSI) The HLR sends Insert Subscriber Data (IMSI, IGPRS 623 subscription data) to the new IGSS. The new IGSS validates the MN 624 presence in the (new) RA. If due to regional subscription 625 restrictions the MN is not allowed to be attached in the RA, the 626 IGSS rejects the Routing Area Update Request with an appropriate 627 cause, and may return an Insert Subscriber Data Ack message to the 628 HLR. If all checks are successful then the IGSS constructs a context 629 for the MN and returns an Insert Subscriber Data Ack (IMSI) message 630 to the HLR. The HLR acknowledges the Update Location by sending 631 Update Location Ack (IMSI) to the new IGSS. The new IGSS validates 632 the MN presence in the new RA. If due to roaming restrictions the MN 633 is not allowed to be attached in the IGSS, or if subscription 634 checking fails, then the new IGSS rejects the routing area update 635 with an appropriate cause. If all checks are successful then the new 636 IGSS constructs contexts for the MN. The new IGSS responds to the MN 637 with Routing Area Update Accept (P-TMSI, P-TMSI Signature). The MN 638 acknowledges the new P-TMSI by returning a Routing Area Update 639 Complete message to the IGSS. In the case of a rejected routing area 640 update operation, due to regional subscription or roaming 641 restrictions, the new IGSS shall not construct a context. A reject 642 shall be returned to the MN with an appropriate cause. The MN shall 643 not re-attempt a routing area update to that RA. The RAI value shall 644 be deleted when the MN is powered-up. 646 6 . Security Considerations 648 The Security function: 650 - Guards against unauthorised IGPRS service usage (authentication 651 and service request validation). 653 - Provides user identity confidentiality (temporary identification- 654 Regional Registration, and ciphering). 656 - Provides user data confidentiality (ciphering). 658 Authentication of Subscriber 660 Authentication procedures already defined in GSM and in the Diameter 661 strong authentication shall be used, with the distinction that the 662 procedures are executed from the IGSS. The IGSS may act according to 663 Diameter specifications as a proxy in a chain. The IGPRS 664 Authentication procedure performs subscriber authentication, or 665 selection of the ciphering algorithm and the synchronization of the 666 start of ciphering, or both. Authentication triplets are stored in 667 the IGSS. The Authentication procedure is explained in the following 668 list. If the IGSS does not have previously stored authentication 669 triplets, a Send Authentication Info (IMSI) message is sent to the 670 HLR through the Diameter protocol proxying procedures. The HLR 671 responds with a Send Authentication Info Ack (Authentication 672 Triplets) message. Each Authentication Triplet includes RAND, SRES, 673 and Kc. The IGSS sends an Authentication and Ciphering Request 674 (RAND, CKSN, Ciphering Algorithm) message to the MN. The MN 675 responds with an Authentication and Ciphering Response message 676 through Diameter extensions. The MN starts ciphering after sending 677 the Authentication and Ciphering Response message. The IGSS starts 678 ciphering when a valid Authentication and Ciphering Response is 679 received from the MN. In the routing area update case, if ciphering 680 was used before the routing area update, and if the Authentication 681 procedure is omitted, then the IGSS shall resume ciphering with the 682 same 684 Page 11 GPRS Interface to Mobile IPv6 686 algorithm when a ciphered Routing Area Update Accept Diameter 687 message is sent, and the MN shall resume ciphering when a ciphered 688 Routing Area Update Accept Diameter message is received. User 689 Identity Confidentiality A Temporary Logical Link Identity (TLLI) 690 identifies a IGPRS user. The relationship between TLLI and IMSI is 691 known only in the MN and in the IGSS. TLLI is derived from the P- 692 TMSI allocated by the IGSS or built by the MN. The IGSS may 693 reallocate the P-TMSI at any time when the MN is in READY state. The 694 reallocation procedure can be performed by the P-TMSI Reallocation 695 procedure, or it can be included in the Attach or Routing Area 696 Update Diameter procedures. 698 P-TMSI Signature 700 P-TMSI Signature is optionally sent by the IGSS to the MN in Attach 701 Accept and Routing Area Update Accept Diameter messages. If the P- 702 TMSI Signature has been sent by the IGSS to the MN since the current 703 P-TMSI was allocated, then the MN shall include the P-TMSI Signature 704 in the next Routing Area Update Request and Attach Request for 705 identification checking purposes. In the Attach and Routing Area 706 Update procedures, the IGSS shall compare the P-TMSI Signature sent 707 by the MN with the signature stored in the IGSS. If the values do 708 not match, the IGSS should use the security functions to 709 authenticate the MN. If the values match or if the P-TMSI Signature 710 is missing, the IGSS may use the security functions to authenticate 711 the MN. The P-TMSI Signature parameter has only local significance 712 in the IGSS that allocated the signature. If ciphering is supported 713 by the network, the IGSS shall send the P-TMSI Signature ciphered to 714 the MS. Routing Area Update Request and Attach Request, into which 715 the MN includes the P-TMSI Signature, are not ciphered. 717 IMEI 719 This is the identification of the terminal. It can be required by a 720 given operator. It is hence taken into consideration in the security 721 functions. 723 7 . Security Functions 725 P-TMSI Reallocation Procedure 727 This is the procedure by which the MN will obtain a temporary key in 728 the authentication domain of the new IGSS. Diameter messages will 729 help the exchange of keys between the original and the new IGSS. At 730 the end of the procedure the MN should receive a valid P-TMSI using 731 the IKE protocol. 733 Identity Check Procedure 735 The Identity Check procedure is explained in the following list. 737 1) The IGSS sends Identity Request (Identity Type) to the MN. The MN 738 responds with Identity Response (Mobile Identity). 740 2) If the IGSS decides to check the IMEI, it sends Check IMEI (IMEI) 741 Diameter message to the BSS that translates it and forwards it to 742 the MN. 744 0n) References 746 Page 12 GPRS Interface to Mobile IPv6 748 [CHAP] CHAP, PPP Challenge Handshake Authentication Protocol. rfc- 749 1994. 751 [GPRS] Draft ETSI EN 301 344 V6.6.0 (2000-02) European Standard 752 (Telecommunications series) Digital cellular telecommunications 753 system (Phase 2+); General Packet Radio Service (GPRS); Service 754 description; Stage 2 (GSM 03.60 version 6.6.0 Release 1997) 756 [ADDRCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address 757 Autoconfiguration", RFC 2462, December 1998. 759 Authors may be reached at 760 charliep@iprg.nokia.com 761 hossam.afifi@int-evry.fr 763 Page 13 GPRS Interface to Mobile IPv6