idnits 2.17.00 (12 Aug 2021) /tmp/idnits60902/draft-ietf-mip4-dsmipv4-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 997. 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 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 13, 2008) is 5211 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 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Tsirtsis 3 Internet-Draft V. Park 4 Intended status: Standards Track Qualcomm 5 Expires: August 16, 2008 H. Soliman 6 Elevate Technologies 7 February 13, 2008 9 Dual Stack Mobile IPv4 10 draft-ietf-mip4-dsmipv4-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 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 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 16, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This specification provides IPv6 extensions to the Mobile IPv4 44 protocol. The extensions allow a dual stack node to use IPv4 and 45 IPv6 home addresses as well as to move between IPv4 and dual stack 46 network infrastructures. 48 Table of Contents 50 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.3. Implicit and Explicit Modes . . . . . . . . . . . . . . . 5 55 3. Extension Formats . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. IPv6 Prefix Request Extension . . . . . . . . . . . . . . 6 57 3.2. IPv6 Prefix Reply Extension . . . . . . . . . . . . . . . 7 58 3.3. IPv6 Tunneling Mode Extension . . . . . . . . . . . . . . 8 59 4. Mobile IP Registrations . . . . . . . . . . . . . . . . . . . 10 60 4.1. Registration Request . . . . . . . . . . . . . . . . . . . 10 61 4.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 10 62 4.3. Home Agent Considerations . . . . . . . . . . . . . . . . 11 63 4.3.1. IPv6 Packet Processing . . . . . . . . . . . . . . . . 12 64 4.3.2. Processing intercepted IPv6 Packets . . . . . . . . . 12 65 4.3.3. IPv6 Multicast Membership Control . . . . . . . . . . 14 66 4.4. Foreign Agent Considerations . . . . . . . . . . . . . . . 15 67 4.5. Mobile Node Considerations . . . . . . . . . . . . . . . . 15 68 4.6. Dynamic IPv6 Prefix allocation . . . . . . . . . . . . . . 17 69 4.6.1. Mobile IP Style Address Allocation . . . . . . . . . . 17 70 4.7. Deregistration of IPv6 Prefix . . . . . . . . . . . . . . 18 71 4.8. Registration with a private CoA . . . . . . . . . . . . . 18 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 74 7. Change history . . . . . . . . . . . . . . . . . . . . . . . . 21 75 7.1. Changes from v04 to v05 . . . . . . . . . . . . . . . . . 21 76 7.2. Changes from v03 to v04 . . . . . . . . . . . . . . . . . 21 77 7.3. Changes from v02 to v03 . . . . . . . . . . . . . . . . . 21 78 7.4. Changes from v01 to v02 . . . . . . . . . . . . . . . . . 21 79 7.5. Changes from v00 to v01 . . . . . . . . . . . . . . . . . 22 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 85 Intellectual Property and Copyright Statements . . . . . . . . . . 27 87 1. Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Introduction 95 Mobile IPv4 [RFC3344] allows a mobile node with an IPv4 address to 96 maintain communications while moving in an IPv4 network. 98 Extensions defined in this document allow a node that has IPv4 and 99 IPv6 addresses [RFC2460] to maintain communications through any of 100 its addresses while moving in IPv4 or dual stack networks. 102 Essentially, this specification separates the Mobile IPv4 signaling 103 from the IP version of the traffic it tunnels. Mobile IPv4 with the 104 present extensions remains a signaling protocol that runs over IPv4, 105 and yet can set-up both IPv4 and IPv6 tunnels over IPv4. 107 The aim is two-fold: 109 On one hand, Mobile IPv4 with the present extensions becomes a 110 useful transition mechanism, allowing automated but controlled 111 tunneling of IPv6 traffic over IPv4 tunnels. Dual stack nodes in 112 dual stack home networks can now roam to and from legacy IPv4 113 networks, while IPv4 mobile nodes and networks can migrate to IPv6 114 without changing mobility management, and without upgrading all 115 network nodes to IPv6 at once. 117 On the other hand, and more importantly, it allows dual stack 118 mobile nodes and networks to utilize a single protocol for the 119 movement of both IPv4 and IPv6 stacks in the network topology. 121 Note that features like Mobile IPv6 [RFC3775] style route 122 optimization will not be possible with this solution as it still 123 relies on Mobile IPv4 signaling, which does not provide route 124 optimization. 126 2.1. Goals 128 a. The solution supports the registration of IPv6 home address(es) 129 and/or prefix(s) in addition to regular IPv4 home address 130 registration 132 b. The solution supports static and dynamic IPv6 home address(s)/ 133 prefix(s) allocations 135 c. The solution supports the above registrations with and without FA 136 support 138 2.2. Non-Goals 140 a. The solution does not provide support for IPv6 care-of address 141 registration 143 2.3. Implicit and Explicit Modes 145 As defined in NEMO [RFC3963], this specification also supports two 146 modes of operation; the implicit mode and the explicit mode. 148 In the implicit mode, the mobile node does not include any IPv6 149 Prefix Request extensions in the Registration Request. The home 150 agent can use any mechanism (not defined in this document) to 151 determine the IPv6 Prefix(es) owned by the mobile node and to set up 152 forwarding for these prefixes. In this mode of operation all traffic 153 to and from the IPv6 prefixes MUST be encapsulated over the IPv4 154 tunnel between the mobile node's IPv4 home address and the IPv4 155 address of the home agent, and as such it is transparent to any 156 foreign agent in the path. This IPv4 tunnel is established by 157 mechanisms that are out of the scope of this document on both the 158 mobile node and home agent when operating in the implicit mode. 160 In the explicit mode, IPv6 address bindings are signalled explicitly. 161 The mobile node includes one or more IPv6 Prefix Request extensions 162 in the Registration Request, while the home agent returns 163 corresponding IPv6 Prefix Reply extensions to accept/reject the IPv6 164 bindings. 166 Additionally, in the explicit mode, the mobile node (when co-located 167 mode of operation is used) or the foreign agent (when present) can 168 indicate whether IPv6 traffic should be tunneled to the care-of 169 address of the home address of the mobile node. 171 The rest of this specification is primarily defining the explicit 172 mode. 174 3. Extension Formats 176 The following extensions are defined according to this specification. 178 3.1. IPv6 Prefix Request Extension 180 A new skippable extension to the Mobile IPv4 registration request 181 message in accordance to the short extension format of [RFC3344] is 182 defined here. 184 This extension contains a mobile IPv6 network prefix and its prefix 185 length. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Type | Length | Sub-Type | Prefix Length | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | | 193 + + 194 | | 195 + Mobile IPv6 Network Prefix + 196 | | 197 + + 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1: IPv6 Prefix Request Extension 203 Type 205 TBD (DSMIPv4 Extension)(skippable type to be assigned by IANA) 207 Length 209 18 211 Sub-Type 213 1 ( IPv6 Prefix Request) 215 Prefix Length 217 Indicates the prefix length of the prefix included in the Mobile 218 IPv6 Network Prefix field 220 Mobile IPv6 Network Prefix 221 A sixteen-byte field containing the Mobile IPv6 Network Prefix 223 3.2. IPv6 Prefix Reply Extension 225 A new skippable extension to the Mobile IPv4 registration reply 226 message in accordance to the short extension format of [RFC3344] is 227 defined here. 229 This extension defines a mobile IPv6 network prefix and its prefix 230 length, as well as a code. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type | Length | Sub-Type | Code | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Prefix Length | Reserved | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 239 | | 240 + + 241 | | 242 + Mobile IPv6 Network Prefix + 243 | | 244 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 2: IPv6 Prefix Reply Extension 250 Type 252 TBD (DSMIPv4 Extension)(skippable type to be assigned by IANA) 254 Length 256 20 258 Sub-Type 260 2 (IPv6 Prefix Reply) 262 Code 264 A value indicating the result of the registration request with 265 respect to the IPv6 home address registration. See below for 266 currently defined Codes. 268 Prefix Length 269 Indicates the prefix length of the prefix included in the Mobile 270 IPv6 Network Prefix field 272 Reserved 274 Set to 0 by the sender, ignored by the receiver 276 Mobile IPv6 Network Prefix 278 A sixteen-byte field containing the Mobile IPv6 Network Prefix 280 The following values are defined for use as a Code value in the above 281 extension 283 0 registration accepted, IPv6 to be tunneled to HoA 285 1 registration accepted, IPv6 to be tunneled to CoA 287 8 registration rejected, reason unspecified 289 9 registration rejected, administratively prohibited 291 10 registration rejected, not home subnet 293 11 registration rejected, Duplicate Address Detection failed 295 Note that a registration reply that does not include an IPv6 Prefix 296 Reply extension indicates that the home agent does not support IPv6 297 extensions and thus has ignored such extensions in the registration 298 request. 300 3.3. IPv6 Tunneling Mode Extension 302 A new skippable extension to the Mobile IPv4 registration request 303 message in accordance to the short extension format of [RFC3344] is 304 defined here. 306 By including this extension in a registration request the sender 307 indicates that IPv6 traffic can be tunneled to the mobile's CoA. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Length | Sub-Type | Reserved | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 3: IPv6 Tunneling Mode Extension 317 Type 319 TBD (DSMIPv4 Extension) (skippable type to be assigned by IANA) 321 Length 323 2 325 Sub-Type 327 3 (IPv6 Tunneling Mode) 329 Reserved 331 Set to 0 by the sender, ignored by the receiver 333 4. Mobile IP Registrations 335 4.1. Registration Request 337 A mobile node MAY include one or more IPv6 Prefix Request extensions 338 defined in this specification in a registration request. 340 A mobile node MAY include exactly one IPv6 tunneling mode extension 341 when it uses the co-located care-of address mode of [RFC3344]. 343 When IPv6 prefix and/or IPv6 tunneling mode extensions are used by 344 the mobile IP client, they MUST be placed after the registration 345 request header and before the mobile - home authentication extension 346 so they MUST be included in the computation of any authentication 347 extension. 349 A foreign agent MAY include exactly one IPv6 tunneling mode 350 extension, defined in this specification, in a registration request 351 when a mobile node registers using the care-of address mode via the 352 foreign agent. 354 When the IPv6 tunneling mode extension is used by a foreign agent it 355 MUST be placed after the mobile - home authentication extensions and 356 before the foreign - home authentication extension so they MUST be 357 included in the computation of the foreign - home authentication 358 extension when one exists. 360 4.2. Registration Reply 362 The mechanism described in the specification depends on skippable 363 extensions. For that reason, a registration reply that does not 364 include an IPv6 Prefix Reply extension, in response to a registration 365 request that included an IPv6 Prefix Request extension, indicates 366 that the home agent does not support IPv6 extensions and has ignored 367 the request. 369 If an IPv6 Prefix Reply extension is included in a registration 370 reply, then the extension indicates the success or failure of the 371 IPv6 prefix registration. The IPv6 Prefix Reply extension does not 372 affect in any way the code value in the registration reply header but 373 it is superseded by it. In other words if the code field in the 374 registration reply header is set to a reject code, then all IPv6 375 Prefix Request extensions are also rejected. If the code field in 376 the registration reply header, however, is set to an accept code, 377 then an IPv6 Prefix Reply extension with a code field set to a reject 378 code only rejects the binding for the specific IPv6 prefix indicated 379 in the same extension. 381 Note that a rejecting IPv6 Prefix Reply extension has the same effect 382 as not including such an extension at all in the sense that in both 383 cases the mobile node and foreign agent must act as if the 384 corresponding IPv6 Prefix Request extension included in the 385 registration request was rejected. Of course, the inclusion of the 386 IPv6 Prefix Reply extension allows the home agent to indicate why a 387 given IPv6 Prefix Request extension was rejected. Consequently, home 388 agent implementations of this specification SHOULD include, in the 389 registration reply messages, an IPv6 Prefix Reply extension for each 390 IPv6 Prefix Request extension included in the corresponding 391 registration request message. A detailed description of how the 392 mobile node handles different IPv6 Prefix Reply extension code values 393 and the absence of IPv6 Prefix Reply extensions is given in 394 Section 4.5. 396 4.3. Home Agent Considerations 398 The dual stack home agent defined in this specification is a Mobile 399 IPv4 [RFC3344] Home Agent, in that it MUST operate as defined in 400 MIPv4 [RFC3344]. In addition to that the following mechanism are 401 defined in this specification. 403 For each IPv6 Prefix Request extension included in a valid 404 registration request, a home agent that supports this specification 405 SHOULD include a corresponding IPv6 Prefix Reply extension in the 406 registration reply message. The home agent MUST NOT included more 407 than one IPv6 Prefix Reply extension for the same prefix. For each 408 accepted IPv6 prefix the home agent MUST decide the tunneling mode it 409 is going to use and set the Code field of the IPv6 Prefix Reply 410 extension to the appropriate value. The IPv6 prefix field of each of 411 the IPv6 Prefix Reply extensions included in the registration reply 412 MUST match the IPv6 prefix field of an IPv6 Prefix Request extensions 413 included in the corresponding registration request message. 415 If the IPv6 home address included in an IPv6 Prefix Request extension 416 is not an on-link IPv6 address with respect to the home agent's 417 current Prefix List or a prefix it is configured to serve, the home 418 agent MUST reject the IPv6 Prefix Request extension and SHOULD return 419 an IPv6 Prefix Reply extension with rejection code "registration 420 rejected, not home subnet" in the registration reply to the mobile 421 node. 423 When the IPv6 Prefix Request extension contains a /128 IPv6 address 424 and unless this home agent already has a binding for the given IPv6 425 address indicated, the home agent MUST perform Duplicate Address 426 Detection [RFC4862] on the mobile node's home IPv6 link before 427 returning a registration reply. This ensures that no other node on 428 the home link is using the IPv6 home address. Duplicate address 429 detection is not required when the IPv6 Prefix Request extension 430 contains a prefix. If this Duplicate Address Detection fails for the 431 given IPv6 home address or an associated link local address, then the 432 home agent MUST reject the IPv6 Prefix Request extension and SHOULD 433 return a registration reply to the mobile node, in which the code 434 field of the corresponding IPv6 Prefix Reply extension is set to 435 "registration rejected, Duplicate Address Detection failed". 437 When the home agent sends a successful registration reply to the 438 mobile node, with the Code field of a corresponding IPv6 Prefix Reply 439 extension set to one of the "registration accepted" values, the home 440 agent assures the mobile node that its IPv6 address(es) will be kept 441 unique by the home agent for as long as the lifetime is granted for 442 the binding. It also indicates the tunneling mode used i.e., 443 tunneling to home address or care-of address, based on the value of 444 the code field used in the IPv6 Prefix Reply extension. 446 Note that for IPv6 prefixes (rather than addresses), the home agent 447 does not have to perform Duplicate Address Detection but it MUST 448 check that allocated prefixes are not overlapping so that all 449 addresses under each allocated prefix are allocated only to a single 450 mobile node at any one time. 452 4.3.1. IPv6 Packet Processing 454 Dual stack home agents MUST use Proxy Neighbor Discovery [RFC4861] on 455 behalf of the nodes they serve. This allows the home agent to 456 receive IPv6 packets addressed to the mobile node's registered IPv6 457 address(es). 459 In this respect, the dual stack home agent MUST act as defined in 460 MIPv6 [RFC3775], Section 10.4.1. in order to intercept IPv6 packets 461 for the mobile nodes it serves. 463 The home agent MUST advertise reachability for the registered 464 prefixes as defined in NEMO [RFC3963], section 6.3. 466 4.3.2. Processing intercepted IPv6 Packets 468 A dual stack home agent that supports the IPv6 extensions defined in 469 this specification, MUST keep track of the following IPv6 related 470 state for the mobile nodes it supports, in addition to the state 471 defined in [RFC3344]. 473 - Registered IPv6 prefix(es) and prefix length(s) 475 - Tunneling mode for IPv6 traffic: 477 - Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA 479 - Tunnel to CoA and accept IPv6 tunneled from CoA 481 When IPv6 traffic is encapsulated over the tunnel between the HA and 482 the mobile node's care-off address, the tunneling mechanism used 483 should be the same as the mechanism negotiated by the Mobile IP 484 header as defined in MIPv4 [RFC3344]. In that case, when IPinIP 485 encapsulation is negotiated, IPv6 is tunneled over IPv4 according 486 to[RFC4213]. GRE and Minimal Encapsulation techniques also allow 487 tunneling of IPv6 packets by setting the Protocol Type [RFC2784] and 488 Protocol [RFC2004] fields to appropriate payload type defined for 489 IPv6 by IANA. When, however, IPv6 traffic is encapsulated over the 490 tunnel between the HA and the mobile node's home address, IPv6 is 491 always tunneled over IPv4 according to [RFC4213], no matter what 492 tunneling mechanism is negotiated in MIPv4 signaling. 494 A home agent that supports this specification MUST be able to defend 495 IPv4 and IPv6 addresses registered by mobile nodes according to 496 mechanisms described in MIPv4 [RFC3344] and MIPv6 [RFC3775] 497 specifications. 499 Tunneling mode selection for IPv6 traffic depends on the following 500 parameters in a successful registration request: 502 1) A registration request is received with one or more IPv6 Prefix 503 Request extensions. An IPv6 tunneling mode extension is not 504 included. 506 All IPv6 packets destined to the registered IPv6 prefix(es) MUST 507 be tunneled by the home agent to the registered IPv4 home address 508 of the mobile. The home agent first encapsulates the IPv6 packetm 509 addressing it to the mobile node's IPv4 home address, and then 510 tunnels this encapsulated packet to the foreign agent. This extra 511 level of encapsulation is required so that IPv6 routing remains 512 transparent to a foreign agent that does not support IPv6. When 513 received by the foreign agent, the unicast encapsulated packet is 514 detunneled and delivered to the mobile node in the same way as any 515 other packet. The mobile node must decapsulate the received IPv4 516 packet in order to recover the original IPv6 packet. 518 Additionally, the home agent MUST be prepared to accept reverse 519 tunneled packets from the IPv4 home address of the mobile 520 encapsulating IPv6 packets sent by that mobile. 522 2) A registration request is received with one or more IPv6 Prefix 523 Request extensions. An IPv6 tunneling mode extension is included. 525 All IPv6 packets destined to the registered IPv6 home address(s) 526 SHOULD be tunneled by the home agent to the registered care-of 527 address of the mobile node. Additionally, the home agent SHOULD 528 be prepared to accept reverse tunneled packets from the care-of 529 address of the mobile encapsulating IPv6 packets sent by that 530 mobile. The home agent MAY ignore the presence of the IPv6 531 tunneling mode extension and act as in case (1) above. 533 Packets addressed to the mobile node's IPv6 link-local address MUST 534 NOT be tunneled to the mobile node. Instead, these packets MUST be 535 discarded and the home agent SHOULD return an ICMPv6 Destination 536 Unreachable, Code 3, message to the packet's Source Address (unless 537 this Source Address is a multicast address). 539 The home agent SHOULD check that all inner IPv6 packets received from 540 the mobile node over a tunnel with outer source address the home 541 address or the care-of address, include a source address that falls 542 under the registered IPv6 prefix(es) for that mobile node. If the 543 source address of the outer header of a tunneled packet is not the 544 registered IPv4 care-of address or the registered IPv4 home 545 addresses, the packet SHOULD be dropped. If the source address of 546 the inner header of an tunneled packet does not match any of the 547 registered home addresses and/or prefixes the packet SHOULD be 548 dropped. 550 Interception and tunneling IPv6 multicast addressed packets on the 551 home network is only done if the home agent supports multicast group 552 membership control messages from the mobile node as described in the 553 next section. Multicast IPv6 packets addressed to a multicast 554 address with link-local scope [RFC4291], to which the mobile node is 555 subscribed, MUST NOT be tunneled to the mobile node. These packets 556 SHOULD be silently discarded (after delivering to other local 557 multicast recipients). Multicast packets addressed to a multicast 558 address with a scope larger than link-local, but smaller than global 559 (e.g., site- local and organization-local [RFC4291], to which the 560 mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. 561 Multicast packets addressed with a global scope, to which the mobile 562 node has successfully subscribed, MUST be tunneled to the mobile 563 node. 565 4.3.3. IPv6 Multicast Membership Control 567 IPv6 multicast membership control is provided as defined in MIPv6 568 [RFC3775], Section 10.4.3. The only clarification required for the 569 purpose of this specification is that all MLD [RFC2710] or MLDv2 570 [RFC3810] messages between the mobile node and the home agent MUST be 571 tunneled between the mobile node and the home agent, bypassing the 572 foreign agent. 574 4.4. Foreign Agent Considerations 576 A dual stack foreign agent that supports the IPv6 extensions defined 577 in this specification MUST keep track of the following IPv6 related 578 state for the mobile IP clients it supports in addition to the state 579 defined in [RFC3344]. 581 - IPv6 Prefix(es) and Prefix Length(s) 583 - Tunneling mode for IPv6 traffic: 585 - accept IPv6 encapsulated in IPv4 and reverse tunnel IPv6 587 - IPv6 is tunneled directly to the IPv4 HoA so the foreign agent 588 will not provide encapsulation/decapsulation services for IPv6 589 traffic for this mobile. 591 When a foreign agent receives a registration request with IPv6 Prefix 592 Request extension(s) it has the following choices: 594 1) Ignore the extension(s). The registration request is forwarded as 595 is to the home agent. 597 The foreign agent SHOULD operate according to MIPv4 [RFC3344] 599 2) Attach an IPv6 tunneling mode extension to the registration 600 request sent to the home agent. 602 The foreign agent MUST be prepared to decapsulate and deliver IPv6 603 packets, in addition to the IPv4 packets, sent to it in the home 604 agent to foreign agent tunnel for that mobile node. The foreign 605 agent MUST be prepared to receive IPv6 packets from the mobile 606 node, in addition to IPv4 packets. All IPv6 traffic MUST be 607 reverse tunneled to the home agent by the foreign agent 608 irrespectively from the reverse tunneling setting negotiated for 609 IPv4 packets by mechanisms in [RFC3024] 611 If the foreign agent sets the R flag included in the mobility agent 612 advertisement [RFC3344] and a mobile node uses the co-located address 613 mode of operation, the foreign agent MUST NOT include an IPv6 614 tunneling mode extension in the registration request messages sent 615 from that mobile node. 617 4.5. Mobile Node Considerations 619 A dual stack mobile node that supports the extensions described in 620 this document MAY use these extensions to register its IPv6 home 621 address(es) and/or prefix(es) while moving between access routers. 623 The mobile node MAY include one or more IPv6 Prefix Request 624 extension(s) in the registration request. 626 In this case the mobile MUST take the following action depending on 627 the extensions included in the registration reply it receives in 628 response to the registration request: 630 1) The registration reply does not include any IPv6 Prefix Reply 631 extensions. 633 The mobile node SHOULD assume that the home agent does not support 634 the extensions defined in this specification. The mobile node 635 SHOULD continue to operate according to MIPv4 [RFC3344]. 637 2) The registration reply includes one or more IPv6 Prefix Reply 638 extensions. 640 The mobile node MUST match each IPv6 Prefix Reply extension with 641 one of the IPv6 Prefix Request extensions earlier included in the 642 corresponding registration request message. 644 If a matching IPv6 Prefix Reply extension is not included for one 645 or more of corresponding IPv6 Prefix Request extensions included 646 in the registration request message, the mobile node SHOULD assume 647 that these IPv6 prefixes are rejected. 649 For each matching IPv6 Prefix Reply extensions the mobile node 650 MUST inspect the Code field. If the field is set to a rejection 651 code then the corresponding IPv6 prefix registration has been 652 rejected. If the Code field is set to an acceptance code then the 653 corresponding IPv6 prefix registration has been accepted. 655 If the Code field is set to "0" then the mobile node MUST be 656 prepared to send/receive IPv6 packets encapsulated in the 657 bidirectional tunnel between the home agent address and the 658 registered IPv4 home address of the mobile node. 660 If the Code field is set to "1" then the mobile node MUST act as 661 follows: 663 - If the care-of address mode of operation is used, the mobile 664 node MUST be prepared to send/receive IPv6 traffic on its 665 interface natively (i.e., without any Mobile IP related tunnel 666 headers). If reverse tunneling is negotiated, then IPv6 traffic 667 sent by the mobile node may be reverse tunneled via the foreign 668 agent using either the direct delivery style or the encapsulating 669 delivery style as defined in [RFC3024] for IPv4 traffic. 671 - If the co-located care-of address mode is used, the mobile node 672 MUST be prepared to send/receive IPv6 packets over the 673 bidirectional tunnel between the home agent address and its co- 674 located care-of address. 676 The mobile node SHOULD include exactly one IPv6 tunneling mode 677 extension if it uses the co-located care-of address model and it 678 wants to request that IPv6 packets are tunneled to its co-located 679 care-of address. If the mobile node uses the co-located care-of 680 address model but it does not include the IPv6 tunneling mode 681 extension the home agent will tunnel IPv6 traffic to the mobile 682 node's home address. The mobile node MUST NOT include an IPv6 683 tunneling mode extension if it uses the foreign agent care-of address 684 mode of operation. Note that if the mobile includes an IPv6 685 tunneling mode extension in this case, IPv6 packets could be tunneled 686 to the FA by the HA. The FA is then likely to drop them since it may 687 not have appropriate state to process them. 689 4.6. Dynamic IPv6 Prefix allocation 691 The dynamic IPv6 prefix allocation described in the following section 692 reuses the Mobile IPv4 mechanisms defined for IPv4 address 693 allocation. An implementation can use a different mechanism to 694 dynamically allocate IPv6 addresses in which case once such IPv6 695 addresses are allocated, they can be registered using the extensions 696 and mechanism already described. 698 How a home agent decides to provide, or accept, an IPv6 home address 699 or prefix for a given mobile node, is out of scope of this 700 specification. Local configuration or external authorization via an 701 authorization system e.g., Diameter [RFC3588], or other mechanisms 702 may be used to make such determination 704 4.6.1. Mobile IP Style Address Allocation 706 A mobile node may include one or more IPv6 Prefix Request extensions 707 with the IPv6 prefix field set to zero. The mobile node MAY set the 708 prefix length field of such extensions to zero or to a length of its 709 choice as a hint to the home agent. Such IPv6 Prefix Request 710 extensions indicate that the mobile node requests IPv6 address(es) 711 and prefix(es) to be assigned to it by the home agent. 713 A home agent receiving an IPv6 Prefix Request extension with the IPv6 714 prefix field set to zero MAY return an IPv6 Prefix Reply extension 715 with the IPv6 prefix field set to the IPv6 prefix allocated to the 716 mobile node. The length of that prefix is at the discretion of the 717 home agent. The home agent may take into account the prefix length 718 hint if one is included in the IPv6 Prefix Request extension. 720 A mobile node MAY include one or more IPv6 Prefix Request extensions 721 with the IPv6 Prefix field set to ::interface_identifier, where 722 interface_identifier is the unique layer 2 address of the client. 723 The interface_identifier MUST be less than or equal to 64 bits in 724 length. In this case the prefix length field MUST be set to 128. 726 The home agent MAY in this case return an IPv6 Prefix Reply extension 727 with: 729 - the IPv6 prefix field set to PREFIX:: and the prefix length 730 field set to the desired prefix length value. In this case the 731 PREFIX:: subnet is allocated to the mobile node, which should 732 proceed in constructing IPv6 addresses as defined in [RFC4862] 734 - the IPv6 prefix field set to PREFIX::interface_identifier and 735 the prefix length field set to 128. In this case an individual 736 IPv6 address is allocated to the mobile node. 738 4.7. Deregistration of IPv6 Prefix 740 The mobile IP registration lifetime included in the registration 741 request header is valid for all the bindings created by the 742 registration request, which may include bindings for IPv6 address(es) 743 and prefix(es). 745 A registration request with a zero lifetime can be used to remove all 746 bindings from the home agent. 748 A re-registration request with non-zero lifetime can be used to 749 deregister some of the registered IPv6 prefixes by not including 750 corresponding IPv6 Prefix Request extensions in the registration 751 request message. 753 4.8. Registration with a private CoA 755 If the care-of address is a private address then Mobile IP NAT 756 Traversal as [RFC3519] MAY be used in combination with the extensions 757 described in this specification. In that case, to transport IPv6 758 packets, the next header field of the Mobile Tunnel Data message 759 header [RFC3519] MUST be set to the value for IPv6. 761 5. Security Considerations 763 This specification operates in the security constraints and 764 requirements of [RFC3344]. It extends the operations defined in 765 [RFC3344] for IPv4 home addresses to cover home IPv6 addresses 766 prefixes and provides the same level of security for both IP address 767 versions. 769 As defined in the security considerations section of RFC3344, ingress 770 filtering in the data path may prevent mobiles from using triangular 771 routing for their IPv6 communications even if the foreign agent used 772 supports the dual stack extensions defined in this specification. In 773 such cases reverse tunneling can be used to allow for effective 774 ingress filtering in intermediate routers without blocking IPv6 775 traffic to reach its destination. 777 Home Agents MUST perform appropriate checks for reversed tunneled 778 IPv6 packets similar to what is defined in [RFC3024] for IPv4 779 packets. The check defined in [RFC3024] requires that the outer 780 header's source address is set to a registered care-of address for 781 the mobile node and as such the same check protects from attacks 782 whether the encapsulated (inner) header is IPv4 or IPv6. 784 In addition to that, the home agent SHOULD check that the source 785 address of the inner header is a register IPv4 or IPv6 home address 786 for this mobile node. If that is not the case, the home agent SHOULD 787 silently discard the packet and log the event as a security 788 exception. 790 6. IANA Considerations 792 This specification requires the allocation of a new type number for 793 DSMIPv4 extensions, from the space of numbers for skippable mobility 794 extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344] at 795 http://www.iana.org/assignments/mobileip-numbers. 797 This specification also creates a new subtype space for the type 798 number of this extension. The subtype values 1, 2 and 3 are defined 799 in this specification. 801 Finally, this specification creates a new space for the Code field of 802 the IPv6 Prefix Reply extension. Values 0, 1, 8, 9, 10, 11 are 803 defined in this specification. Values 0-7 are reserved for accept 804 codes and the rest of the values are reserved for reject values. 806 Similar to the procedures specified for Mobile IPv4 [RFC3344] number 807 spaces, future allocations from this number space require expert 808 review [RFC2434]. 810 7. Change history 812 NOTE TO RFC EDITOR: Remove Section 7 before publication. 814 7.1. Changes from v04 to v05 816 Corrected nits. 818 Added IANA considerations section. 820 7.2. Changes from v03 to v04 822 Clarified that DAD is only needed on IPv6 addresses and not prefixes, 823 in Section 4.3. 825 Clarified of tunneling process in Section 4.3.2 827 Numerous editorial and clarification changes. 829 7.3. Changes from v02 to v03 831 Clarified high level description of implicit mode in Section 2.3 832 (thanks to Kent for suggesting appropriate text). 834 Clarified how IPv6 is tunneled over various tunneling modes allowed 835 by MIPv4 in Section 4.3.2 (thanks to Alex for spotting this). 837 Numerous editorial and clarification changes. 839 7.4. Changes from v01 to v02 841 Expanded high level description of explicit mode in Section 2.3. 843 Fixed alignment of figures. 845 Fixed length fields in extensions to reflect short extension format 846 correctly (thanks to Jun Awano for catching this one) 848 Removed section on Prefix Delegation and replaced it with more 849 generic text that allows any other address allocation mechanism to be 850 used to allocate IPv6 addresses and then extensions and mechanism 851 described in this specification can be used to registered these 852 addresses. 854 Numerous editorial and clarification changes. 856 7.5. Changes from v00 to v01 858 The Home Agent Considerations section was re-written and expanded 859 with a lot more details by adapting text from MIPv6 and NEMO 860 specifications. 862 New error codes were added to section 3.2 864 Allowed for any length prefix, not just 64 and 128. 866 Numerous editorial and clarification changes. 868 8. Acknowledgements 870 Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller and Pete McCann for 871 earlier work on this subject. Thanks also to Alex Petrescu for 872 suggesting the use of additional mechanisms for dynamic IPv6 address 873 allocation. Special thanks also to Sri Gundavelli and Kent Leung for 874 their thorough review and suggestions. 876 9. References 878 9.1. Normative References 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, March 1997. 883 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 884 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 885 October 1998. 887 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 888 (IPv6) Specification", RFC 2460, December 1998. 890 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 891 revised", RFC 3024, January 2001. 893 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 894 August 2002. 896 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 897 Network Address Translation (NAT) Devices", RFC 3519, 898 May 2003. 900 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 901 in IPv6", RFC 3775, June 2004. 903 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 904 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 905 RFC 3963, January 2005. 907 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 908 for IPv6 Hosts and Routers", RFC 4213, October 2005. 910 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 911 Architecture", RFC 4291, February 2006. 913 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 914 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 915 September 2007. 917 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 918 Address Autoconfiguration", RFC 4862, September 2007. 920 9.2. Informative References 922 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 923 October 1996. 925 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 926 Listener Discovery (MLD) for IPv6", RFC 2710, 927 October 1999. 929 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 930 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 931 March 2000. 933 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 934 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 936 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 937 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 939 Authors' Addresses 941 George Tsirtsis 942 Qualcomm 944 Phone: +908-947-7059 945 Email: tsirtsis@qualcomm.com; tsirtsisg@yahoo.com 947 Vincent Park 948 Qualcomm 950 Phone: +908-947-7084 951 Email: vpark@qualcomm.com 953 Hesham Soliman 954 Elevate Technologies 956 Phone: +614-111-410-445 957 Email: hesham@elevatemobile.com 959 Full Copyright Statement 961 Copyright (C) The IETF Trust (2008). 963 This document is subject to the rights, licenses and restrictions 964 contained in BCP 78, and except as set forth therein, the authors 965 retain all their rights. 967 This document and the information contained herein are provided on an 968 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 969 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 970 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 971 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 972 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 973 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 975 Intellectual Property 977 The IETF takes no position regarding the validity or scope of any 978 Intellectual Property Rights or other rights that might be claimed to 979 pertain to the implementation or use of the technology described in 980 this document or the extent to which any license under such rights 981 might or might not be available; nor does it represent that it has 982 made any independent effort to identify any such rights. Information 983 on the procedures with respect to rights in RFC documents can be 984 found in BCP 78 and BCP 79. 986 Copies of IPR disclosures made to the IETF Secretariat and any 987 assurances of licenses to be made available, or the result of an 988 attempt made to obtain a general license or permission for the use of 989 such proprietary rights by implementers or users of this 990 specification can be obtained from the IETF on-line IPR repository at 991 http://www.ietf.org/ipr. 993 The IETF invites any interested party to bring to its attention any 994 copyrights, patents or patent applications, or other proprietary 995 rights that may cover technology that may be required to implement 996 this standard. Please address the information to the IETF at 997 ietf-ipr@ietf.org. 999 Acknowledgment 1001 Funding for the RFC Editor function is provided by the IETF 1002 Administrative Support Activity (IASA).