idnits 2.17.1 draft-oulai-mext-dsmip-ro-00.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 : ---------------------------------------------------------------------------- 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the Kbm is created, the MN sends a BU to the CN. If the BU is sent to trigger RO for traffic using v6HoA only, the BU is constructed as defined in [RFC3775]. In the case the MN requires v4HoA RO only, it includes the v4HoA option and the parameter built based on the Kbm generated for the v4HoA. If v6HoA and v4HoA RO are required, the MN MUST include both HoA options and both parameters. The MN also inserts an IPv4 Route Optimization mode option containing the value chosen after the CoTI/CoT messages exchange. See Section 6.3. The BU MUST not be encapsulated as IPv6 connectivity exists between MN and CN. When receiving the BU message, the CN recomputes the Home and CareOf Keygens then the binding management key. Note that distinct BCE will be created for v4HoA and v6HoA. Then, the CN MUST send a BAck. The CN MUST also include the IPv4 RO mode option in the BAck. Not receiving this option in the BAck means that the CN does not support IPv4 RO. -- The document date (March 3, 2009) is 5532 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) == Missing Reference: 'PS REFERENCE' is mentioned on line 100, but not defined == Unused Reference: 'RFC4449' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC4866' is defined on line 593, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-09 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mext Working Group D. Oulai 3 Internet-Draft S. Krishnan 4 Intended status: Standards Track Ericsson 5 Expires: September 4, 2009 H. Soliman 6 Elevate Technologies 7 March 3, 2009 9 DSMIPv6 Route Optimization 10 draft-oulai-mext-dsmip-ro-00.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 September 4, 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 49 mobility for mobile hosts. While route optimization is well defined 50 for IPv6 traffic, this feature is not defined for IPv4. However, 51 Route Optimization has many advantages as reduced delays and lower 52 load for the Home Agent. This document proposes solutions for the 53 different scenarios where IPv4 route optimization is performed. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions used in this document . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Corresponding Node considerations . . . . . . . . . . . . . . 6 61 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Extensions to DSMIP . . . . . . . . . . . . . . . . . . . . . 9 63 6.1. Data structures . . . . . . . . . . . . . . . . . . . . . 9 64 6.2. IPv4 Route Optimization mode option . . . . . . . . . . . 9 65 6.3. Route Optimization mode negotiation . . . . . . . . . . . 9 66 6.4. Keygen tokens generation . . . . . . . . . . . . . . . . . 9 67 6.4.1. Home keygen token generation . . . . . . . . . . . . . 10 68 6.4.2. CareOf keygen token generation . . . . . . . . . . . . 10 69 7. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Mobile Node with IPv4 Home address . . . . . . . . . . . . 11 71 7.1.1. Return Routability procedure . . . . . . . . . . . . . 11 72 7.1.2. Binding registration . . . . . . . . . . . . . . . . . 12 73 7.1.3. Packet processing . . . . . . . . . . . . . . . . . . 13 74 7.2. Mobile Node with IPv4 CareOf address only . . . . . . . . 14 75 7.2.1. Return Routability procedure . . . . . . . . . . . . . 14 76 7.2.2. Binding registration . . . . . . . . . . . . . . . . . 15 77 7.2.3. Packet processing . . . . . . . . . . . . . . . . . . 15 78 7.2.4. NAT keepalives . . . . . . . . . . . . . . . . . . . . 16 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 10. Normative References . . . . . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 traffic 87 for mobile hosts [I-D.ietf-mext-nemo-v4traversal]. DSMIP is relevant 88 for situations where applications MUST be run using IPv4 or when the 89 MN is located in an IPv4 only network. DSMIP introduces two new 90 address options: the IPv4 Home Address and the IPv4 CareOf Address 91 options. With those options, a MN can send and receive IPv4 traffic 92 although all the mobility signaling is MIPv6 based. Therefore, there 93 is no need to have a MIPv4 stack on the mobile. 95 On the other hand, route optimization (RO) is a process that allows a 96 MN to communicate directly with a CN without transiting by an anchor, 97 the Home Agent. There are several benefits from RO as shorter path 98 delay, reduced bandwidth consumption and reduced load on the HA. 99 However, RO is not defined for DSMIP. The problem statement of DSMIP 100 RO can be found in [PS REFERENCE]. 102 This document provides a solution for DSMIP RO. We study two 103 scenarios: 105 1. MN with a v4HoA 106 This scenario implies that the MN has also a v6HoA as all DSMIP 107 signaling is based on the v6HoA. This scenario only considers 108 v6CoA for the MN as the v4CoA case is tackled in the next 109 scenario. 111 2. MN with a v4CoA only 112 In this case, the MN is connected to an IPv4 only network. The 113 scenario considers v6HoA and v4HoA. 115 We do not consider the situations where the MN has both v6CoA and 116 v4CoA configured as [I-D.ietf-mext-nemo-v4traversal] clearly states 117 that v6CoA SHOULD be preferred over the v4CoA. Moreover, we reuse as 118 much as possible MIPv6 RO mechanisms and add extensions when needed. 120 2. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Terminology 128 All the general mobility-related terms used in this document are to 129 be interpreted as defined in the Mobile IPv6 [RFC3775] and DSMIP 130 [I-D.ietf-mext-nemo-v4traversal] base specifications. 132 RRP: Return Routability Procedure 134 v4CN: IPv4 address of the CN 136 v6CN: IPv6 address of the CN 138 v4CoA: IPv4 CareOf Address of the MN 140 v6CoA: IPv6 CareOf Address of the MN 142 v4HoA: IPv4 Home Address of the MN 144 v6HoA: IPv6 Home Address of the MN 146 v4HoA-map: IPv4 HoA mapped IPv6 address 148 4. Corresponding Node considerations 150 To support this specification, a CN MUST be dual-stacked to 151 understand some of the new options introduced here. Note that this 152 specification works also if the CN is in an IPv4 only network. 153 Moreover, all CNs supporting this specification MUST listen the DSMIP 154 UDP port to receive messages sent from v4CoAs as there could be 155 NAT(s) between the MN and the CN. On the other hand, if the HoA type 156 or the CoA type used by the MN differs from the type of address 157 configured by the CN, v4v6 transition mechanisms MUST be used to 158 transfer the packets. However, this is out of scope of this 159 document. 161 5. Overview 163 To perform RO for DSMIP, we first need to guarantee that the v6HoA, 164 v6CoA, v4HoA and v4CoA belong to the MN. MIPv6 RRP provides 165 reachability test for the v6HoA and v6CoA only. Therefore, we define 166 some steps for the IPv4 addresses reachability tests. As DSMIP 167 mandates v6HoA for the MN, the v4HoA reachability test MUST also 168 ensure that the v4HoA and v6HoA belong to the same MN. For this 169 reason, the HoT message is encapsulated in a IPv4 header with v4HoA 170 as destination address. If the MN receives the Home Keygen Token, it 171 means that it is reachable by the v4HoA. Note that the v4HoA 172 reachability test and the v6HoA are decoupled for security reasons, 173 which means the CN has to send two different CoT messages for the 174 reachability test. See Section 7.1.1.1 for more details. 176 The v4CoA reachability test is more complex. Note that this test is 177 performed only if the MN has only a v4CoA because DSMIP specification 178 states that v6CoA SHOULD be prefered over v4CoA. In this test, the 179 CN MUST replace the v6CoA in the keygen token generation by a 180 combination of the source address of the BU, the v4CoA and the UDP 181 port as the MN can be in a private network. This is need to ensure 182 that the generated CareOf Keygen is unique for communication with 183 that mobile node. The CoT message is encapsulated in an IPv4 Header 184 with v4CoA as destination address. See Section 7.2.1.2 for more 185 details. 187 Another important aspect to perform DSMIP RO is the routing. The UDP 188 encapsulation is used the same way as in 189 [I-D.ietf-mext-nemo-v4traversal] for private addresses. As defining 190 new IPv4 options is not recommended, we have three routing 191 possibilities: 193 1. IPv6 tunnel 194 The IPv4 packet is encapsulated as data in an IPv6 tunnel. The 195 tunnel header is represented by the IPv6 header as in MIPv6 RO. 196 The normal MIPv6 RO process is performed then the IPv4 packet is 197 processed by the IPv4 module. 199 2. IPv4 mapped address 200 This approach only modifies the address in the HoA option and the 201 Type 2 Routing Header. The v6HoA is replaced with an IPv4 mapped 202 IPv6 address. Therefore, MIPv6 RO process is performed and after 203 address swapping and IPSec operations, the endpoint MUST be able 204 to forward the packet to the upper layer considering the IPv4 205 HoA. 207 3. IPv4 tunnel 208 This is use when the MN only has an v4CoA and IPv6 routing is not 209 possible. Therefore, we perform an IP in IP tunnelling with the 210 v4CoA as destination address for the outer header. Note that 211 IPv4-UDP encapsulation is performed when NAT is detected. 213 A new option, IPv4 Route Optimization mode option, is defined in 214 order to negotiate the routing mode (See Section 6.2). This option 215 is included in the CoTI/CoT messages. If the CN responds with a 216 different mode than the one requested by the MN, the MN MUST use the 217 mode advertised by the CN or stop RO process. 219 6. Extensions to DSMIP 221 6.1. Data structures 223 IPv4 HoA, IPv4 CoA and IPv4 RO mode fields MUST be added to the CN 224 BCE as described in [RFC3775]. IPv4 RO mode and v4CN field MUST be 225 added to the BULE as described in [RFC3775]. 227 6.2. IPv4 Route Optimization mode option 229 This option is created to negotiate the IPv4 RO mode. 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | Mode | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Type - TBD 237 Length - 3 239 Mode - 0 : All modes supported 240 1 : IPv6 encapsulation 241 2 : IPv4 mapped IPv6 addresses 242 3 : IPv4 encapsulation 243 4 : IPv4-UDP encapsulation 245 IPv4 Route Optimization mode Option 247 6.3. Route Optimization mode negotiation 249 The MN MUST include an IPv4 RO mode option in the CoTI message. The 250 choice of the IPv4 RO mode included in the CoTI message can be driven 251 by policies and is out of the scope of this specification. If the CN 252 detects NAT(s) presence, it MUST respond in the CoT message with 253 value 4 (IPv4-UDP) as RO mode. If the CN supports the mode requested 254 by the MN and there is no NAT(s) in between, the CN SHOULD 255 acknowledge the mode chosen by the MN. If the CN responds with a 256 different mode, the MN MUST use the RO mode chosen by the CN. 257 Otherwise, if the CN indicates 0 (All modes supported), the MN uses 258 the mode initially selected in the CoTI message. 260 6.4. Keygen tokens generation 262 This section describes the Home and CareOf Keygen generation when 263 v4HoA or v4CoA is involved in the RRP. The token generation process 264 MUST include the IPv4 addresses as the CN is stateless during the 265 RRP. 267 6.4.1. Home keygen token generation 269 The CN uses the same formula as used in [RFC3775], which is: 271 home keygen token := 272 First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))) 274 In case a v4HoA is involved, the home address is replaced by a 275 combined home address described below: 277 Combined HoA:= (v6HoA | v4HoA) 279 6.4.2. CareOf keygen token generation 281 In case the MN is using a v4CoA, the CareOf keygen token generation 282 is more complex as there could be NAT(s) between the MN and the CN. 283 As the MN could be in a private network, the CoA value used for 284 calculation MUST be unique. The CN uses the same formula as used in 285 [RFC3775], which is: 287 careOf keygen token := 288 First (64, HMAC_SHA1 (Kcn, (careOf address | nonce | 1))) 290 In case a v4CoA is involved, the careOf address is replaced by a 291 combined careOf address described below: 293 Combined CoA:= 294 (v4CoA | Source UDP port | Source IPv4 address of the CoTI message) 296 This insures that the value used for careOf token calculation is 297 unique even if there are NATs in between. 299 7. Protocol operation 301 In this document, we assume that MN and CN are dual stacked. The 302 solutions proposed depend of the addresses configured on the MN and 303 the CN. We assume that the MN knows at which address to reach the CN 304 by using DNS for example. 306 7.1. Mobile Node with IPv4 Home address 308 If the MN has v6CoA and v4CoA configured at the same time, 309 [I-D.ietf-mext-nemo-v4traversal] suggests to use the v6CoA. The case 310 where the MN is configured with v4CoA only is tackled in Section 7.2. 312 7.1.1. Return Routability procedure 314 The RRP procedure is presented in Figure 1. 316 Mobile node Home agent Correspondent node 317 | | 318 | Home Test Init (HoTI) | | 319 |------------------------->|------------------------->| 320 | | | 321 | Care-of Test Init (CoTI) | 322 |---------------------------------------------------->| 323 | | | 324 | | v4HoA Home Test (HoT) | 325 |<-------------------------|<-------------------------| 326 | | | 327 | v4CoA Care-of Test (CoT)| 328 |<----------------------------------------------------| 329 | | 331 Figure 1: Return Routability procedure for v4HoA and v4CoA 333 7.1.1.1. Home address reachability test 335 The MN includes a v4HoA option in the HoTI. If a CN receives a HoTI 336 message without any HoA option, it MUST process it as a request for 337 v6HoA reachability test. In this case, the Home keygen token and the 338 HoT message are generated as described in [RFC3775]. If the HoTI 339 message contains a v4HoA option only, the CN MUST process the message 340 as a v4HoA reachability test. After generating the Home Keygen token 341 based on the v6HoA and the v4HoA, the CN responds with a HoT message. 343 If a v4HoA reachability test is, the CN MUST encapsulate the HOT 344 message in an IPv4 header. The HoT message is descried below: 346 External header: 347 Src = v4CN 348 Dest = v4HoA 349 Internal header: 350 Src = v6CN 351 Dest = v6HoA 352 HoT message 353 IPv4 HoA Option = v4HoA 354 Other options 356 HoT message for v4HoA reachability test 358 The MN MUST set the Hop Limit to 1 for the inner IPv6 header. 359 Therefore, the IPv4 tunnel endpoint MUST be also the destination for 360 the HoT message. If the MN receives the HoT message at v4HoA 361 address, it will internally transfer the packet to its IPv6 process 362 as there is an v6inv4 encapsulation. The MN will also noticed that 363 he is the IPv6 endpoint of the HoT message and will process it. If 364 the MN is not the IPv6 endpoint, the HoT message will be dropped 365 because either there is no way of forwarding IPv6 packets or either 366 the MN will decrement the Hop limit to 0. By this way, we can simply 367 check that v4HoA and v6HoA belong to the same MN. 369 7.1.1.2. CareOf address reachability test 371 The MN includes a v4HoA option and an IPv4 RO mode option in the CoTI 372 message and the CN responds with a CoT message after generating the 373 CareOf Keygen token based on the v6CoA. Moreover, tokens and Kbm 374 generation are based on the v6CoA address. See Section 6.3 and 375 Section 6.4 for details. 377 7.1.2. Binding registration 379 When the Kbm is created, the MN sends a BU to the CN. If the BU is 380 sent to trigger RO for traffic using v6HoA only, the BU is 381 constructed as defined in [RFC3775]. In the case the MN requires 382 v4HoA RO only, it includes the v4HoA option and the parameter built 383 based on the Kbm generated for the v4HoA. If v6HoA and v4HoA RO are 384 required, the MN MUST include both HoA options and both parameters. 385 The MN also inserts an IPv4 Route Optimization mode option containing 386 the value chosen after the CoTI/CoT messages exchange. See 387 Section 6.3. The BU MUST not be encapsulated as IPv6 connectivity 388 exists between MN and CN. 389 When receiving the BU message, the CN recomputes the Home and CareOf 390 Keygens then the binding management key. Note that distinct BCE will 391 be created for v4HoA and v6HoA. Then, the CN MUST send a BAck. The 392 CN MUST also include the IPv4 RO mode option in the BAck. Not 393 receiving this option in the BAck means that the CN does not support 394 IPv4 RO. 396 7.1.3. Packet processing 398 With IPv6 based routing, two options are possible: 400 1. Normal MIPv6 RO with encapsulated IPv4 packets 401 In this case, the MN and the CN process the packet as in the 402 MIPv6 RO using HoA option and Type 2 Routing Header in the IPv6 403 external header. The IPv6 header encapsulates an IPv4 packet. 404 When leaving the MN, the addresses are: 406 External header: 407 Src = v6CoA 408 Dest = v6CN 409 HoA option = v6HoA 410 Internal header: 411 Src = v4HoA 412 Dest = v4CN 414 After receiving this packet, the CN performs regular MIPv6 RO 415 process before decapsulating and processing the IPv4 packet. For 416 security reasons, when detecting that there is an IPv4 packet 417 encapsulated in a IPv6 packet that passes the RO process, the MN 418 MUST check if the IPv4 source and destination addresses 419 correspond respectively to the v4HoA and v4CN addresses 420 registered in the related BCE. If not, the packet MUST be 421 discarded. When leaving the CN, the addresses are: 423 External header: 424 Src = v6CN 425 Dest = v6CoA 426 Type 2 Routing Header = v6HoA 427 Internal header: 428 Src = v4CN 429 Dest = v4HoA 431 When receiving this packet, the MN performs regular MIPv6 RO 432 process before decapsulating and processing the IPv4 packet. For 433 security reasons, when detecting that there is an IPv4 packet 434 encapsulated in a IPv6 packet that passes the RO process, the MN 435 MUST check if the IPv4 source and destination addresses 436 correspond respectively to the v4CN and v4HoA addresses 437 registered in the related BCE. If not, the packet MUST be 438 discarded. 440 2. Normal MIPv6 RO with IPv4 mapped IPv6 addresses 441 This solution assumes that MN and CN understand IPv4 mapped 442 addresses. An IPv4 mapped address, labeled v4HoA-map address, is 443 formed with the v4HoA. When sending a packet, the MN configures 444 the addresses as below: 446 IPv6 header: 447 Src = v6CoA 448 Dest = v6CN 449 HoA option = v4HoA-map 451 After receiving this packet, the CN performs regular MIPv6 RO 452 process. Then, the CN detects the v4HoA-map and forwards the 453 packet to the next layer considering v4HoA as source address. 454 When leaving the CN, the addresses are: 456 IPv6 header: 457 Src = v6CN 458 Dest = v6CoA 459 Type 2 Routing Header = v4HoA-map 461 After performing regular MIPv6 RO process, the MN forwards the 462 packet to the next layer considering IPv4 addresses. 464 7.2. Mobile Node with IPv4 CareOf address only 466 7.2.1. Return Routability procedure 468 In this case, it is impossible to use directly the MIPv6 RO process 469 as there is no v6CoA. 471 7.2.1.1. Home address reachability test 473 If a v4HoA is configured, the MN SHOULD perform Home address 474 reachability test in the RRP the same way as described in 475 Section 7.1.1.1. Otherwise, process described in [RFC3775] is 476 applied. 478 7.2.1.2. CareOf address reachability test 480 For the v4CoA reachability test, the MN sends a CoTI message 481 described below: 483 External header: 484 Src = v4CoA 485 Dest = v4CN 486 UDP header 487 Internal header: 488 Src = v6HoA 489 Dest = v6CN 490 CoTI message 491 IPv4 CoA Option = v4CoA 492 IPv4 RO mode option = 3 or 4 494 The CoTI message MUST include an IPv4 CoA option and be UDP 495 encapsulated as described in [I-D.ietf-mext-nemo-v4traversal]. An 496 IPv4 RO mode option MUST be present with a value equal to 3 (IPv4 497 encapsulation) or 4 (IPv4-UDP encapsulation). After receiving the 498 CoTI message, due to the presence of an IPv4 CoA option, the CN 499 understand that this is a v4CoA reachability test. The CN calculates 500 the CoA Keygen Token as described in Section 6.4.2. Then, the CN 501 generates a CoT message and send it encapsulated to the MN. The 502 format of the CoT message is described below: 504 External header: 505 Src = v4CN 506 Dest = v4CoA 507 UDP header (optional) 508 Internal header: 509 Src = v6CN 510 Dest = v6HoA 511 CoT message 512 IPv4 CoA Option = v4CoA 513 IPv4 RO mode option = 0 or 3 or 4 515 For security reason, the Hop limit of the IPv6 header MUST be set to 516 1. Therefore, v4CoA and v6HoA MUST belong to the MN. After 517 receiving the tokens, the MN is able to generate the Kbm. 519 7.2.2. Binding registration 521 The procedure here is the same as the one described in Section 7.1.2 522 except that the BU and BA messages MUST be encapsulated using the 523 chosen RO mode. 525 7.2.3. Packet processing 527 In this scenario, we can not use HoA option or Type 2 Routing header 528 as they are not defined for IPv4. Also, source routing is not a good 529 approach as many firewalls will block packets with source routing 530 option. Moreover, defining new options for IPv4 is not recommended 531 as IPv4 is already widespread. The approach chosen here is to use an 532 IP-in-IP encapsulation. When leaving the MN, the addresses are: 534 External header: 535 Src = v4CoA 536 Dest = v4CN 537 Internal header: 538 Src = v4HoA 539 Dest = v4CN 541 For security reasons, the CN MUST check if the sources of the outer 542 and inner header match in a BCE. If not, the packet MUST be 543 discarded. When leaving the CN, the addresses are: 545 External header: 546 Src = v4CN 547 Dest = v4CoA 548 Internal header: 549 Src = v4CN 550 Dest = v4HoA 552 For security reasons, the MN MUST check if the destination of the 553 outer and inner header match in a BULE. If not, the packet MUST be 554 discarded. 556 7.2.4. NAT keepalives 558 When a CN detects NAT(s) in the path, it MUST include a NAT detection 559 option in the CoTI message and the NAT keepalives are performed using 560 the BU and BA messages as described in 561 [I-D.ietf-mext-nemo-v4traversal]. 563 8. Security Considerations 565 There are no new messages added here and all messages exchanges are 566 secured using the same mechanisms described in 567 [I-D.ietf-mext-nemo-v4traversal] and [RFC3775]. This specification 568 requires to perform IPv4 HoA and CoA reachability tests. For this 569 purpose, the v4HoA and v4CoA are included in the token generation 570 process. 572 9. IANA Considerations 574 This specification requires a type for the IPv4 RO mode option 575 included in the mobility header. 577 10. Normative References 579 [I-D.ietf-mext-nemo-v4traversal] 580 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 581 Routers", draft-ietf-mext-nemo-v4traversal-09 (work in 582 progress), February 2009. 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, March 1997. 587 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 588 in IPv6", RFC 3775, June 2004. 590 [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization 591 Using a Static Shared Key", RFC 4449, June 2006. 593 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 594 Optimization for Mobile IPv6", RFC 4866, May 2007. 596 Authors' Addresses 598 Desire Oulai 599 Ericsson 600 8400 Blvd Decarie 601 Town of Mount Royal, Quebec 602 Canada 604 Email: desire.oulai@ericsson.com 606 Suresh Krishnan 607 Ericsson 608 8400 Blvd Decarie 609 Town of Mount Royal, Quebec 610 Canada 612 Email: Suresh.Krishnan@ericsson.com 614 Hesham Soliman 615 Elevate Technologies 617 Email: hesham@elevatemobile.com