idnits 2.17.00 (12 Aug 2021) /tmp/idnits14161/draft-muhanna-netlmm-pmipv6-support-transient-coa-01.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 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 615. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 25, 2008) is 5192 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) -- Looks like a reference, but probably isn't: 'MN-ID' on line 431 -- Looks like a reference, but probably isn't: 'HNP1' on line 431 -- Looks like a reference, but probably isn't: 'IF1' on line 431 == Unused Reference: '6' is defined on line 537, but no explicit reference was found in the text == Outdated reference: draft-ietf-netlmm-proxymip6 has been published as RFC 5213 ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) -- Unexpected draft version: The latest known version of draft-muhanna-netlmm-multihoming-support is -00, but you're referring to -01. == Outdated reference: draft-ietf-netlmm-pmip6-ipv4-support has been published as RFC 5844 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group A. Muhanna 3 Internet-Draft Nortel 4 Intended status: Standards Track S. Krishnan 5 Expires: August 28, 2008 Ericsson 6 K. Leung 7 Cisco 8 B. Patil 9 Nokia Siemens Networks 10 February 25, 2008 12 Proxy MIPv6 Support of Transient Registration 13 draft-muhanna-netlmm-pmipv6-support-transient-coa-01.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 August 28, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 In order for the local mobility anchor to receive and forward uplink 47 traffic for a mobile node, Proxy Mobile IPv6 base protocol mandates 48 the LMA to have an active BCE with a registered proxy CoA that is the 49 other end of the tunnel between the LMA and MAG. In some systems and 50 during active inter-MAG handoff with traffic that is sensitive to 51 delay and packet loss, the LMA is required to forward uplink traffic 52 for the mobile node from the target MAG without completely switching 53 the tunnel from the source MAG. This document specifies a mechanism 54 which allows the target MAG to perform transient registration for a 55 new proxy CoA and the LMA to create a transient BCE for the same 56 mobile node for a specified period of time while maintaining the 57 original mobile node's BCE which reference the old pCoA at the source 58 MAG. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions used in this document . . . . . . . . . . . . . . 4 64 3. PMIPv6 Transient Registration Overview . . . . . . . . . . . . 5 65 4. Transient Registration Option . . . . . . . . . . . . . . . . 6 66 5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 8 67 6. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 10 68 7. Transient Binding Cache Entries Update . . . . . . . . . . . . 10 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 11.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . . . 16 78 1. Introduction 80 Proxy Mobile IPv6 is a network-based mobility protocol which provides 81 IP mobility for a mobile node without the involvement of the IPv6 82 host. Whenever a mobile node is attached to a PMIPv6 domain via a 83 mobility access gateway, it appears to the mobile node as if it is 84 attached to the same home link and thus the mobile node may think 85 that it is not roaming away from home. In the case of mobile node 86 active inter-MAG handoff from the source to the target MAG, the 87 target MAG usually sends a proxy BU message to the mobile node local 88 mobility anchor to update the mobile node BCE with a new pCoA. As 89 soon as the LMA receives and successfully processes the proxy BU from 90 the target MAG, LMA updates the mobile node BCE with the new care of 91 address and switch the tunnel to the target MAG. 93 However, during active inter-MAG handoff scenario, some of the mobile 94 node uplink traffic may still be in transit through the previous MAG. 95 In addition, in some active handoff scenarios, it is necessary to 96 prepare the target MAG prior to completion of link layer handoff 97 procedures. In some systems, the target MAG will be the recipient of 98 uplink traffic prior to the completion of the procedure that would 99 result in the PBU/PBA. Currently and as per PMIPv6 base protocol 100 [1], LMA routes the mobile node's uplink traffic received from a 101 tunnel as long as the source IP address of the mobile node's uplink 102 traffic matches the IP address of the mobile node's registered pCoA 103 in an active BCE. 105 This document specifies an enhancement to Proxy MIPv6 base protocol 106 to support transient registration. This process allows the target 107 mobile access gateway to request the local mobility anchor to create 108 a transient binding cache entry with uplink traffic forwarding 109 capabilities for a specified period of time while still maintaining 110 the active state for the existing BCE, i.e., sending and receiving 111 traffic on both directions. Eventually and after a short lived 112 lifetime, the mobile node transient BCE is updated to regular BCE and 113 the original regular BCE is removed as described in Section 6 115 This mechanism is critical for reducing handoff latency and will be 116 an important parameter for real-time applications such as VoIP. It 117 is assumed that inter-MAG handoff is carried out with a central 118 entity that is responsible for the mobile node context transfer 119 across the source and target MAGs. 121 2. Conventions used in this document 123 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC2119 [2]. 127 General mobility terminology can be found in [5], [3], and [1]. The 128 following additional or clarified terms are used in this document: 130 Proxy BCE (pBCE): 132 The mobile node BCE that has the same characteristics as the MN 133 BCE in PMIPv6 base protocol [1]. 135 Transient BCE (tBCE): 137 The mobile node BCE that is created by the process described in 138 this document. The tBCE is short lived with a lifetime that is no 139 more than the transient registration lifetime. When LMA creates 140 such transient BCE, it allows uplink traffic from the mobile node 141 while the mobile node is in the process of moving from sMAG to the 142 tMAG. 144 Transient Registration (tReg.) 146 The mechanism which allows the LMA to create a transient BCE for a 147 specific mobile node with uplink traffic forward capability from a 148 care-of address different than the current proxy care-of address 149 that is registered in the mobile node current regular BCE. During 150 the lifetime of the tBCE, the LMA may forward the mobile node 151 uplink traffic from both care-of addresses to the internet while 152 sending the downlink traffic to the source care-of address. 154 Source MAG (sMAG): 156 The mobile access gateway that the mobile node is currently 157 attached to and moving from its area coverage to another MAG. 159 Target MAG (tMAG): 161 The mobile access gateway that the mobile node is moving to its 162 area of coverage and attaches to during an inter-MAG handoff 163 scenario. 165 Source proxy Care-of Address (s-pCoA): 167 The mobile node proxy care-of address that is hosted at the sMAG 168 and currently referenced in the mobile node regular BCE before the 169 transient registration starts. 171 Transient proxy Care-of Address (t-pCoA): 173 The mobile node's proxy care-of address that is hosted at tMAG and 174 has been registered by the tMAG during a mobile node transient 175 registration procedure. It is the pCoA in an active tBCE. 177 3. PMIPv6 Transient Registration Overview 179 Several scenarios have been identified relevant to PMIPv6 support for 180 mobile nodes multihoming where a mobile node is multihomed through 181 different interfaces simultaneously accessing the same PMIPv6 domain. 182 Transient multihoming scenario has been described in [4] where a 183 mobile node is transitionally multihomed using different proxy 184 care-of addresses for a short period of time. This transient 185 multihoming scenario is enabled through PMIPv6 support of transient 186 registration. 188 During active inter-MAG handoff scenario, a transitional period of 189 time requires the LMA in the PMIPv6 domain to accept uplink traffic 190 for the same mobile node but through different MAGs. Context 191 transfer is assumed to provide the needed mobile node information and 192 parameters to enable the target MAG to send a proxy BU message with 193 the same HNP and interface ID, however, with an indication that the 194 current registration is a transient registration with a short 195 lifetime. As soon as the LMA receives a P-BU with transient 196 registration mobility option, the LMA identifies the mobile nodes 197 current pBCE which reflects the s-pCoA and creates a new tBCE with a 198 lifetime as specified in the TRO lifetime field. Additionally, the 199 LMA tags the tBCE as uplink traffic forwarding as per the traffic 200 direction in the TRO. Figure 1 shows a mobile node binding cache 201 entry state during inter-MAG active handoff using a single interface 202 to access the PMIPv6 domain. 204 Mobile node's BCE States @ LMA 205 ============================== 206 Before tReg. 207 MN-if1 [prefix1 @ sMAG] [pBCE] 209 During tReg. 210 MN-if1 [prefix1 @ tMAG] [tBCE] 211 MN-if1 [prefix1 @ sMAG] [pBCE] 213 After tReg. 214 MN-if1 [prefix1 @ tMAG] [pBCE] 215 MN-if1 [prefix1 @ sMAG] [removed] 217 +=====+ if1 +------+ +------+ 218 | MN |---------->| | | | 219 +=====+ | tMAG |\ +=================+ | | 220 | | | \ / \ | | 221 ^ +------+ \ / IPv6/IPv4 Transport \ | L | 222 MN +---+ ...... +----| M | 223 Handover +------+ / \ IPv6/IPv4 Transport / | A | 224 ^ | | / \ / | | 225 ...^... if1 | sMAG |/ +=================+ | | 226 | MN |...........| | | | 227 ....... +------+ +------+ 229 |<------------------ PMIPv6 Domain ---------------->| 231 Figure 1: PMIPv6 Transient Multihoming during Inter-MAG handoff Over 232 one Interface. 234 It is assumed that during the active inter-MAG handoff and when the 235 tMAG sends a P-BU for a new transient BCE, the mobile node is homed 236 at the target MAG. However, in order to guarantee safe and on time 237 delivery of the uplink and downlink traffics, a transient BCE with 238 uplink traffic forwarding capability is necessary. During the tBCE 239 lifetime, the LMA continue to send all of the mobile node downlink 240 traffic to the sMAG. It is also assumed that the source MAG is aware 241 of the mobile node's current point of attachment and forward all of 242 the downlink traffic to the mobile node accordingly. 244 4. Transient Registration Option 246 Transient Registration Option, TRO, is included in the P-BU message 247 by the tMAG to indicate to the LMA that it is requesting the 248 registration and creation of a transient BCE with the criterias as 249 defined in the TRO. The source IP address of the P-BU is considered 250 the transient CoA while the lifetime field specifies the transient 251 BCE lifetime in one-tenth of seconds. The transient traffic field 252 specifies the traffic forwarding capability throughout the tBCE 253 lifetime, which in this case is limited to uplink only. The 254 Transient Registration option has an alignment requirement of 4n+2. 255 Its format is as shown in Figure 2 below. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Reserved (R) | Trans. Traffic| Transient BCE Lifetime | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2: Transient Registration Option Format 267 Type 268 270 Length 271 8-bit unsigned integer indicating the length in octets of this 272 option, excluding the type and length fields. The value of this 273 field must be set to 4. 275 Reserved (R) 276 This 8-bit field is unused for now. The value MUST be initialized 277 to 0 by the sender and MUST be ignored by the receiver. 279 Transient Traffic Direction 280 This 8-bit field is used as a bit-wise field to specify the 281 transient traffic direction. The following values are specified. 283 00000001 Uplink Traffic Forward Capability 284 All remaining Values are reserved. 286 Transient BCE Lifetime 287 This 16-bit field specify the requested lifetime for the transient 288 BCE in the number one-tenth of a second. 290 5. Mobile Access Gateway Operation 292 During the mobile node inter-MAG handoff process, the target MAG gets 293 the current mobile node BCE information through an out of scope 294 context transfer mechanism. It is assumed that the target MAG have 295 access to the mobile node ID, HNP, Interface ID. When the target MAG 296 receives the indication that the mobile node is moving from the 297 source MAG access network area to the target MAG area, the target MAG 298 sends a PBU on behalf of the mobile node. In this PBU, the target 299 MAG specifies the MN-ID, HNP, and the interface ID as per PMIPv6 base 300 protocol. 302 On the other hand, the target MAG sets the HI to 3 and includes the 303 transient registration option to indicate to the LMA that this 304 registration is a transient registration P-BU and the LMA needs to 305 create a tBCE. The tMAG sets the value of the transient lifetime to 306 a value that is dependent on the deployment and operator specific. 307 Additionally, the tMAG indicates that transient traffic forwarding 308 capability is uplink only by setting the transient traffic field to a 309 value 1. 311 After the target MAG receives an indication that the mobile node has 312 completed the inter-MAG handoff process and the data path is ready to 313 move the tunnel completely from the source MAG to the target MAG, the 314 target MAG SHOULD send a PBU to allow the local mobility anchor to 315 update the tBCE to a regular BCE and to switch the data bath 316 completely to be delivered through the target care-of address. In 317 this case, the tMAG sends a PBU with the MN-ID, Interface ID, MN-HNP 318 and at the same time sets the HI to 3. The tMAG does not include the 319 transient registration option as shown in Figure 3. 321 +-----+ +-----+ +-----+ +-----+ 322 | MN | |s-MAG| |t-MAG| | LMA | 323 +-----+ +-----+ +-----+ +-----+ 324 | | | bi-directional | 325 | |<<<<<<<<========================>>>>>>>>| 326 | | | pBCE 327 | | | [HNP1, s-pCOA, IF1] 328 Handoff Event | | | 329 | MN HO Event | | 330 | | HO Event Acquire | 331 | | MN pBCE[MN-ID, HNP1, IF1] | 332 LL Attach to | | | 333 tMAG AN | |-------P-BU (tReg.)------->| 334 | | | Create tBCE 335 | | | [HNP1, t-pCOA, IF1] 336 | | | pBCE HO Progress 337 | | |<------P-BA (tReg.)--------| 338 | | | | 339 | | bi-directional | 340 | |<<<<<<<<========================>>>>>>>>| 341 | | | | 342 | | | uplink only | 343 | | |>>>>>>=============>>>>>>>>| 344 | | | | 345 | | HO Complete | 346 | | |----- P-BU (NO tReg.) ---->| 347 | | | | 348 | | | Update tBCE to pBCE 349 | | | pBCE=[HNP1, t-pCOA, IF1] 350 | | |<--------- P-BA -----------| 351 | |` | | 352 | | |<<<<<<<<===========>>>>>>>>| 353 | | | | 354 | | | remove Source pBCE 355 | | | | 357 Figure 3: Target MAG Update MN tBCE during Inter-MAG Handover 359 In the event that the target MAG receives downlink traffic destined 360 to the mobile node from the LMA over the MAG-LMA tunnel, the tMAG 361 MUST deliver the downlink traffic to the mobile node. In this case, 362 the tMAG choose not to send a PBU to update the mobile node tBCE. 363 The tMAG may assume that the LMA has updated the mobile node tBCE to 364 regular BCE possibly after the LMA received a de-registration message 365 from the source MAG for the pBCE with care-of address s-pCoA. 367 6. Local Mobility Anchor Operation 369 When an uplink packet is received from the MN through the target MAG, 370 the LMA MUST verify if the source address of the packet matches the 371 transient pCoA. If the address matches, the LMA MUST consider the 372 packet to be valid and MUST forward the packet appropriately based on 373 the contents of the decapsulated packet. If the mobile node's tBCE 374 indicates uplink traffic forwarding capability, the LMA MUST NOT use 375 the tBCE for sending out downlink traffic to the MN through the 376 target MAG. 378 When the LMA receives a PBU with the transient registration option 379 included and the MN-ID, HNP, and the IF-ID, the LMA allocates all the 380 binding cache entries for the same MN-ID. The LMA then identifies 381 the BCE that have the same HNP and Interface ID. The LMA set an 382 indication flag to "handoff in progress". The LMA creates a tBCE 383 after allocating the same HNP and sets the transient lifetime field 384 to the value received in the TRO. LMA sends a PBA with HI equals to 385 the value received in PBU and as per the processes in PMIPv6 base 386 protocol. 388 After the LMA creates the mobile node transient BCE, the LMA add 389 another routing entry to the MN for the new t-pCOA. As long as the 390 tBCE is active, the LMA MUST forward all of the mobile node 391 intercepted downlink traffic to the source pCOA. 393 7. Transient Binding Cache Entries Update 395 The transient binding cache entry, which was created by the procedure 396 described in this document, needs to be short lived. i.e. for the 397 duration of the inter-MAG handover. After the handover completes, 398 this entry needs to be updated to a pBCE state. At the same time, 399 the LMA deletes the mobile node pBCE which is tagged as "handoff in 400 progress" and points to the source pCOA which is hosted at the sMAG. 401 There are three ways by which this process can happen: 403 1. The target MAG sends a new PBU with HI value 3 (Handoff between 404 mobile access gateways for the same interface): The transient 405 binding cache entry is converted into a full blown binding cache 406 entry and the BCE for the source MAG is removed. Figure 3 shows 407 the call flow for this procedure. 409 2. The source MAG sends a deregistration PBU: The transient binding 410 cache entry is converted into a pBCE and the pBCE for the source 411 MAG is removed. Figure 4 shows the call flow for this procedure. 413 3. Transient BCE lifetime expires: If the tBCE lifetime expires 414 before the tBCE has been updated based on one of the above cases 415 Paragraph 1 or Paragraph 2, the LMA MUST update the tBCE to pBCE 416 and remove the pBCE for the source MAG as shown in Figure 5 . 417 Additionally, the LMA MAY send a revocation indication message to 418 indicate to the source MAG that the mobile node's pBCE has been 419 removed and it needs to clean associated resources. 421 +-----+ +-----+ +-----+ +-----+ 422 | MN | |s-MAG| |t-MAG| | LMA | 423 +-----+ +-----+ +-----+ +-----+ 424 | | | bi-directional | 425 | |<<<<<<<<========================>>>>>>>>| 426 | | | pBCE 427 | | | [HNP1, s-pCOA, IF1] 428 Handoff Event | | | 429 | MN HO Event | | 430 | | HO Event Acquire | 431 | | MN pBCE[MN-ID, HNP1, IF1] | 432 LL Attach to | | | 433 tMAG AN | | | 434 | | |-------P-BU (tReg.)------->| 435 | | | | 436 | | | Create tBCE 437 | | | [HNP1, t-pCOA, IF1] 438 | | | pBCE HO Progress 439 | | |<------P-BA (tReg.)--------| 440 | | | | 441 | | bi-directional | 442 | |<<<<<<<<========================>>>>>>>>| 443 | | | | 444 | | | uplink only | 445 | | |>>>>>>=============>>>>>>>>| 446 | HO | | 447 | Complete | | 448 | |------------- P-BU (de-Reg.) ---------->| 449 | | | | 450 | | | Remove Source pBCE 451 | |<------------------ P-BA ---------------| 452 | | | | 453 | | | Update tBCE to pBCE 454 | | | pBCE=[HNP1, t-pCOA, IF1] 455 | |` | | 456 | | |<<<<<<<<===========>>>>>>>>| 457 | | | | 459 Figure 4: Source MAG Deregister MN Old pBCE during Inter-MAG Handover 460 +-----+ +-----+ +-----+ +-----+ 461 | MN | |s-MAG| |t-MAG| | LMA | 462 +-----+ +-----+ +-----+ +-----+ 463 | | | | 464 | | | tBCE Active 465 | | | tReg. Lifetime Start 466 | | bi-directional | 467 | |<<<<<<<<========================>>>>>>>>| 468 | | | | 469 | | | uplink only | 470 | | |>>>>>>=============>>>>>>>>| 471 | HO | | 472 | Complete | | 473 | | | tReg. Lifetime Expires 474 | | | No PBU from tMAG 475 | | | No De-reg. from sMAG 476 | | | | 477 | | | | 478 | | | Update tBCE to pBCE 479 | | | bi-directional | 480 | | |<<<<<<<<===========>>>>>>>>| 481 | | | | 482 | | | remove source pBCE 483 | | | | 484 | | | | 486 Figure 5: LMA Updates Transient BCE upon Transient Registration 487 Lifetime Expiry 489 8. IANA Considerations 491 This document defines one new Mobility Header option, the Transient 492 Registration option, which is described in Figure 2. The Type value 493 for this option needs to be assigned from the same numbering space as 494 allocated for the other mobility options, as defined in [3]. 496 9. Security Considerations 498 This document does not present any new security requirement on the 499 top of the security requirements listed in PMIPv6 base protocol [1]. 500 It only presents a mechanism which allows a mobile node to be 501 transitionally multihomed at two care of addresses during an inter- 502 MAG active handoff using the existing trust relationship and security 503 association between the LMA and the source and target MAGs. 505 10. Acknowledgements 507 The idea to capture transient registration as presented in this 508 document came out of a discussion during IETF70 at Vancouver in 509 December 2007. The following people were involved in the discussion 510 (listed by last name) Kuntal Chowdhury, Vijay Devarapalli, Sri 511 Gundavelli, Lalit Kotecha, Suresh Krishnan, Kent Leung and Ahmad 512 Muhanna. 514 11. References 516 11.1. Normative References 518 [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 519 B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-11 520 (work in progress), February 2008. 522 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 523 Levels", BCP 14, RFC 2119, March 1997. 525 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 526 IPv6", RFC 3775, June 2004. 528 [4] Muhanna, A. and M. Khalil, "Proxy MIPv6 support for Mobile Nodes 529 with Multihoming", draft-muhanna-netlmm-multihoming-support-01 530 (work in progress), February 2008. 532 11.2. Informative References 534 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 535 RFC 3753, June 2004. 537 [6] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile 538 IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in 539 progress), November 2007. 541 Authors' Addresses 543 Ahmad Muhanna 544 Nortel Networks 545 2221 Lakeside Blvd. 546 Richardson, TX 75082 547 USA 549 Phone: +1 (972) 685-1416 550 Email: amuhanna@nortel.com 552 Suresh Krishnan 553 Ericsson 554 8400 Decarie Blvd. 555 Town of Mount Royal, QC 556 Canada 558 Phone: +1 (514) 345-7900 x42871 559 Email: suresh.krishnan@ericsson.com 561 Kent Leung 562 Cisco 563 170 West Tasman Drive 564 San Jose, CA 95134 565 USA 567 Email: kleung@cisco.com 569 Basavaraj Patil 570 Nokia Siemens Networks 571 6000 Connection Drive 572 Irving, TX 75039 573 USA 575 Email: basavaraj.patil@nsn.com 577 Full Copyright Statement 579 Copyright (C) The IETF Trust (2008). 581 This document is subject to the rights, licenses and restrictions 582 contained in BCP 78, and except as set forth therein, the authors 583 retain all their rights. 585 This document and the information contained herein are provided on an 586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 588 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 589 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 590 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Intellectual Property 595 The IETF takes no position regarding the validity or scope of any 596 Intellectual Property Rights or other rights that might be claimed to 597 pertain to the implementation or use of the technology described in 598 this document or the extent to which any license under such rights 599 might or might not be available; nor does it represent that it has 600 made any independent effort to identify any such rights. Information 601 on the procedures with respect to rights in RFC documents can be 602 found in BCP 78 and BCP 79. 604 Copies of IPR disclosures made to the IETF Secretariat and any 605 assurances of licenses to be made available, or the result of an 606 attempt made to obtain a general license or permission for the use of 607 such proprietary rights by implementers or users of this 608 specification can be obtained from the IETF on-line IPR repository at 609 http://www.ietf.org/ipr. 611 The IETF invites any interested party to bring to its attention any 612 copyrights, patents or patent applications, or other proprietary 613 rights that may cover technology that may be required to implement 614 this standard. Please address the information to the IETF at 615 ietf-ipr@ietf.org. 617 Acknowledgment 619 Funding for the RFC Editor function is provided by the IETF 620 Administrative Support Activity (IASA).