idnits 2.17.1 draft-ietf-mip4-dsmipv4-10.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.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 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 (January 15, 2009) is 5579 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 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 4 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: July 19, 2009 H. Soliman 6 Elevate Technologies 7 January 15, 2009 9 Dual Stack Mobile IPv4 10 draft-ietf-mip4-dsmipv4-10.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 19, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This specification provides IPv6 extensions to the Mobile IPv4 50 protocol. The extensions allow a dual stack node to use IPv4 and 51 IPv6 home addresses as well as to move between IPv4 and dual stack 52 network infrastructures. 54 Table of Contents 56 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Implicit and Explicit Modes . . . . . . . . . . . . . . . 5 61 3. Extension Formats . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. IPv6 Prefix Request Extension . . . . . . . . . . . . . . 6 63 3.2. IPv6 Prefix Reply Extension . . . . . . . . . . . . . . . 7 64 3.3. IPv6 Tunneling Mode Extension . . . . . . . . . . . . . . 8 65 4. Mobile IP Registrations . . . . . . . . . . . . . . . . . . . 10 66 4.1. Registration Request . . . . . . . . . . . . . . . . . . . 10 67 4.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 10 68 4.3. Home Agent Considerations . . . . . . . . . . . . . . . . 11 69 4.3.1. IPv6 Reachability . . . . . . . . . . . . . . . . . . 11 70 4.3.2. Processing intercepted IPv6 Packets . . . . . . . . . 11 71 4.3.3. IPv6 Multicast Membership Control . . . . . . . . . . 13 72 4.4. Foreign Agent Considerations . . . . . . . . . . . . . . . 13 73 4.5. Mobile Node Considerations . . . . . . . . . . . . . . . . 13 74 4.6. Tunneling Impacts . . . . . . . . . . . . . . . . . . . . 15 75 4.7. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . . . 15 76 4.7.1. Dynamic IPv6 Prefix Delegation . . . . . . . . . . . . 15 77 4.8. Deregistration of IPv6 Prefix . . . . . . . . . . . . . . 16 78 4.9. Registration with a private CoA . . . . . . . . . . . . . 16 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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 prefix(s) in 129 addition to regular IPv4 home address registration 131 b. The solution supports static and dynamic IPv6 prefix delegation 133 2.2. Non-Goals 135 a. The solution does not provide support for IPv6 care-of address 136 registration 138 2.3. Implicit and Explicit Modes 140 As defined in NEMO [RFC3963], this specification also supports two 141 modes of operation; the implicit mode and the explicit mode. 143 In the implicit mode, the mobile node does not include any IPv6 144 prefix request extensions in the Registration Request. The home 145 agent can use any mechanism (not defined in this document) to 146 determine the IPv6 prefix(es) owned by the mobile node and to set up 147 forwarding for these prefixes. In this mode of operation all traffic 148 to and from the IPv6 prefixes MUST be encapsulated over the IPv4 149 tunnel between the mobile node's IPv4 home address and the IPv4 150 address of the home agent, and as such it is transparent to any 151 foreign agent in the path. This IPv4 tunnel is established by 152 mechanisms that are out of the scope of this document on both the 153 mobile node and home agent when operating in the implicit mode. 155 In the explicit mode, IPv6 bindings are signalled explicitly. The 156 mobile node includes one or more IPv6 prefix request extensions in 157 the Registration Request, while the home agent returns corresponding 158 IPv6 prefix reply extensions to accept/reject the IPv6 bindings. 160 Additionally, in the explicit mode, the mobile node (when co-located 161 mode of operation is used) can indicate whether IPv6 traffic should 162 be tunneled to the care-of address or the home address of the mobile 163 node. 165 The rest of this specification is primarily defining the explicit 166 mode. 168 3. Extension Formats 170 The following extensions are defined according to this specification. 172 3.1. IPv6 Prefix Request Extension 174 A new skippable extension to the Mobile IPv4 registration request 175 message in accordance to the short extension format of [RFC3344] is 176 defined here. 178 This extension contains a mobile IPv6 network prefix and its prefix 179 length. 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | Sub-Type | Prefix Length | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 + + 188 | | 189 + Mobile IPv6 Network Prefix + 190 | | 191 + + 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 1: IPv6 Prefix Request Extension 197 Type 199 TBD (DSMIPv4 Extension)(skippable type to be assigned by IANA) 201 Length 203 18 205 Sub-Type 207 1 (IPv6 Prefix Request) 209 Prefix Length 211 A sixteen-byte field containing the Mobile IPv6 Network Prefix; 212 all insignificant (low-order) bits (beyond the Prefix Length) MUST 213 be set to 0 by the originator of the option and ignored by the 214 receiver 216 Mobile IPv6 Network Prefix 218 A sixteen-byte field containing the Mobile IPv6 Network Prefix 220 3.2. IPv6 Prefix Reply Extension 222 A new skippable extension to the Mobile IPv4 registration reply 223 message in accordance to the short extension format of [RFC3344] is 224 defined here. 226 This extension defines a mobile IPv6 network prefix and its prefix 227 length, as well as a code. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | Sub-Type | Code | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Prefix Length | Reserved | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 236 | | 237 + + 238 | | 239 + Mobile IPv6 Network Prefix + 240 | | 241 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2: IPv6 Prefix Reply Extension 247 Type 249 TBD (DSMIPv4 Extension)(skippable type to be assigned by IANA) 251 Length 253 20 255 Sub-Type 257 2 (IPv6 Prefix Reply) 259 Code 261 A value indicating the result of the registration request with 262 respect to the IPv6 home prefix registration. See below for 263 currently defined Codes. 265 Prefix Length 267 Indicates the prefix length of the prefix included in the Mobile 268 IPv6 Network Prefix field. A value of 255 indicates that a link 269 local address is included in the Mobile IPv6 Network Prefix field. 271 Reserved 273 Set to 0 by the sender, ignored by the receiver 275 Mobile IPv6 Network Prefix 277 A sixteen-byte field containing the Mobile IPv6 Network Prefix; 278 all insignificant (low-order) bits (beyond the Prefix Length) MUST 279 be set to 0 by the originator of the option and ignored by the 280 receiver 282 The following values are defined for use as a Code value in the above 283 extension 285 0 registration accepted, IPv6 to be tunneled to HoA 287 1 registration accepted, IPv6 to be tunneled to CoA 289 8 registration rejected, reason unspecified 291 9 registration rejected, administratively prohibited 293 Note that a registration reply that does not include an IPv6 prefix 294 reply extension, when received in response to a registration request 295 carrying at least one instance of the IPv6 prefix request extension, 296 indicates that the home agent does not support IPv6 extensions and 297 thus has ignored such extensions in the registration request. 299 3.3. IPv6 Tunneling Mode Extension 301 A new skippable extension to the Mobile IPv4 registration request 302 message in accordance to the short extension format of [RFC3344] is 303 defined here. 305 By including this extension in a registration request the sender 306 indicates that IPv6 traffic can be tunneled to the mobile node's CoA. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type | Length | Sub-Type | Reserved | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Figure 3: IPv6 Tunneling Mode Extension 316 Type 318 TBD (DSMIPv4 Extension) (skippable type to be assigned by IANA) 320 Length 322 2 324 Sub-Type 326 3 (IPv6 Tunneling Mode) 328 Reserved 330 Set to 0 by the sender, ignored by the receiver 332 4. Mobile IP Registrations 334 4.1. Registration Request 336 A mobile node MAY include in a registration request one or more IPv6 337 prefix request extensions defined in this specification. 339 A mobile node MAY also include exactly one IPv6 tunneling mode 340 extension when it uses the co-located care-of address mode of 341 [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 4.2. Registration Reply 351 The mechanism described in this specification depends on skippable 352 extensions. For that reason, a registration reply that does not 353 include an IPv6 prefix reply extension, in response to a registration 354 request including an IPv6 prefix request extension, indicates that 355 the home agent does not support IPv6 extensions and has ignored the 356 request. 358 If an IPv6 prefix reply extension is included in a registration 359 reply, then the extension indicates the success or failure of the 360 IPv6 prefix registration. The IPv6 prefix reply extension does not 361 affect in any way the code value in the registration reply header but 362 it is superseded by it. In other words if the code field in the 363 registration reply header is set to a reject code, then all IPv6 364 prefix request extensions are also rejected. If the code field in 365 the registration reply header, however, is set to an accept code, 366 then an IPv6 prefix reply extension with a code field set to a reject 367 code only rejects the binding for the specific IPv6 prefix indicated 368 in the same extension. 370 Note that a rejecting IPv6 prefix reply extension has the same effect 371 as not including such an extension at all, in the sense that in both 372 cases the mobile node must act as if the corresponding IPv6 prefix 373 request extension included in the registration request was rejected. 374 Of course, the inclusion of the IPv6 prefix reply extension allows 375 the home agent to indicate why a given IPv6 prefix request extension 376 was rejected. A detailed description of how the mobile node handles 377 different IPv6 prefix reply extension code values and the absence of 378 IPv6 prefix reply extensions is given in Section 4.5. 380 4.3. Home Agent Considerations 382 The dual stack home agent defined in this specification is a Mobile 383 IPv4 home agent in that, it MUST operate as defined in MIPv4 384 [RFC3344]. In addition to that, the following mechanisms are defined 385 in this specification. 387 For each IPv6 prefix request extension included in a valid 388 registration request, a home agent that supports this specification 389 SHOULD include a corresponding IPv6 prefix reply extension in the 390 registration reply message. The home agent MUST NOT include more 391 than one IPv6 prefix reply extension for the same prefix. For each 392 accepted IPv6 prefix the home agent MUST decide the tunneling mode it 393 is going to use and set the code field of the IPv6 prefix reply 394 extension to the appropriate value. The IPv6 prefix field of each of 395 the IPv6 prefix reply extensions included in the registration reply 396 MUST match the IPv6 prefix field of an IPv6 prefix request extension 397 included in the corresponding registration request message. 399 When the home agent sends a successful registration reply to the 400 mobile node, with the code field of a corresponding IPv6 prefix reply 401 extension set to one of the "registration accepted" values, the home 402 agent indicates that the IPv6 prefix is registered for the lifetime 403 granted for the binding. It also indicates the tunneling mode used 404 i.e., tunneling to home address or care-of address, based on the 405 value of the code field used in the IPv6 prefix reply extension. 407 Note that since only IPv6 prefixes (and not addresses) are supported 408 by this specification, there is no need for Duplicate Address 409 Detection. The home agent, however, MUST check that registered 410 prefixes are not overlapping so that all addresses under each 411 registered prefix belong to a single mobile node at any one time. 412 These prefixes MUST NOT appear as on-link to any other node (e.g., 413 via Router Advertisements). 415 4.3.1. IPv6 Reachability 417 For each registered IPv6 prefix, the home agent MUST advertise its 418 reachability as defined in NEMO [RFC3963], section 6.3. 420 4.3.2. Processing intercepted IPv6 Packets 422 A dual stack home agent that supports the IPv6 extensions defined in 423 this specification, MUST keep track of the following IPv6 related 424 state for the mobile nodes it supports, in addition to the state 425 defined in [RFC3344]. 427 - Registered IPv6 prefix(es) and prefix length(s) 428 - Tunneling mode for IPv6 traffic: 430 - Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA. 432 - Tunnel to CoA and accept IPv6 tunneled from CoA. 434 When IPv6 traffic is encapsulated over the tunnel between the HA and 435 the mobile node's care-off address, the tunneling mechanism used 436 should be the same as the mechanism negotiated by the Mobile IP 437 header as defined in MIPv4 [RFC3344]. In that case, when IPinIP 438 encapsulation is negotiated, IPv6 is tunneled over IPv4 according to 439 [RFC4213]. GRE also allow tunneling of IPv6 packets by setting the 440 Protocol Type [RFC2784] field, to the appropriate payload type 441 defined for IPv6 by IANA. Minimal Encapsulation [RFC2004] cannot be 442 used, since the second (inner) IP header is IPv6, which is not 443 supported by [RFC2004]. 445 When IPv6 traffic is encapsulated over the tunnel between the HA and 446 the mobile node's home address, IPv6 is always tunneled over IPv4 447 according to [RFC4213].The resulting IPv4 packet is then delivered 448 just like any other IPv4 packet addressed to the IPv4 HoA (using the 449 tunneling for normal IPv4 traffic, possibly going via FA). 451 Tunneling mode selection for IPv6 traffic depends on the following 452 parameters in a successful registration request: 454 1) A registration request is received with one or more IPv6 prefix 455 request extensions. An IPv6 tunneling mode extension is not 456 included. 458 All IPv6 packets destined to the registered IPv6 prefix(es) MUST 459 be tunneled by the home agent to the registered IPv4 home address 460 of the mobile node. The home agent first encapsulates the IPv6 461 packet, addressing it to the mobile node's IPv4 home address, and 462 then tunnels this encapsulated packet to the foreign agent. This 463 extra level of encapsulation is required so that IPv6 routing 464 remains transparent to a foreign agent that does not support IPv6. 465 When received by the foreign agent, the unicast encapsulated 466 packet is detunneled and delivered to the mobile node in the same 467 way as any other packet. The mobile node must decapsulate the 468 received IPv4 packet in order to recover the original IPv6 packet. 470 Additionally, the home agent MUST be prepared to accept reverse 471 tunneled packets from the IPv4 home address of the mobile node 472 encapsulating IPv6 packets sent by that mobile node. 474 2) A registration request is received with one or more IPv6 prefix 475 request extensions. An IPv6 tunneling mode extension is included. 477 All IPv6 packets destined to the registered IPv6 prefix(es) SHOULD 478 be tunneled by the home agent to the registered care-of address of 479 the mobile node. Additionally, the home agent SHOULD be prepared 480 to accept reverse tunneled packets from the care-of address of the 481 mobile node encapsulating IPv6 packets sent by that mobile node. 482 The home agent MAY ignore the presence of the IPv6 tunneling mode 483 extension and act as in case (1) above. 485 The home agent MUST check that all inner IPv6 packets received from 486 the mobile node over a tunnel with the mobile node's home address or 487 the care-of address as the outer source address, include a source 488 address that falls under the registered IPv6 prefix(es) for that 489 mobile node. If the source address of the outer header of a tunneled 490 packet is not the registered IPv4 care-of address or the registered 491 IPv4 home addresses, the packet SHOULD be dropped. If the source 492 address of the inner header of an tunneled packet does not match any 493 of the registered prefixes the packet SHOULD be dropped. 495 Multicast packets addressed to a group to which the mobile node has 496 successfully subscribed, MUST be tunneled to the mobile node. 498 4.3.3. IPv6 Multicast Membership Control 500 IPv6 multicast membership control is provided as defined in MIPv6 501 [RFC3775], Section 10.4.3. The only clarification required for the 502 purpose of this specification is that all MLD [RFC2710] or MLDv2 503 [RFC3810] messages between the mobile node and the home agent MUST be 504 tunneled over an IPv4 tunnel between the mobile node's IPv4 home 505 address and the home agent's IPv4 address, bypassing the foreign 506 agent. Note that if tunneling to the care-of address has been 507 negotiated for other traffic, then the rest of the traffic continues 508 using this tunnel. 510 4.4. Foreign Agent Considerations 512 This specification does not afect the operation of the foreign agent. 514 4.5. Mobile Node Considerations 516 A dual stack mobile node that supports the extensions described in 517 this document MAY use these extensions to register its IPv6 518 prefix(es) while moving between access routers. 520 The mobile node MAY include one or more IPv6 prefix request 521 extension(s) in the registration request. 523 In this case the mobile MUST take the following action depending on 524 the extensions included in the registration reply it receives in 525 response to the registration request: 527 1) The registration reply does not include any IPv6 prefix reply 528 extensions. 530 The mobile node MUST assume that the home agent does not support 531 the extensions defined in this specification. The mobile node 532 SHOULD continue to operate according to MIPv4 [RFC3344]. 534 2) The registration reply includes one or more IPv6 prefix reply 535 extensions. 537 The mobile node MUST match each IPv6 prefix reply extension with 538 one of the IPv6 prefix request extensions earlier included in the 539 corresponding registration request message. 541 If a matching IPv6 prefix reply extension is not included for one 542 or more of corresponding IPv6 prefix request extensions included 543 in the registration request message, the mobile node MUST assume 544 that these IPv6 prefixes are rejected. 546 For each matching IPv6 prefix reply extension the mobile node MUST 547 inspect the code field. If the field is set to a rejection code 548 then the corresponding IPv6 prefix registration has been rejected. 549 If the code field is set to an acceptance code then the 550 corresponding IPv6 prefix registration has been accepted. 552 If the code field is set to "0" then the mobile node MUST be 553 prepared to send/receive IPv6 packets encapsulated in the 554 bidirectional tunnel between the home agent address and the 555 registered IPv4 home address of the mobile node. 557 If the code field is set to "1" then the mobile node MUST act as 558 follows: 560 - Assuming the co-located care-of address mode is used, the mobile 561 node MUST be prepared to send/receive IPv6 packets over the 562 bidirectional tunnel between the home agent address and its co- 563 located care-of address. Otherwise the mobile node SHOULD act as 564 in the case where the code field is set to "0". 566 The mobile node SHOULD include exactly one IPv6 tunneling mode 567 extension if it uses the co-located care-of address model and it 568 wants to request that IPv6 packets are tunneled to its co-located 569 care-of address. If the mobile node uses the co-located care-of 570 address model but it does not include the IPv6 tunneling mode 571 extension, the home agent will tunnel IPv6 traffic to the mobile 572 node's IPv4 home address. The mobile node MUST NOT include an IPv6 573 tunneling mode extension if it uses the foreign agent care-of address 574 mode of operation. Note that if the mobile node includes an IPv6 575 tunneling mode extension in this case, IPv6 packets could be tunneled 576 to the FA by the HA. The FA is then likely to drop them since it 577 will not have appropriate state to process them. 579 4.6. Tunneling Impacts 581 When IPv6 runs over an IPv4 tunnel, the IPv6 tunnel end points can 582 treat the IPv4 tunnel as a single hop link as defined in [RFC4213]. 583 The two tunnel end points, e.g., mobile node and home agent, MUST 584 configure link local IPv6 addresses as defined in [RFC4213], section 585 3.7, while they MUST also adhear to the neighbor discovery 586 requirements of the same specification, section 3.8 and the hop limit 587 requirements of section 3.3. 589 With respect to the Tunnel MTU an implementation MUST support the 590 Static Tunnel MTU approach as defined in [RFC4213], section 3.2. 591 Implementation and use of the Dynamic Tunnel MTU method defined in 592 the same section of [RFC4213] is OPTIONAL. 594 To accommodate traffic that uses Explicit Congestion Notification 595 (ECN), it is RECOMMENDED that the ECN and DSCP information is copied 596 between the inner and outer header as defined in [RFC3168] and 597 [RFC2983]. It is RECOMMENDED that the full-functionality option 598 defined in section 9.1.1 of [RFC3168] is used to deal with ECN 600 4.7. IPv6 Prefixes 602 An implementation can use any number of mechanisms to allocate IPv6 603 prefixes to a mobile node. Once one or more IPv6 prefixes are 604 allocated, they can be registered using the extensions and mechanism 605 already described in this specification. 607 How a home agent decides to accept an IPv6 prefix for a given mobile 608 node is out of scope of this specification. Local configuration or 609 external authorization via an authorization system e.g., Diameter 610 [RFC3588], or other mechanisms may be used to make such 611 determination. 613 4.7.1. Dynamic IPv6 Prefix Delegation 615 A dual stack mobile node MAY use prefix delegation as defined in 616 DHCPv6 Prefix Delegation [RFC3633] to get access to IPv6 prefixes. 617 In that case, if the mobile node is not directly attached to its home 618 agent, the mobile node MUST first register its IPv4 home address as 619 per MIPv4 [RFC3344]. When that is done the mobile node can generate 620 a link local IPv6 address as per [RFC4213], section 3.7. The mobile 621 node then sends registration request to its home agent, including an 622 IPv6 prefix request extension with prefix length field set to 255 and 623 by setting the mobile IPv6 network prefix field to the localy 624 generated link local address. If the registration reply message 625 includes an IPv6 prefix reply extension with the code field set to a 626 success code the mobile node can use the tunnel to send and receive 627 IPv6 link local packets. The mobile node can now send DHCPv6 628 messages according to [RFC3633]. All IPv6 messages at this stage 629 MUST be tunneled over the IPv4 tunnel between the mobile node's IPv4 630 home address and the home agent's IPv4 address. 632 Once prefixes are delegated, and assuming explicit mode is used, the 633 mobile node SHOULD send a registration request with appropriate IPv6 634 prefix request extensions to the home agent to register the delegated 635 prefixes. 637 4.8. Deregistration of IPv6 Prefix 639 The mobile IP registration lifetime included in the registration 640 request header is valid for all the bindings created by the 641 registration request, which may include bindings for IPv6 prefix(es). 643 A registration request with a zero lifetime can be used to remove all 644 bindings from the home agent. 646 A re-registration request with non-zero lifetime can be used to 647 deregister some of the registered IPv6 prefixes by not including 648 corresponding IPv6 prefix request extensions in the registration 649 request message. 651 4.9. Registration with a private CoA 653 If the care-of address is a private address then Mobile IP NAT 654 Traversal as [RFC3519] MAY be used in combination with the extensions 655 described in this specification. In that case, to transport IPv6 656 packets, the next header field of the Mobile Tunnel Data message 657 header [RFC3519] MUST be set to the value for IPv6. Note that in 658 that case the encapsulation field of the UDP Tunnel Request Extension 659 defined in [RFC3519] MUST be set to zero. 661 5. Security Considerations 663 This specification operates in the security constraints and 664 requirements of [RFC3344]. It extends the operations defined in 665 [RFC3344] for IPv4 home addresses to cover home IPv6 prefixes and 666 provides the same level of security for both IP address versions. 668 Home agents MUST perform appropriate checks for reverse tunneled IPv6 669 packets similar to what is defined in [RFC3024] for IPv4 packets. 670 The check defined in [RFC3024] requires that the outer header's 671 source address is set to a registered care-of address for the mobile 672 node and as such the same check protects from attacks whether the 673 encapsulated (inner) header is IPv4 or IPv6. 675 In addition to that, the home agent MUST check that the source 676 address of the inner header is a registered IPv4 home address or IPv6 677 prefix for this mobile node. If that is not the case, the home agent 678 SHOULD silently discard the packet and log the event as a security 679 exception. 681 Security devices should look for IPv6 packets encapsulated over IPv4 682 either directly to the mobile node's care-of address or via double 683 encpasulation first to the mobile node's IPv4 home address and then 684 to the mobile node's care-of addres. Interactions with Mobile IPv4 685 and IPsec have been covered elsewhere, for instance in [RFC5265] and 686 [RFC5266]. 688 6. IANA Considerations 690 This specification requires the allocation of a new type number for 691 DSMIPv4 extensions, from the space of numbers for skippable mobility 692 extensions (i.e., 128-255), defined for Mobile IPv4 [RFC3344] at 693 http://www.iana.org/assignments/mobileip-numbers, under extensions 694 appearing in Mobile IP control messages.. 696 This specification also creates a new subtype space for the type 697 number of this extension. The subtype values 1, 2 and 3 are defined 698 in this specification, while the rest of the sub-types are reserved 699 and available for allocation based on expert review. 701 Finally, this specification creates a new space for the code field of 702 the IPv6 prefix reply extension. Values 0, 1, 8, and 9 are defined 703 in this specification. Values 2-7 are reserved for accept codes and 704 values 10-255 are reserved for reject codes. 706 Similar to the procedures specified for Mobile IPv4 [RFC3344] number 707 spaces, future allocations from the two number spaces require expert 708 review [RFC5226]. 710 7. Acknowledgements 712 Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller and Pete McCann for 713 earlier work on this subject. Thanks also to Alex Petrescu for 714 various suggestions. Special thanks also to Sri Gundavelli and Kent 715 Leung for their thorough review and suggestions. 717 8. References 719 8.1. Normative References 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, March 1997. 724 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 725 (IPv6) Specification", RFC 2460, December 1998. 727 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 728 revised", RFC 3024, January 2001. 730 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 731 August 2002. 733 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 734 Network Address Translation (NAT) Devices", RFC 3519, 735 April 2003. 737 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 738 Host Configuration Protocol (DHCP) version 6", RFC 3633, 739 December 2003. 741 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 742 in IPv6", RFC 3775, June 2004. 744 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 745 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 746 RFC 3963, January 2005. 748 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 749 for IPv6 Hosts and Routers", RFC 4213, October 2005. 751 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 752 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 753 May 2008. 755 8.2. Informative References 757 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 758 October 1996. 760 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 761 Listener Discovery (MLD) for IPv6", RFC 2710, 762 October 1999. 764 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 766 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 767 March 2000. 769 [RFC2983] Black, D., "Differentiated Services and Tunnels", 770 RFC 2983, October 2000. 772 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 773 of Explicit Congestion Notification (ECN) to IP", 774 RFC 3168, September 2001. 776 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 777 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 779 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 780 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 782 [RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across 783 IPsec-Based VPN Gateways", RFC 5265, June 2008. 785 [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and 786 Mobility Using Mobile IPv4 and IKEv2 Mobility and 787 Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008. 789 Authors' Addresses 791 George Tsirtsis 792 Qualcomm 794 Email: tsirtsis@googlemail.com 796 Vincent Park 797 Qualcomm 799 Phone: +908-947-7084 800 Email: vpark@qualcomm.com 802 Hesham Soliman 803 Elevate Technologies 805 Phone: +614-111-410-445 806 Email: hesham@elevatemobile.com