idnits 2.17.1 draft-yokota-mipshop-pfmipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 759. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 777. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 783. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 461 has weird spacing: '... S flag not...' -- 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.) -- The document date (June 2007) is 6153 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-00 ** Obsolete normative reference: RFC 4068 (ref. '3') (Obsoleted by RFC 5268) ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2486 (ref. '5') (Obsoleted by RFC 4282) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yokota 3 Internet-Draft KDDI Lab 4 Intended status: Standards Track K. Chowdhury 5 Expires: December 3, 2007 Starent Networks 6 R. Koodli 7 Nokia Research Center 8 B. Patil 9 Nokia Siemens Networks 10 June 2007 12 Fast Handovers for PMIPv6 13 draft-yokota-mipshop-pfmipv6-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on December 3, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document specifies the usage of FMIPv6 when Proxy Mobile IPv6 is 47 applied for the mobility management protocol. Necessary amendments 48 are shown for FMIPv6 to work under the condition that the mobile node 49 does not have IP mobility functionality and it is not involved with 50 either MIPv6 or FMIPv6 operations. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 7 58 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 14 59 5.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 14 60 5.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . . . 15 61 5.3. Context Request Option . . . . . . . . . . . . . . . . . . 16 62 5.4. NAI Option . . . . . . . . . . . . . . . . . . . . . . . . 17 63 5.5. Tunnel-ID Option . . . . . . . . . . . . . . . . . . . . . 18 64 5.6. New option-code for the IP Address Option . . . . . . . . 18 65 5.7. Vendor Specific Option . . . . . . . . . . . . . . . . . . 18 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 67 7. Normative References . . . . . . . . . . . . . . . . . . . . . 21 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 69 Intellectual Property and Copyright Statements . . . . . . . . . . 23 71 1. Requirements notation 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [1]. 77 2. Introduction 79 Proxy Mobile IPv6 [2] provides IP mobility to a mobile node that does 80 not have Mobile IPv6 [4] functionality. The proxy agent in the 81 network performs the signaling and does the mobility management on 82 behalf of the mobile node. Although the signaling between the mobile 83 node and the network can be saved, the basic performance for handover 84 such as handover latency is considered to be not different from that 85 of Mobile IPv6. 87 To improve handover latency due to Mobile IPv6 procedures, fast 88 handovers for MIPv6 is specified in FMIPv6[3]. By applying the 89 FMIPv6 solution to Proxy MIPv6 as well, it is expected that the 90 handover latency due to Proxy MIPv6 procedures will be improved as 91 much. However, Mobile IPv6 and Proxy MIPv6 are intrinsically 92 different in the sense that the mobile node is not involved with IP 93 mobility and hence does not directly handle the care-of address. 94 Hence, there are some issues in directly applying the original 95 specifications of FMIPv6 to Proxy MIPv6. This document identifies 96 those differences and specifies amendments to apply FMIPv6 solution 97 principles to Proxy MIPv6. 99 3. Terminology 101 This document refers to [2][3][4] for terminology. The following 102 terms and abbreviations are additionally used in this document. The 103 reference network is illustrated in Figure 1. 105 Previous Access Network (P-AN): 106 The access network to which the MN is attached before handover. 108 New Access Network (N-AN): 109 The access network to which the MN is attached after handover. 111 Previous Mobile Access Gateway (PMAG): 112 The MAG that manages mobility related signaling for the MN 113 before handover. In this document, the MAG and the Access 114 Router (AR) are collocated. 116 New Mobile Access Gateway (NMAG): 117 The MAG that manages mobility related signaling for the MN after 118 handover. 120 HO-Initiate: 121 A generic signaling that indicates the handover of the MN sent 122 from the P-AN to the PMAG. While this signaling is dependent on 123 the access technology, it is assumed that HO-Initiate can carry 124 the information to specify the MN and to help the PAR resolve 125 the NAR (e.g. the new access point or base station to which the 126 MN is moving to). 128 +----------+ 129 | LMA | 130 | | 131 +----------+ 132 / \ 133 / \ 134 / \ 135 +........../..+ +..\..........+ 136 . +-------+-+ .______. +-+-------+ . 137 . | PAR |()_______)| NAR | . 138 . | (PMAG) | . . | (NMAG) | . 139 . +----+----+ . . +----+----+ . 140 . | . . | . 141 . ___|___ . . ___|___ . 142 . / \ . . / \ . 143 . ( P-AN ) . . ( N-AN ) . 144 . \_______/ . . \_______/ . 145 . | . . | . 146 . +----+ . . +----+ . 147 . | MN | ----------> | MN | . 148 . +----+ . . +----+ . 149 +.............+ +.............+ 151 Figure 1: Reference network for fast handover 153 4. Proxy-based FMIPv6 Protocol Overview 155 To reduce the handover latency due to signaling between the MAGs 156 (Mobile Access Gateways) and the LMA (Local Mobility Anchor), FMIPv6 157 in this document specifies a bi-directional tunnel between the 158 Previous MAG (PMAG) and the New MAG (NMAG). To expedite sending the 159 Proxy Binding Update (PBU) by the NMAG, FMIPv6 protocol is also used 160 for context transfer, whereby the necessary information for sending 161 the PBU is transferred from the PMAG. 163 In this document, the Previous Access Router (PAR) and New Access 164 Router (NAR) are interchangeable with the PMAG and NMAG, 165 respectively. 167 Since the MN is not directly involved with IP mobility, it is natural 168 to think that the MN is not directly involved with fast handover 169 procedures, either at least from the IP layer perspective. 170 Therefore, among the messages for fast handovers defined in RFC4068, 171 those that are initiated by and targeted to the MN are not used when 172 PMIPv6 is in use. Such messages are the Router Solicitation for 173 Proxy Advertisement (RtSolPr), Proxy Router Advertisement (PrRtAdv), 174 Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and 175 Fast Neighbor Advertisement (FNA). 177 RFC4068 specifies two types of fast handovers; the predictive fast 178 handover and the reactive fast handover. In the predictive fast 179 handover, the MN sends the FBU to the PAR before handover, which then 180 triggers to establish a bi-directional tunnel between the PAR and NAR 181 to transfer packets for the MN. On the other hand, in the reactive 182 fast handover, the FBU is sent by the MN to the NAR after it has 183 moved to the new network, which is then transferred to the PAR to 184 trigger to send the Handover Initiate (HI) towards the NAR. Based on 185 the above observations, the fast handover procedures for PMIPv6 need 186 to work without the involvement of the MN. Figure 2 illustrates the 187 predictive fast handover procedures for PMIPv6, where the bi- 188 directional tunnel establishment is initiated by the PAR. 190 PMAG NMAG 191 MN P-AN N-AN (PAR) (NAR) LMA 192 | | | | | | 193 | Report | | | | | 194 (a) |-(MN ID,-->| | | | | 195 | New AP ID)| | | | | 196 | | HO Initiate | | | 197 (b) | |--(MN ID, New AP ID)-->| | | 198 | | | | | | 199 | | | | HI | | 200 (c) | | | |-(MN ID, ->| | 201 | | | |MN-HoA,LMA)| | 202 | | | | | | 203 (d) | | | |<---HAck---| | 204 | | | | (MN ID) | | 205 | | | | | | 206 (e) | | | |==DL data=>| | 207 | | | | | | 208 (f) ~~~ | | | | | 209 ~~~ | | | | | 210 | MN-AN connection | AN-MAG connection | | 211 (g) |<---establishment---->|<----establishment----->| | 212 | | | (substitute for FNA) | | 213 | | | | | | 214 (h) |<==================DL data=====================| | 215 | | | | | | 216 (i) |===================UL data====================>|# | 217 | | | #|<==========|# | 218 | | | #|===================>| 219 / | | | | | | \ 220 |(j) | | | | |--PBU-->| | 221 | | | | | | | | 222 |(k) | | | | |<--PBA--| | 223 \ | | | | | | / 225 Figure 2: Predictive fast handover for PMIPv6 (PAR initiated) 227 The detailed descriptions are as follows: 229 (a) The MN detects that a handover is imminent and reports the 230 identifications of itself (MN ID) and the access point (New AP ID) 231 to which the MN is most likely to move. These IDs can be Link- 232 Layer Addresses (LLAs) or any other types of IDs. This step is 233 access technology specific. In some cases, the P-AN will figure 234 out which AP ID the MN is moving to. 236 (b) The previous access network (P-AN), to which the MN is currently 237 attached, indicates the handover of the MN to the PAR (PMAG). 239 (c) The PAR sends the HI to the NAR. The HI message MUST include 240 the MN ID and SHOULD include the MN-HoA and the address of the LMA 241 that is currently serving the MN. 243 (d) The NAR sends back the Hack to the PAR. At this point, the bi- 244 directional tunnel between the PAR and NAR is established. 246 (e) Packets destined for the MN are transferred from the PAR to the 247 NAR over the tunnel that is established at the previous step. 248 After detunneling, those packets may be buffered at the NAR based 249 on the U flag in the HI message. If the connection between the 250 N-AN and NAR has already been established, those packet may reach 251 the N-AN (access technology specific). 253 (f) The MN hands over to the New Access Network (N-AN). 255 (g) The MN establishes a connection (e.g. radio channel) with the 256 N-AN, which in turn triggers the establishment of the connection 257 between the N-AN and NAR if it has not been established, yet 258 (access technology specific). This can be regarded as a 259 substitute for the FNA. 261 (h) The NAR starts to transfer packets destined for the MN via the 262 N-AN. 264 (i) The uplink packets from the MN are sent to the NAR via the N-AN 265 and the NAR forwards them to the PAR. The PAR then sends the 266 packets to the LMA that is currently serving the MN. 268 (j) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA, 269 whose address can be obtained in (c). Steps (j) and (k) are not 270 part of the fast handover procedure, but shown for reference. 272 (k) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the 273 NAR (NMAG). From this time on, the packets to/from the MN go 274 through the NAR instead of the PAR. 276 According to Section 4 of RFC4068, the PAR establishes a binding 277 between the PCoA and NCoA to forward packets for the MN to the NAR, 278 and the NAR creates a proxy NCE to receive those packets for the NCoA 279 before the MN arrives. In the case of PMIPv6, however, the only 280 address that is used by the MN is MN-HoA, so the PAR transfers the 281 packets for the MN to the NAR instead of the NCoA. The NAR then 282 simply detunnels (decapsulates) those packets and delivers them to 283 the MN. If the NAR obtains the LLA (=MN ID) and MN-HoA by the HI, it 284 can create the NCE for the MN and deliver packets to it before the MN 285 performs the ND. For the uplink packets from the MN after handover 286 in (i), the NAR forwards the packets to the PAR through the tunnel 287 established in step (d). The PAR then decapsulates and sends them to 288 the LMA. 290 The IP addresses in the headers of those user packets are summarized 291 below: 293 In (e), 295 Inner source address: IP address of the CN 297 Inner destination address: MN-HoA 299 Outer source address: IP address of the PAR (PMAG) 301 Outer destination address: IP address of the NAR (NMAG) 303 In (h), 305 Source address: MN-HoA 307 Destination address: IP address of the CN 309 In (i), 311 - from the MN to the NMAG, 313 Source address: MN-HoA 315 Destination address: IP address of the CN 317 - from the NMAG to the PMAG, 319 Inner source address: MN-HoA 321 Inner destination address: IP address of the CN 323 Outer source address: IP address of the NAR (NMAG) 325 Outer destination address: IP address of the LMA 327 - from the PMAG to the LMA, 328 Inner source address: MN-HoA 330 Inner destination address: IP address of the CN 332 Outer source address: IP address of the PAR (PMAG) 334 Outer destination address: IP address of the LMA 336 If the network that the MN has moved in does not support PMIPv6 but 337 only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6 338 at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA 339 in steps (j) and (k). If this is the case, the LMA and HA will most 340 likely be collocated and the LMA (HA) address should be maintained in 341 the new network for communication continuity. Since the LMA (HA) 342 address is transferred to the NAR in step (c), the MN can retrieve it 343 at or after step (g) by e.g. the authentication or DHCP procedure 344 (not shown in the figure). 346 In the case of the reactive handover for PMIPv6, since the MN does 347 not send either the FBU or FNA, it would be more natural that the NAR 348 sends the HI to the PAR after the MN has moved to the new network. 349 Figure 3 illustrates the reactive fast handover procedures for 350 PMIPv6, where the bi-directional tunnel establishment is initiated by 351 the NAR. 353 PMAG NMAG 354 MN P-AN N-AN (PAR) (NAR) LMA 355 | | | | | | 356 (a) ~~~ | | | | | 357 ~~~ | | | | | 358 | MN-AN connection | AN-MAG connection | | 359 (b) |<--establishment-->|<-------establishment------>| | 360 | (MN ID) | (MN ID) | | 361 | | |(substitute for FNA and FBU)| | 362 | | | | | | 363 | | | | HI | | 364 (c) | | | |<---(MN ID) ---| | 365 | | | | | | 366 | | | | HAck | | 367 (d) | | | |---(MN ID, --->| | 368 | | | | MN-HoA, LMA) | | 369 | | | | | | 370 (e) | | | |===DL data====>|# | 371 |<====================DL data====================|# | 372 | | | | | | 373 (f) |=====================UL data===================>|# | 374 | | | #=|<==============|# | 375 | | | #=|=======================>| 376 / | | | | | | \ 377 |(g) | | | | |--PBU-->| | 378 | | | | | | | | 379 |(h) | | | | |<--PBA--| | 380 \ | | | | | | / 382 Figure 3: Reactive fast handover for PMIPv6 (NAR initiated) 384 The detailed descriptions are as follows: 386 (a) The MN hands over from the P-AN to the N-AN. 388 (b) The MN establishes a connection (e.g. radio channel) with the 389 N-AN, which triggers the establishment of the connection between 390 the N-AN and NAR. The MN ID is transferred to the NAR for the 391 subsequent procedures. This can be regarded as a substitute for 392 the FNA and FBU. 394 (c) The NAR sends the HI to the PAR. The HI message MUST include 395 the MN ID. The Context Request Option MAY be included to 396 request additional context information on the MN to the PAR. 398 (d) The PAR sends back the HAck to the NAR. The HAck message MUST 399 include the MN-HoA that is corresponding to the MN ID in the HI 400 message and SHOULD include the LMA address that is currently 401 serving the MN. The context information requested by the NAR 402 MUST be included. At this point, the bi-directional tunnel 403 between the PAR and NAR is established. 405 (e) Packets destined for the MN are transferred from the PAR to the 406 NAR over the tunnel that is established at the previous step. 407 After detunneling, those packets are delivered to the MN via the 408 N-AN. 410 (f) The uplink packets from the MN are sent to the NAR via the N-AN 411 and the NAR forwards them to the PAR. The PAR then sends the 412 packets to the LMA that is currently serving the MN. 414 Steps (g)-(h) are the same as (j)-(k) in the predictive fast handover 415 procedures. 417 In step (c), The IP address of the PAR needs to be resolved by the 418 NAR to send the HI to the PAR. This information may come from the 419 N-AN or some database that the NAR can access. 421 Also, in step (c), the NAR could send an unsolicited HAck message to 422 the PAR, which then triggers the HI message from the PAR. By doing 423 so, the directions of HI/HAck messages are aligned with the 424 predictive (PAR-initiated) fast handover. Further study is needed if 425 this call flow is more appropriate than the current one. 427 5. Message Format 429 This document extends the HI and HAck to work with PMIPv6 and further 430 defines new options and option-codes for the IP Address option to 431 convey context information. 433 5.1. Handover Initiate (HI) 435 0 1 2 3 436 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 437 +--------------+--------------+--------------------------------+ 438 | Type | Code | Checksum | 439 +--------------+-+-+-+--------+--------------------------------+ 440 | Subtype |S|U|P|Reserved| Identifier | 441 +--------------+-+-+-+--------+--------------------------------+ 442 | Options ... 443 +------------------------ 445 IP Fields: 447 Source Address 449 The IP address of PAR or NAR 451 Destination Address 453 The IP address of the peer AR 455 All the other fields follow RFC4068. 457 ICMP Fields: 459 Code not used when P flag is set and MUST be set to zero. 461 S flag not used when P flag is set and MUST be set to zero. 463 U flag Buffer flag. Same as RFC4068. 465 P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed 466 for the mobility management protocol. All the involved 467 nodes MUST perform based on this document for fast handover 468 procedures. 470 All the other fields follow RFC4068. 472 Valid options: 474 MN ID This identifier can be the link-layer address of the MN or 475 any other type of information that can uniquely identify 476 the MN (e.g. IMSI or NAI). This option MUST be included 477 so that the destination can recognize the MN. If the link- 478 layer address is used, the Link-Layer Address (LLA) option 479 defined in RFC4068 MUST be used. 481 MN-HoA This information is stored in the IP Address option. 483 Context Request Option Context Request Option This option is used to 484 request context information typically by the NAR to the PAR 485 in the NAR-initiated fast handover. 487 5.2. Handover Acknowledge (HAck) 489 0 1 2 3 490 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 491 +--------------+--------------+--------------------------------+ 492 | Type | Code | Checksum | 493 +--------------+-+------------+--------------------------------+ 494 | Subtype |P| Reserved | Identifier | 495 +--------------+-+------------+--------------------------------+ 496 | Options ... 497 +------------------------ 499 IP Fields: 501 Source Address 503 Copied from the destination address of the 504 Handover Initiate message to which this message 505 is a response. 507 Destination Address 509 Copied from the source address of the Handover 510 Initiate message to which this message is a 511 response. 513 All the other fields follow RFC4068. 515 ICMP Fields: 517 Code: 519 0: Handover Accepted 521 128: Handover Not Accepted 523 129: Administratively prohibited 525 130: Insufficient resources 527 P flag Proxy flag. When set, PMIPv6 instead of MIPv6 is assumed 528 for the mobility management protocol. All the involved 529 nodes MUST perform based on this document for fast handover 530 procedures. 532 Valid options: 534 MN ID Copied from the corresponding HI message. 536 MN-HoA Stored in the IP Address option so that the NAR can use 537 this address for the PBU. 539 LMA Stored in the IP Address option so that the NAR can use 540 this address for the PBU. 542 Requested option(s) All the other context information requested by 543 the Context Request Option in the HI message. 545 5.3. Context Request Option 547 This option is sent in the HI message to request context information 548 on the MN. 550 0 1 2 3 551 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 552 +---------------+---------------+---------------+---------------+ 553 | Type | Length | Option-Code | Reserved | 554 +---------------------------------------------------------------+ 555 | Reserved | 556 +---------------+---------------+-------------------------------+ 557 | Req-type-1 | Req-option-1 | Padding | 558 +---------------------------------------------------------------+ 559 | Padding | 560 +---------------+---------------+-------------------------------+ 561 | Req-type-2 | Req-option-2 | Vendor-ID | 562 +-------------------------------+-------------------------------+ 563 | Vendor-ID | VS-Type | 564 +---------------------------------------------------------------+ 565 | ... | 567 Context Request Option is typically used for the reactive (NAR- 568 initiated) fast handover mode to retrieve the context information 569 from the PAR. When this option is included in the HI message, the 570 requested option(s) MUST be included in the HAck message. 572 Type TBD 574 Length Number of requested context(s)+1. 576 Option-Code 0 578 Req-type-n The Type value for the requested option. 580 Req-option-n The Option-Code for the requested option. 582 Padding 6 octets of padding are added if the requested type is 583 not the Vendor-Specific Option. MUST be set to zero. 585 Vendor/Org-ID Defined in the Vendor Specific Option. 587 VS-Type Defined in the Vendor Specific Option. 589 5.4. NAI Option 591 0 1 2 3 592 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 593 +---------------+---------------+---------------+---------------+ 594 | Type | Length | Option-Code | NAI-Length | 595 +---------------------------------------------------------------+ 596 | NAI ... 597 +------------------------------ 599 This option is used to transfer the Network Address Identifier 600 (NAI)[5] of the MN. 602 Type TBD 604 Length The size of this option is in 8 octets including the 605 Type, Length and Option-Code. 607 Option-Code 0 609 NAI-Length The length of the NAI in octets. 611 NAI The NAI value in a string format. 613 5.5. Tunnel-ID Option 615 This option is used to transfer additional information that 616 associates the MN with the tunnel used by the MN. The exact format 617 of the Tunnel-ID is outside the scope of this document. 619 0 1 2 3 620 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 621 +---------------+---------------+---------------+---------------+ 622 | Type | Length | Option-Code | TID-Length | 623 +---------------------------------------------------------------+ 624 | Tunnel-ID ... 625 +------------------------------ 627 Type TBD 629 Length The size of this option is in 8 octets including the 630 Type, Length and Option-Code. 632 Option-Code 0 634 NAI-Length The length of the Tunnel-ID in octets 636 Tunnel-ID The Tunnel-ID value. 638 5.6. New option-code for the IP Address Option 640 To convey the MN-HoA and LMA in the HI or HAck message, new Option- 641 Codes for the IP Address Option[3] are defined: 643 Option-Code 645 4 MN-HoA 647 5 LMA 649 5.7. Vendor Specific Option 651 This option is to send other information than defined in this 652 document. Many of the context information can be vendor specific 653 (access technology specific). This option is used for such 654 information. 656 0 1 2 3 657 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 658 +---------------+---------------+---------------+---------------+ 659 | Type | Length | Option-Code | Reserved | 660 +---------------------------------------------------------------+ 661 | Vendor/Org-ID | 662 +-------------------------------+-------------------------------+ 663 | VS-Type | VS-Length | 664 +---------------------------------------------------------------+ 665 | VS-Value ... 666 +------------------------------ 668 Type TBD 670 Length The size of this option is in 8 octets including the 671 Type, Length and Option-Code. 673 Option-Code 0 675 Vendor/Org-ID The SMI Network Management Private Enterprise Code of 676 the Vendor/Organization as defined by IANA. 678 VS-Type The type of the Vendor-Specific information carried in 679 this option. The type value is defined by the vendor 680 or organization specified by Vendor/Org-ID. 682 VS-Length The length of the Vendor-Specific information carried 683 in this option. 685 VS-Value The value of the Vendor-Specific information carried 686 in this option. 688 6. Security Considerations 690 Security issues for this document follow those for PMIPv6[2] and 691 FMIPv6[3]. In this document, it is assumed that the PAR (PMAG), NAR 692 (NMAG) and LMA have trust relationship with each other and the 693 connection between any pair is securely protected. 695 7. Normative References 697 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 698 Levels", BCP 14, RFC 2119, March 1997. 700 [2] Gundave, S., Ed., "Proxy Mobile IPv6", 701 draft-ietf-netlmm-proxymip6-00.txt, April 2007. 703 [3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068, 704 July 2005. 706 [4] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. 708 [5] Aboba, B. and M. Beadles, "The Network Access Identifier", 709 RFC 2486, January 1999. 711 Authors' Addresses 713 Hidetoshi Yokota 714 KDDI Lab 715 2-1-15 Ohara, Fujimino 716 Saitama, 356-8502 717 JP 719 Email: yokota@kddilabs.jp 721 Kuntal Chowdhury 722 Starent Networks 723 30 International Place 724 Tewksbury, MA 01876 725 US 727 Email: kchowdhury@starentnetworks.com 729 Rajeev Koodli 730 Nokia Research Center 731 975 Page Mill Road, Suite 200 732 Palo Alto, CA 94304 733 US 735 Email: rajeev.koodli@nokia.com 737 Basavaraj Patil 738 Nokia Siemens Networks 739 6000 Connection Drive 740 Irving, TX 75039 741 US 743 Email: basavaraj.patil@nsn.com 745 Full Copyright Statement 747 Copyright (C) The IETF Trust (2007). 749 This document is subject to the rights, licenses and restrictions 750 contained in BCP 78, and except as set forth therein, the authors 751 retain all their rights. 753 This document and the information contained herein are provided on an 754 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 755 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 756 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 757 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 758 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 759 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 761 Intellectual Property 763 The IETF takes no position regarding the validity or scope of any 764 Intellectual Property Rights or other rights that might be claimed to 765 pertain to the implementation or use of the technology described in 766 this document or the extent to which any license under such rights 767 might or might not be available; nor does it represent that it has 768 made any independent effort to identify any such rights. Information 769 on the procedures with respect to rights in RFC documents can be 770 found in BCP 78 and BCP 79. 772 Copies of IPR disclosures made to the IETF Secretariat and any 773 assurances of licenses to be made available, or the result of an 774 attempt made to obtain a general license or permission for the use of 775 such proprietary rights by implementers or users of this 776 specification can be obtained from the IETF on-line IPR repository at 777 http://www.ietf.org/ipr. 779 The IETF invites any interested party to bring to its attention any 780 copyrights, patents or patent applications, or other proprietary 781 rights that may cover technology that may be required to implement 782 this standard. Please address the information to the IETF at 783 ietf-ipr@ietf.org. 785 Acknowledgment 787 Funding for the RFC Editor function is provided by the IETF 788 Administrative Support Activity (IASA).