idnits 2.17.1 draft-premec-mext-extended-home-link-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (October 8, 2009) is 5307 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-ietf-netlmm-mip-interactions-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group F. Abinader, Ed. 3 Internet-Draft Nokia Institute of Technology 4 Intended status: Standards Track D. Premec 5 Expires: April 11, 2010 Unaffiliated 6 J. Korhonen 7 Nokia Siemens Networks 8 October 8, 2009 10 IPv4 Support for DSMIPv6 IPv6 Home Link 11 draft-premec-mext-extended-home-link-04 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 11, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Mobile IPv6 for Dual Stack Hosts and Routers enables mobility for the 50 mobile node's IPv6 home address or prefix as well as an IPv4 home 51 address, irrespective of the IP version supported on the link that 52 the mobile node is attached to. The home agent maintains binding 53 cache entries for the IPv6 and IPv4 home addresses assigned to the 54 mobile node when the mobile node is connected via a foreign link. 55 The binding cache entries are deprecated when the mobile node 56 attaches to its home link. This document addresses an issue related 57 to the de-registration procedure and the continued connectivity for 58 the IPv4 home address when the mobile node attaches to its IPv6-only 59 home link. 61 Requirements Language 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Example Deployment Configuration . . . . . . . . . . . . . . . 7 73 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1. Binding Update Extensions . . . . . . . . . . . . . . . . 8 75 5.2. Binding Acknowledgment Extensions . . . . . . . . . . . . 9 76 5.3. Registration Process on the Home Link . . . . . . . . . . 9 77 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 11 78 6.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 11 79 6.2. Home Agent Considerations . . . . . . . . . . . . . . . . 11 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 A Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] Home Agent (HA) may be 91 deployed with some links that are considered by Mobile Nodes (MNs) as 92 home links that are IPv6 only. A DSMIPv6 MN may attach to its home 93 link via either a physical or a "virtual" link. As an example, a 94 DSMIPv6 MN may attach to a network which deploys Proxy Mobile IPv6 95 (PMIPv6) [RFC5213] in a way similar to the Scenario C from 96 [I-D.ietf-netlmm-mip-interactions], where the non-PMIPv6 domain to 97 which the MN roams can be a different PMIPv6 domain that handles a 98 different MN_HoA; in this case, the MN would receive a Router 99 Advertisement (RA) including the home-link prefix and hence would 100 perceive to be connected to the home link. The DSMIPv6 MN may also 101 be attached via a 2G/3G cellular network [3GPP.23.060], in which case 102 the link the MN is attached to can also be seen as the home link. In 103 addition, the MN may also attach to its HA via a physical home link 104 of the HA. The links in these examples may be in many cases IPv6 105 only. Figure 1 illustrate some of these examples: 107 .--. 108 _(. `) 109 _( IPv4/6`)_ 110 ( Internet `) 111 ( ` . ) ) 112 `--(_______)--' 113 | 114 | 115 | 116 IPv6-only HL +----+----+ Dual Stack HL 117 ---------------|DSMIP6 HA|-------------- 118 IF1 +---------+ IF2 119 | GW | 120 | eg. GGSN| 121 +---------+ 122 | IF3 123 |<-------------IPv6 Virtual HL 124 | 125 (--------|------) 126 ( | ) 127 ( Radio | NW ) 128 (--------|------) 129 | 130 | 131 +-------+ 132 | DS MN | 133 +-------+ 135 Figure 1: Example of Home Links (HL) Types provided by a DSMIPv6 HA 137 As seen on Figure 1, if the attaches to its home link which is dual 138 stack, eg interface IF2, the procedures described in [RFC5555] handle 139 the deregistration and are sufficient. However, if the MN returns 140 through either the IPv6-only (IF1) or IPv6 "virtual" (IF3) home 141 links, the provisioning of a "IPv6-only home link" for the MN does 142 not imply that the IPv4 Home Address (HoA) assigned to the MN is also 143 conceptually on the MN's home link. Furthermore, forwarding IPv4 144 traffic from the home agent (HA) to the MN might only be accomplished 145 by tunneling it over the IPv6-only access link. This basically 146 implies that there are situations where the MN is on its home link 147 (from the IPv6 point of view), but must still retain a Binding Cache 148 Entry (BCE) on the HA for the IPv4 HoA in order to be able to send 149 and receive IPv4 traffic. 151 Since DSMIPv6 does not allow the MN to maintain a BCE for its IPv4 152 HoA while being attached to the home link from the IPv6 point of view 153 (as stated in Section 4.4.2.1 of [RFC5555]), this document extends 154 the DSMIP6 protocol in order to allow the usage of the IPv4 HoA from 155 an IPv6-only access link appearing as the "IPv6 home link" to the MN. 156 By means of what is herein defined, a MN attached to an IPv6-only 157 "home link" is allowed to register its own IPv6 HoA as a Care-of 158 Address (CoA) for its IPv4 home address, while at the same time de- 159 registering the IPv6 binding. In such scenario, there is no 160 tunneling overhead for the IPv6 traffic, and the MN is able to tunnel 161 IPv4 traffic using its IPv4 HoA over the IPv6-only access link. 163 Section 3 describes what occurs (as per the current DSMIPv6 164 specification [RFC5555]) with the IPv4 HoA BCE that an MN registers 165 on its HA while attached via a foreign network with support for IPv6, 166 and then moves to an IPv6-only home link. 168 Section 4 of this specification discusses the envisioned deployment 169 scenarios in more detail. 171 Section 5 describes how a DSMIPv6-enabled MN that is attached to a 172 foreign network returns to the "IPv6-only home link" while 173 maintaining IPv4 connectivity. 175 Section 6 provides the details for the processing at the MN and HA 177 2. Terminology 179 General Mobile IPv6 related terminology is defined in [RFC3775]. 180 DSMIPv6 related terminology is described in [RFC5555]. 182 IPv6-only Home Link 184 A link associated with an HA, which may be physical or virtual, 185 and is considered by an MN as its home link, which supports IPv6 186 only. 188 3. Problem Statement 190 As stated in Section 4.4.2 of [RFC5555], the presence of the IPv4 HoA 191 Option is only mandatory in the Binding Update (BU) message for the 192 situation where the MN does need to register an IPv4 HoA with the HA, 193 otherwise its presence in the BU message is optional. Section 194 4.4.2.1 of [RFC5555] also states that the MN cannot remove the IPv6 195 HoA BCE while maintaining an IPv4 HoA BCE. From these two 196 statements, it can be concluded that the presence of the IPv4 HoA 197 Option on the BU message that de-registers the IPv6 HoA on the HA 198 when the MN returns to its home link is not mandatory, and that 199 independently of the presence or absence of the IPv4 HoA in the BU 200 message, the HA will remove all bindings (both IPv6 and IPv4) for the 201 MN. 203 According to Section 2.3.1 of [RFC5555], the HA for an MN which is 204 attached via a foreign link and has been assigned an IPv6 HoA as well 205 as an IPv4 HoA, contains a BCE which includes both the assigned HoAs 206 pointing to the MN's IPv4 or IPv6 CoA, like those defined below: 208 v6HoA -> v6CoA 209 v4HoA -> v6CoA 211 Suppose now that the MN moves to an IPv6-only link which is viewed by 212 the MN as its home link. After determining that it has returned to 213 the home link, the first action the MN takes is to send a BU to its 214 HA in order to de-register the IPv6 CoA on the HA. As the HA cannot 215 remove IPv6 binding while maintaining the IPv4 binding, the MN may or 216 may not include the IPv4 HoA (which is optional) in the BU message. 217 Once the HA receives this BU message and determines that it is a de- 218 registration (by either looking for equal source IPv6 address and 219 IPv6 HoA Option values OR a lifetime of zero), all bindings for the 220 mobile node will be removed. This will occur no matter if the IPv4 221 HoA Option was present or not, as it was already stated that it is 222 not allowed (by Section 4.4.2.1 of [RFC5555]) to have an registered 223 IPv4 HoA without a registered IPv6 HoA as well. 225 If for instance the MN needs an IPv4 HoA BCE while at the home 226 network, according to what is stated on [RFC5555], one possibility is 227 to send another BU message to register the IPv4 HoA after receiving 228 the Binding Acknowledgement (BAck) message for the previous IPv6 de- 229 registration event. However, this creates a gap in the provisioning 230 of IPv4 service between the two BU messages which does not allow 231 "seamless handovers", as IPv4 packets may be discarded on the HA 232 while in the gap period because of the lack of the BCE for the IPv4 233 HoA. In fact, the transport layer connections would most probably be 234 dropped due to the event of IPv6 CoA de-registration. Therefore, the 235 registration of the IPv4 HoA after the initial BU message for de- 236 registering the IPv6 HoA would not ensure "seamless handovers". 237 Given that there are no other mechanisms currently supported in 238 [RFC5555] for keeping the IPv4 binding while roaming back to the 239 IPv6-only network, there is a need for extending [RFC5555] in order 240 to allow "seamless handovers" for IPv4. 242 4. Example Deployment Configuration 244 This section describes an example scenario, where a MN's "home link" 245 provides IPv6-only access. As shown on Figure 2, the HA is 246 collocated with the default router, and the MN's access link (i.e. 247 the "home link" from the MN point of view) is configured to support 248 only IPv6, while the HA has connectivity to IPv4/IPv6 Internet on its 249 outbound interface. 251 .--. 252 _(. `) 253 _( IPv4/6`)_ 254 ( Internet `) 255 ( ` . ) ) 256 `--(_______)--' 257 | 258 | IPv4/6 link 259 | 260 +----+----+ 261 |DSMIP6 HA| 262 +---------+ 263 | 264 | IPv6 access link 265 | 266 +--+--+ 267 | MN | 268 +-----+ 270 Figure 2: Dual Stack Deployment with IPv6-only Home Link 272 Since the HA in the example shown on Figure 2 is a fully functional 273 DSMIPv6 HA, it can provide IPv4 HoA and IPv4 connectivity service to 274 the MN. In this case, the IPv4 home link appears as a "virtual home 275 link" to the MN (meaning the MN is always attached to a foreign link 276 from the Mobile IP point of view) and the MN tunnels the IPv4 traffic 277 via its on-link IPv6 address to the HA, and vice versa. However, 278 from an IPv6 perspective the MN is on its home link and hence there 279 is no tunnelling of IPv6 packets. 281 5. Solution Overview 283 The following sections describe the solution to overcome the problem 284 when the MN attaches to an IPv6 only home link with additional 285 information in the Binding Update (BU) and Binding Acknowledgement 286 (BAck) messages. Currently when a MN attaches to its home link, as 287 described in Section 4.4.2.1. of [RFC5555] and in Sections 9.5. and 288 11.5.4. of [RFC3775]), this would cause a de-registration of all 289 bindings for the Mobile Node (MN), including the IPv4 HoA. 291 5.1. Binding Update Extensions 293 This specification extends the Binding Update message with a new (X) 294 flag. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Sequence # | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |A|H|L|K|M|R|P|F|T|X| Reserved | Lifetime | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 3: Binding Update Message 306 Tunnel flag (X) 308 A new flag (X) is introduced in the Binding Update message to 309 indicate a request to register the IPv6 HoA as the Care-of Address 310 (CoA) for the IPv4 HoA. The MN MAY set this flag only when it sends 311 a BU message from an IPv6-only link that appears as the Mobile IPv6 312 home link to the MN. If this flag is set, the BU message MUST also 313 contain the IPv4 HoA option [RFC5555] and the HA MUST retain the 314 binding for the IPv4 HoA. The presence of the flag (X) on the BU 315 message, independently from the Lifetime being non-zero or not, 316 automatically causes the de-registration of the IPv6 HoA, as it is 317 discussed later on this document (see Section 5.3). 319 5.2. Binding Acknowledgment Extensions 321 This specification extends the BAck message with a new (X) flag. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Status |K|R|P|T|X|Resv.| 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Sequence # | Lifetime | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 . . 332 . Mobility options . 333 . . 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 4: Binding Acknowledgement Message 339 Tunnel Flag (X) 341 A new flag (X) is included in the BAck message to indicate that the 342 HA has created the Binding Cache Entry (BCE) for the IPv4 HoA with 343 the IPv6 HoA as the CoA. 345 5.3. Registration Process on the Home Link 347 Assume a MN has been configured with the following three addresses: 349 v6HoA MN's IPv6 home address 350 v4HoA MN's IPv4 home address 351 v6HA HA's IPv6 address 353 and currently is located in an IPv6 foreign network using 355 v6CoA MN's IPv6 care-of address 357 The MN has, using DSMIPv6, already made a registration with the HA 358 for both of its home addresses. 360 When the MN returns home to an IPv6-only home link, the MN sends the 361 following packet in order to register its on-link IPv6 address as the 362 CoA for the IPv4 HoA. The usage of the Alternate Care-of Address 363 option [RFC3775] while on the home link is optional and hence it may 364 be omitted: 366 IPv6 Header (src = v6HoA, dst = v6HA) 367 ESP Header 368 Mobility Header 369 type = 5 (Binding Update), X-flag=1 370 lifetime non-zero 371 [Alternate Care-of Address option (v6HoA)] 372 IPv4 Home Address option (v4HoA) 374 The HA sends the following response: 376 IPv6 Header (src = v6HA, dst = v6HoA) 377 ESP Header 378 Mobility Header 379 type = 6 (Binding Acknowledgement), X-flag=1 380 lifetime non-zero 381 IPv4 Address Acknowledgement option (v4HoA) 383 Although the packet exchange specified above seems obvious, the 384 packet exchange modifies the normal semantics of bindings in two 385 ways. 387 First, according to [RFC3775] Section 9.5, the HA when processing the 388 BU will determine the specified CoA to be the address found in the 389 Alternate Care-of Address option, i.e. v6HoA, or detect that the 390 Alternate Care-of Address option was omitted. Furthermore, it will 391 determine the HoA to be the source address of the IPv6 header, i.e. 392 v6HoA. With this input, the HA will conclude the binding update is a 393 de-registration, even if lifetime is non-zero. When a DSMIPv6 HA 394 detects a de-registration of the IPv6 home address, it releases the 395 entries for both the IPv6 and IPv4 HoAs. Therefore, the (X) flag 396 introduced by this specification changes the normal semantics of 397 deletion of a Binding Cache Entry (BCE) as it requires that only the 398 IPv6 entry is removed. 400 Another point relates to the de-registration of the IPv4 HoA from the 401 IPv6-only home link. Suppose the MN has installed the entry: 403 v4HoA -> v6HoA 405 in the Binding Cache (BE). Assume the MN no longer wants IPv4 406 connectivity, and wants to clear the BCE. The MN will clear the 407 entry by sending a BU message with a lifetime of zero. This message 408 is sent using v6HoA as source address. However, the BC has no v6HoA 409 entry. This means the entry in the BCE cannot be found and cleared. 411 One way to resolve this is to mandate that the MN includes the IPv4 412 HoA as part of the de-registration BU message which is then used by 413 the HA to locate the corresponding BCE. 415 Another way to resolve this is to ensure the HA maintains a dummy 416 entry for the v6HoA, such that the BC reads: 418 v6HoA -> v6HoA 419 v4HoA -> v6HoA 421 Inserting such a dummy entry in order to bypass tunneling seems a 422 substantial change of semantics. This is essentially the same as the 423 concept of the home binding described in Section 5.6.3 of 424 [I-D.ietf-monami6-multiplecoa]. 426 6. Protocol Operation 428 This specification introduces the new (X) flag in the BU and BAck 429 messages. The (X) flag in the BU message indicates a request to bind 430 the IPv6 home address as the CoA to the IPv4 home address. The (X) 431 flag in BAck indicates that the HA successfully created the binding 432 between the IPv4 HoA and the IPv6 HoA. 434 6.1. Mobile Node Considerations 436 When a DSMIPv6-enabled MN is connected to an IPv6-only home link, it 437 MAY register its IPv6 HoA as the CoA for its IPv4 HoA by setting the 438 (X) flag in the BU message, including the IPv4 Home Address option 439 and setting the CoA in the BU message to its IPv6 HoA. In this case 440 the MN MUST tunnel any IPv4 traffic sourced from the IPv4 HoA via its 441 IPv6 HoA to the HA. 443 If the MN registered its IPv6 HoA as the CoA for its IPv4 HoA, the MN 444 MUST maintain a BU list entry for the IPv4 HoA containing the IPv6 445 HoA as the CoA. 447 6.2. Home Agent Considerations 449 If the MN's current CoA as received in the BU message equals the MN's 450 IPv6 HoA, the HA MUST deprecate the BCE for the IPv6 HoA. If the (X) 451 flag was set and the IPv4 HoA was included in the same BU message and 452 the lifetime filed is non-zero, the HA MUST update the BCE for the 453 IPv4 HoA with the IPv6 HoA as the CoA. 455 If the HA updated the IPv4 BCE with the IPv6 HoA as the CoA, it MUST 456 set the (X) flag in the BAck message. 458 When the MN registers its IPv6 HoA as the CoA for the IPv4 HoA, the 459 HA MUST intercept the traffic destined to the MN's IPv4 HoA and 460 tunnel it to the MN's IPv6 HoA. 462 When the HA receives the BU that was sent from the "IPv6-only home 463 link" and where the lifetime is set to zero, the HA releases both the 464 IPv6 and IPv4 BCEs. If no IPv6 BCE was found, but the BU message 465 contains the IPv4 HoA, the HA MUST use the IPv4 HoA from the BU 466 message to locate the corresponding IPv4 BCE and release it. 468 7. Security Considerations 470 The security aspects and implications associated with [RFC5555] are 471 applicable to this document. This document also recommends that the 472 same level of security is applied to the packets sent natively to/ 473 from the MN's on-link home address and to the packets on the virtual 474 home link that are tunneled to the MN's on-link home address. 476 8. IANA Considerations 478 This document specifies a new flag (X) in the Binding Update (BU) and 479 Binding Acknowledgement (BAck) messages of DSMIPv6 [RFC5555]. This 480 flag is defined in sections Section 5.1 and Section 5.2. IANA is 481 requested to allocate the new flag (X) in the Binding Update and 482 Binging Acknowledgement messages from the RFC3775 Binding Update 483 Flags and the RFC3775 Binding Acknowledgment Flags registries. 485 9. Acknowledgements 487 The authors would like to thank Christian Kaas-Petersen for a 488 detailed review and contributions to this document. 490 10. References 492 10.1. Normative References 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 498 in IPv6", RFC 3775, June 2004. 500 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 501 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 503 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 504 Routers", RFC 5555, June 2009. 506 10.2. Informative References 508 [3GPP.23.060] 509 3GPP, "General Packet Radio Service (GPRS); Service 510 description; Stage 2", 3GPP TS 23.060 8.5.1, June 2009. 512 [I-D.ietf-monami6-multiplecoa] 513 Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 514 and K. Nagami, "Multiple Care-of Addresses Registration", 515 draft-ietf-monami6-multiplecoa-14 (work in progress), 516 May 2009. 518 [I-D.ietf-netlmm-mip-interactions] 519 Giaretta, G., "Interactions between PMIPv6 and MIPv6: 520 scenarios and related issues", 521 draft-ietf-netlmm-mip-interactions-04 (work in progress), 522 June 2009. 524 Authors' Addresses 526 Fuad Abinader (editor) 527 Nokia Institute of Technology 528 Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova 529 Manaus, AM 69048-660 530 BRAZIL 532 Email: fabinader@gmail.com 534 Domagoj Premec 535 Unaffiliated 537 Email: domagoj.premec@gmail.com 539 Jouni Korhonen 540 Nokia Siemens Networks 541 Linnoitustie 6 542 Espoo, FI-02600 543 FINLAND 545 Email: jouni.nospam@gmail.com