idnits 2.17.00 (12 Aug 2021) /tmp/idnits59397/draft-bajko-mip6-rrtfw-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 611. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 34 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (July 9, 2007) is 5430 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '6' on line 234 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-tschofenig-mip6-ice-00 == Outdated reference: A later version (-01) exists of draft-krishnan-mip6-firewall-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Bajko 3 Internet-Draft Nokia 4 Intended status: Standards Track H. Tschofenig 5 Expires: January 10, 2008 Nokia Siemens Networks 6 July 9, 2007 8 Firewall friendly Return-Routability Test (RTT) for Mobile IPv6 9 draft-bajko-mip6-rrtfw-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines a slightly modified Return Routability Test 43 (RRT) for MIPv6. The herein defined RRT mechanism is intended for 44 CoA exchanges between the MN and the CN. Once the MN and CN find out 45 their peers' valid addresses, an additional mechanism will be used to 46 run connectivity checks to figure out which of the address pairs have 47 connectivity and, if needed, open the required pinholes in the 48 firewalls. The defined mechanism is intended to work with current 49 firewalls without requiring any support from them. The document also 50 addresses the use of UDP encapsulation to facilitate MIPv6 signaling 51 between involved nodes. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. New Return Routability Procedure . . . . . . . . . . . . . . . 4 58 4. UDP Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Problem Description . . . . . . . . . . . . . . . . . . . 5 60 4.2. UDP Encapsulation Procedures . . . . . . . . . . . . . . . 5 61 4.2.1. Procedures at the MN . . . . . . . . . . . . . . . . . 5 62 4.2.2. Procedures at the HA . . . . . . . . . . . . . . . . . 6 63 4.2.3. UDP encapsulated HoTI/HoT RRT messages . . . . . . . . 7 64 5. Enabling Route Optimization Through Firewalls . . . . . . . . 7 65 5.1. Problem Description . . . . . . . . . . . . . . . . . . . 7 66 5.2. New RTT Proposal . . . . . . . . . . . . . . . . . . . . . 9 67 5.3. Modified RRT Procedures . . . . . . . . . . . . . . . . . 10 68 5.3.1. Modified RRT Procedures at the MN . . . . . . . . . . 10 69 5.3.2. Modified RRT procedures at the CN . . . . . . . . . . 10 70 5.3.3. HA processing of CoTI-ICE and CoT-ICE . . . . . . . . 10 71 6. New Mobility Header Types . . . . . . . . . . . . . . . . . . 11 72 6.1. CoTI-ICE Message . . . . . . . . . . . . . . . . . . . . . 11 73 6.2. CoT-ICE Message . . . . . . . . . . . . . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 81 Intellectual Property and Copyright Statements . . . . . . . . . . 14 83 1. Introduction 85 Most of today's IP networks are protected by state full firewalls 86 which filter the traffic based on the five tuple (sourceIP, destIP, 87 sourcePort, destPort). This filtering could be supplied to incoming 88 traffic or both incoming and outcoming. The problems which occure 89 when using MIPv6 in firewall protected networks are described in 90 detail in [RFC4487]. 92 Most of the MIPv6 signalling is, as defined in [RFC3775], is secured 93 by IPSec ESP, and most of today's firewalls will drop ESP packets, as 94 there are no default rules defined for this traffic. So the mobile 95 node is not able to successfully complete the registration of it's 96 CoA in the new network and will not be able to communicate with other 97 nodes. 99 If the the Binding Update (BU) with the home agent (HA) is finished, 100 and the mobile node wants to use route optimization, it will start 101 the Return Routability Procedure (RRT). For this it will send a HoTI 102 and a CoTI message to the corresponend node (CN). The HoTI will be 103 send over the HA to the CN and the CoTI message directly to the CN. 104 Normally the HoTI and the corresponet HoT message will go through, 105 but the CoTI or CoT message will mostly be dropped. So no route 106 optimization is available and all the traffic need to go over the HA. 108 This document will provide a solution that the MIPv6 signalling will 109 successfully complete. First a new return routability procedure will 110 be shown and then a was to encapsulate messages in UDP to traverse 111 the firewalls. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 This document uses the following abbreviations: 121 o CN: Correspondent Node 122 o CoA: Care of Address 123 o CoT: Care-of Test 124 o CoT-ICE: Care-of Test ICE 125 o CoTI: Care-of Test Init 126 o CoTI-ICE: Care-of Test Init ICE 127 o HA: Home Agent 128 o HoA: Home Address 129 o HoT Home Test 130 o HoTI: Home Test Init 131 o ICE: Interactive Connectivity Establishment 132 o MN: Mobile Node 133 o RO: Route Optimization 134 o RRT: Return Routability Test 136 3. New Return Routability Procedure 138 Current firewalls typically create state and filter data traffic 139 based on the five tuple (sourceIP, destIP, Prot, sourcePort, 140 destPort). Filtering may be applied either to only incoming traffic 141 or both incoming and outgoing traffic. 143 MIP6 [RFC3775] faces a number of problems when used in an environment 144 with firewalls: 146 o (a) Mobile IP recommends the use of IPsec ESP to protect packets 147 between the MN and its home agent, while today's firewalls, as a 148 default rule, drop ESP packets, thus preventing the use of MIP6. 149 It is possible to configure static pinholes in the firewalls to 150 allow ESP and IKE messages between MN and HA to pass 151 through.[I-D.krishnan-mip6-firewall] describes best current 152 practices on how to configure firewalls to enable MIPv6. 153 Alternatively, UDP encapsulation might be used. 154 o (b) current firewalls filter on udp and tcp protocol, thus when a 155 firewall is protecting the CN, that firewall might not allow a 156 HoTI to pass, as that is sent using MH protocol [RFC3775]. If the 157 policy in the firewall would allow wildcard for the protocol 158 instead of filtering on udp or tcp, this problem would be solved 159 as well. Note: here it is assumed that when a HoTI is generated 160 by the MN (i.e. start of route optimisation), then there is 161 already a data connection between the MN and the CN through the 162 HA. 163 o (c) similar to the above, when a firewall protecting the MN sees a 164 CoTI message, it would need to install state to allow the 165 corresponding CoT to pass and reach the MN. Firewalls that do not 166 support MH and modifying the firewall policy is not acceptable for 167 the administrator, UDP encapsulation might need to be used. This 168 is addressed in section 5. 169 o (d) a firewall protecting the CN will not allow a CoTI to pass, as 170 that is sent from an untrusted address. 171 o (e) when both the HA and the MN and/or CN are behind firewalls, 172 then a combination of UDP encapsulation and the modified RRT 173 mechanism defined in this document might need to be used to enable 174 MIPv6 operation. 176 As a summary, while some of the mobile IPv6 signaling could be 177 enabled using static configurations in the firewalls, there is no way 178 to ensure the same for the signaling and data traffic on the direct 179 path between the MN and the CN. 181 Without applying route optimization, the MN and the CN would be 182 forced to communicate through their home agents, and that, based on 183 their topological location, could result in increased latency and 184 cost. Such additional delays might not be tolerated by interactive 185 applications sensitive to delays. 187 In order to ensure a successful deployment of IPv6 and mobile IPv6 in 188 current IP networks, it is important to have mechanisms and 189 guidelines in place which help the smooth operation of the protocol 190 in an environment with firewalls. 192 4. UDP Encapsulation 194 This section addresses scenarios a), b) and c) from Section 1. 196 4.1. Problem Description 198 When the MN or the HA or both are behind firewalls that block IPsec 199 ESP, then the Binding Update to the Home Agent will fail. To 200 overcome this situation, firewall administrators may configure static 201 pinholes in the firewalls, as described in 202 [I-D.krishnan-mip6-firewall]. When that is not feasible, as an 203 alternative, the MN may use UDP encapsulation to wrap its MIPv6 204 messages destined to the HA into a UDP/IP header. As the MN can not 205 influence or change the firewall behavior, it has to determine 206 whether there are any firewalls blocking ESP between itself and the 207 HA or not. When there are, it will need to use UDP encapsulation. 209 Additionally, when the MN or the CN or both are behind firewalls that 210 do not allow packets with MH protocol to pass, the MN, or the CN or 211 both may need to use UDP encapsulation to wrap their MIPv6 messages 212 into a duplicate UDP/IP header. Same applies when the firewall 213 allows MH packets to pass in the in-->out direction but does not 214 install state to allow the corresponding response in the out-->in 215 direction. 217 4.2. UDP Encapsulation Procedures 219 4.2.1. Procedures at the MN 221 When the MN detects that there is a firewall between itself and the 222 HA, it SHOULD start using UDP encapsulation to wrap its MIPv6 223 signaling messages destined to the HA into new UDP/IP header. When 224 using UDP encapsulation, the MN MUST use UDP port 500. 226 [Editor's Note: If there is a NAT between the mobile node and the 227 home agent then IKEv2 will enable UDP encapsulation for subsequent 228 traffic. For firewalls this UDP encapsulation can either be provided 229 by IKEv2 or as part of the mobile IP stack. For the usage with RFC 230 4285 mobile IP has to enable this UDP encapsulation procedure since 231 IKEv2 is not used in this case.] 233 The MN can detect that there is a firewall on the path by either 234 using an external mechanism like STUN [6] or by simply assuming that 235 if the Binding Update to its HA fails, then that is probably the 236 case. 238 When the MN receives a packet on UDP port 500 from its HA, it MUST 239 inspect the first 8 bytes of the UDP payload. If those are set to 240 zero then the MN received a UDP encapsulated MH packet and it MUST 241 remove the UDP/IP header and process the inner packet as a MH packet. 243 4.2.2. Procedures at the HA 245 When the HA receives a packet on UDP port 500, it MUST inspect the 246 first 8 bytes of the UDP payload. If those are set to zero then the 247 HA received a UDP encapsulated MH packet and it MUST remove the 248 UDP/IP header and process the inner packet as a MH packet. 250 The HA MUST also use UDP encapsulation with port 500 when sending a 251 response to a UDP encapsulated MH packet to the MN. 253 When the HA receives a UDP encapsulated packet containing a HoTI or a 254 HoT or a CoTI-ICE (defined in this document) or a CoT-ICE (defined in 255 this document) MH packet, it MUST decapsulate and re-encapsulate it 256 using UDP port 500 before sending it to the MN or CN, respectively: 258 Mobile Node Home Agent Correspondent Node 259 | | | 260 | HoTI:=IPv6(MN_COA, HA_ADDR) | HoTI:=IPv6(HA_ADDR, CN_ADDR) | 261 | UDP header | UDP header | 262 | IPv6 header | IPv6 header | 263 | Mobility header | Mobility header | 264 | type: HoTI (1) | type: HoTI (1) | 265 | | | 266 |---------------------------->|----------------------------->| 267 | | | 268 | HoT:=IPv6(HA_ADDR, MN_CoA) | HoT:=IPv6(CN_ADDR, HA_ADDR) | 269 | UDP header | UDP header | 270 | IPv6 header | IPv6 header | 271 | Mobility header | Mobility header | 272 | type: HoT (3) | type: HoT (3) | 273 | | | 274 |<----------------------------|<-----------------------------| 275 | | | 277 4.2.3. UDP encapsulated HoTI/HoT RRT messages 279 The CoTI-ICE/CoT-ICE messages are treated similarly, only the MH type 280 will have a different value (22 and 23 respectively) 282 4.2.3.1. Procedures at the CN 284 When the CN receives a packet on UDP port 500, it MUST inspect the 285 first 8 bytes of the UDP payload. If those are set to zero then the 286 CN received a UDP encapsulated MH packet and it MUST remove the 287 UDP/IP header and process the inner packet as a MH packet. 289 When the CN receives a UDP encapsulated MH message, it MUST send the 290 response using UDP encapsulation. 292 5. Enabling Route Optimization Through Firewalls 294 Route optimization can be enabled by either using dedicated signaling 295 to instruct the firewall to create a pinhole, or using a mechanism 296 which would make the firewall to install pinholes as part of its 297 normal operation. This draft addresses the latter solution. 299 5.1. Problem Description 301 This section describes in more details scenario d) from Section 1. 303 The Return Routability Test defined in [RFC4487] enables the 304 correspondent node to obtain some reasonable assurance that the 305 mobile node is in fact addressable at its claimed care-of address as 306 well as at its home address, while keygen tokens are exchanged and 307 combined into a binding management key. In order to enable route 308 optimizations through firewalls, both HoTI and CoTI messages (and the 309 corresponding HoT and CoT) need to successfully pass through. It is 310 assumed that at the time when the MN initiates a route optimization 311 procedure towards the CN, there is already some sort of data 312 communication between the MN and the CN. If the CN is behind 313 firewall and that firewall does have a rule to allow packets from the 314 HoA of the MN to the address of the CN, then there is a good chance 315 that HoTI would also make it through the firewall. 317 If such a rule does not exist in the firewall protecting the CN, then 318 HoTI will be dropped and the return routability test will fail. 320 Once HoTI is sent out and a HoT response is received, the MN will 321 send a CoTI message from its current CoA. If there is a firewall 322 protecting the CN, that firewall will drop the CoTI message as it is 323 coming from an untrusted source. 325 In order to illustrate the problem, let's assume a communication 326 between an inner node A (protected by the firewall), and an external 327 mobile node B. It is assumed that the firewall protecting the CN 328 (node A) is configured in such a way that it allows traffic from the 329 node B's HoA to bypass, therefore MH packets like HoTI are not 330 filtered. 332 As specified in Mobile IP [RFC3775], the transport and higher layers 333 should use the Home IP address and HoA of node B, and not the local 334 IP address that node B might get while roaming in order to support 335 mobility. The state created in the firewall protecting node A is 336 therefore initially based on the IP address of node A, and the home 337 address of the node B, HoA of node B. If the mobile node B is in its 338 home network, the packets are directly exchanged between the nodes A 339 and B. If the mobile node B is roaming, the session can be maintained 340 thanks to the Home Agent of node B and the reverse tunneling 341 mechanism [RFC3775]. Packets forwarded by the Home Agent to node A 342 will have the source IP address indicating the Home IP address of 343 node B and the destination IP address indicating the IP address of 344 node A. Such packets can thus pass the packet filter inspection in 345 the firewall protecting node A. However, nodes A and B might be 346 located topologically closely together while node B's Home Agent may 347 be far away, resulting in a 'trombone effect' that can create delay 348 and degrade the performance. The Mobile IP specifications have 349 defined the route optimization procedure [RFC3775] in order to solve 350 this issue. The mobile node should first execute a Return 351 Routability Test: the Mobile Node B should send a Home Test Init 352 message (HoTI) via its Home Agent and a Care of Test Init (CoTI) 353 message directly to its correspondent node A as illustrated in the 354 figure below [RFC4487]: 356 +----------------+ 357 | +----+ HoTI (HoA) +----+ 358 | | FW |<----------------|HA B| 359 | +----X +----+ 360 | +---+ | ^ CoTI - dropped ^ 361 | | A | | | by the FW | 362 | +---+ | | | HoTI 363 | | | | 364 | | | CoTI (CoA)+---+ 365 | | +------------------| B | 366 +----------------+ +---+ 367 Network protected External Mobile 368 by a firewall Node 370 The Care of Test Init message is sent from the new CoA. However, 371 this packet will not match any entry in the packet filter in the 372 firewall and the CoTI message will be dropped. As a consequence, the 373 RRT cannot be completed and Route optimization cannot be applied due 374 to the presence of a firewall. 376 The above scenario is one from the problem statements described in 377 [RFC4487]. 379 5.2. New RTT Proposal 381 This document proposes a modified RRT for MIPv6 nodes behind 382 firewalls. In the new RRT mechanism the original HoTI and HoT remain 383 unchanged, while the new CoTI (called CoTI-ICE) and CoT (called CoT- 384 ICE) messages will be routed through the HA in a similar way as HoTI 385 and HoT. While the token exchange for binding management key 386 generation purposes from the original RRT is preserved, the new RRT 387 mechanism will be used to exchange the valid addresses the MN and CN 388 possess. Once the addresses - called candidate addresses - are 389 exchanged, both the MN and CN will run connectivity checks as 390 described in [I-D.tschofenig-mip6-ice] in order to enable and to 391 check the connectivity for the addresses. When a working address 392 pair is found, the MN will send a BU from that CoA to the CN's 393 address. 395 Mobile node Home agent Correspondent node 396 | | 397 | HoTI | | 398 |------------------------->|------------------------->| 399 | | | 400 | CoTI-ICE | | 401 |------------------------->|------------------------->| 402 | | | 403 | | HoT | 404 |<-------------------------|<-------------------------| 405 | | | 406 | | CoT-ICE | 407 |<-------------------------|<-------------------------| 408 | | | 410 The new RRT mechanism will not test the connectivity on the direct 411 path between the MN and CN. As that is still needed before the nodes 412 engage in data exchange, a new mechanism, described in 413 [I-D.tschofenig-mip6-ice] is used for this purpose. 415 5.3. Modified RRT Procedures 417 5.3.1. Modified RRT Procedures at the MN 419 The MN following the new RRT procedure defined in this draft MUST NOT 420 send a CoTI, as defined in [RFC3775], to the CN. Instead it MUST 421 generate a CoTI-ICE, as defined in this document. The MN MUST gather 422 its addresses from all its interfaces as described in 423 [I-D.tschofenig-mip6-ice]. The MN MUST form candidate-addresses as 424 described in [I-D.tschofenig-mip6-ice]. The MN MUST put all of its 425 candidate-addresses into a MIP-ICE mobility options defined in 426 [I-D.tschofenig-mip6-ice] and MUST attach it to the CoTI-ICE message. 428 5.3.2. Modified RRT procedures at the CN 430 The CN supporting the new RRT procedure defined in this document, 431 upon receiving a CoTI-ICE message MUST NOT send a CoT response, as 432 defined in [RFC3775]. The CN upon receipt of a CoTI-ICE message MUST 433 gather its addresses from all its interfaces as described in 434 [I-D.tschofenig-mip6-ice]. The CN MUST form candidate-addresses as 435 described in [I-D.tschofenig-mip6-ice]. The CN MUST put all of its 436 candidate-addresses into a MIP-ICE mobility options defined in 437 [I-D.tschofenig-mip6-ice] and MUST attach it to the CoT-ICE message. 439 5.3.3. HA processing of CoTI-ICE and CoT-ICE 441 Both CoTI-ICE and CoT-ICE messages MUST be processed by the HA as any 442 other Mobility Header message, as described in [RFC3775]. 444 6. New Mobility Header Types 446 6.1. CoTI-ICE Message 448 A mobile node uses the CoTI-ICE message to finalize the return 449 routability procedure and request a care-of keygen token from a 450 correspondent. The CoTI-ICE message uses the MH Type value 22 (to be 451 registered with IANA). A CoTI-FW message MUST include a mobility 452 options carrying the candidate addresses of the MN sending it. 454 When value 22 is indicated in the MH Type field, the format of the 455 Message Data field in the Mobility Header is as follows: 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Reserved | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | 463 + Care of Init Cookie + 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | | 467 . MIP-ICE Mobility Options . 468 . . 469 . . 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Care of Init Cookie: as defined in RFC 3775 474 MIP-ICE Mobility Options: as defined in [I-D.tschofenig-mip6-ice] 476 6.2. CoT-ICE Message 478 The Care-of Test ICE (CoT-ICE) message is a response to the Care-of 479 Test Init ICE (CoTI-ICE) message, and is sent from the correspondent 480 node to the mobile node. The Care-of Test ICE message uses the MH 481 Type value 23 (to be registered with IANA). When this value is 482 indicated in the MH Type field, the format of the Message Data field 483 in the Mobility Header is as follows: 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Care-of Nonce Index | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 + Care of Init Cookie + 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | | 495 + Care-of Keygen Token + 496 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 . MIP-ICE Mobility Options . 501 . . 502 . . 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Care of Init Cookie: as defined in RFC 3775 507 Care-of Keygen Token: as defined in RFC 3775 508 MIP-ICE Mobility Options: as defined in [I-D.tschofenig-mip6-ice] 510 7. IANA Considerations 512 This specification registers new MH type values: 514 CoTI-ICE message uses MH type value 22. 516 CoT-ICE message uses MH type value 23. 518 8. Security Considerations 520 The security threats described in [I-D.tschofenig-mip6-ice] are 521 inherited in addition to the existing ones mentioned in [RFC3775]. 523 [Editor's Note: More work is needed on the security consideration 524 section particularly since the security properties of the return 525 routability check might be changed.] 527 9. Acknowledgments 529 We would like to thank Thomas Schreck for his contributions to this 530 document. 532 10. References 534 10.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", March 1997. 539 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 540 in IPv6", RFC 3775, June 2004. 542 [I-D.tschofenig-mip6-ice] 543 Tschofenig, H. and G. Bajko, "Mobile IP Interactive 544 Connectivity Establishment (M-ICE)", 545 draft-tschofenig-mip6-ice-00 (work in progress), 546 June 2007. 548 10.2. Informative References 550 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 551 IPv6 and Firewalls: Problem Statement", RFC 4487, 552 May 2006. 554 [I-D.krishnan-mip6-firewall] 555 Krishnan, S., "Firewall Recommendations for MIPv6", 556 draft-krishnan-mip6-firewall-00 (work in progress), 557 July 2007. 559 Authors' Addresses 561 Gabor Bajko 562 Nokia 564 Hannes Tschofenig 565 Nokia Siemens Networks 566 Otto-Hahn-Ring 6 567 Munich, Bavaria 81739 568 Germany 570 Email: Hannes.Tschofenig@nsn.com 571 URI: http://www.tschofenig.com 573 Full Copyright Statement 575 Copyright (C) The IETF Trust (2007). 577 This document is subject to the rights, licenses and restrictions 578 contained in BCP 78, and except as set forth therein, the authors 579 retain all their rights. 581 This document and the information contained herein are provided on an 582 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 583 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 584 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 585 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 586 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 589 Intellectual Property 591 The IETF takes no position regarding the validity or scope of any 592 Intellectual Property Rights or other rights that might be claimed to 593 pertain to the implementation or use of the technology described in 594 this document or the extent to which any license under such rights 595 might or might not be available; nor does it represent that it has 596 made any independent effort to identify any such rights. Information 597 on the procedures with respect to rights in RFC documents can be 598 found in BCP 78 and BCP 79. 600 Copies of IPR disclosures made to the IETF Secretariat and any 601 assurances of licenses to be made available, or the result of an 602 attempt made to obtain a general license or permission for the use of 603 such proprietary rights by implementers or users of this 604 specification can be obtained from the IETF on-line IPR repository at 605 http://www.ietf.org/ipr. 607 The IETF invites any interested party to bring to its attention any 608 copyrights, patents or patent applications, or other proprietary 609 rights that may cover technology that may be required to implement 610 this standard. Please address the information to the IETF at 611 ietf-ipr@ietf.org. 613 Acknowledgment 615 Funding for the RFC Editor function is provided by the IETF 616 Administrative Support Activity (IASA).