idnits 2.17.1 draft-nordmark-mobileip-mipv6-hindsight-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 38 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (Nov 14, 2001) is 8198 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: 'SCOPED-ARCH' is mentioned on line 402, but not defined == Unused Reference: 'ICMPv6' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'INGRESS' is defined on line 593, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-savola-ipv6-rh-ha-security-00 -- Possible downref: Normative reference to a draft: ref. 'RH-HA' -- Unexpected draft version: The latest known version of draft-kre-ipv6-payload is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'PAYLOAD' == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-01 -- Possible downref: Normative reference to a draft: ref. 'ICMPv6' ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC-SA') (Obsoleted by RFC 4301) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark, Sun Microsystems 3 Nov 14, 2001 5 MIPv6: from hindsight to foresight? 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet Draft expires May 14, 2002. 32 Abstract 34 This document captures the authors personal opinions and is intended 35 to serve as input to the discussion in the Mobile IP Working Group. 36 It proposes several, in may cases completely independent, things 37 which might be deemed radical changes to Mobile IPv6 based on 38 watching Mobile IPv6 evolve over the last 5 years. 40 Contents 42 1. INTRODUCTION............................................. 2 43 1.1. Goals and Requirements.............................. 3 44 1.2. Proposed Changes.................................... 4 46 2. GENERIC END-TO-END PIGGYBACKING.......................... 5 47 2.1. Piggybacking Packet Format.......................... 5 48 2.2. Sending Payload Headers............................. 6 49 2.3. Processing Received Payload Headers................. 6 51 3. NO MORE DESTINATION OPTIONS IN MOBILE IPv6............... 7 53 4. USE REGULAR TUNNELING BETWEEN MOBILE NODES............... 7 55 5. IP TUNNELING WITH REDUNDANT SOURCE OR DESTINATION ADDRESSES 7 56 5.1. Three Address Tunneling Packet Format............... 7 57 5.2. Sending Rules....................................... 8 58 5.3. Receiving Rules..................................... 9 59 5.4. When to Accept Tunneled Packets..................... 9 61 6. EXPLICIT MOVEMENT DETECTION.............................. 11 62 6.1. Location Indication Option Format................... 11 64 7. SECURITY CONSIDERATIONS.................................. 12 66 8. ACKNOWLEDGEMENTS......................................... 13 68 REFERENCES................................................... 13 70 AUTHORS' ADDRESSES........................................... 14 72 1. INTRODUCTION 74 The Mobile IPv6 specification has evolved incrementally over at least 75 5 years. During that time several things have changed that could be 76 used to provide additional benefits for mobile IPv6. 78 An example is IP tunneling which was first specified for Mobile IPv4. 79 Since then the understanding of IP tunneling has increased 80 significantly over the years due to being used for both IPsec and 81 IPv6 transition. This has lead to a greater understanding of e.g., 82 the security issues in decapsulating packets. 84 This document proposes a set of largely independent changes to Mobile 85 IPv6 that are on the author's "wish list". Many of the changes can 86 be viewed as just using a different packet format to encode the same 87 information thus the impact on implementations might not be that 88 large as one would otherwise think. But it is the author's opinion 89 that these changes make the protocol fit better with other IP 90 protocol hence easier to understand. The hope is that this will 91 reduce the probability of implementation problems relating to 92 robustness, security, etc. 94 If the working group thinks these simplifications are worth-while it 95 would make sense to apply them before Mobile IPv6 becomes a proposed 96 standard. Delaying this type of "cleanup" until after there is a 97 mobile IPv6 standard is not likely to be beneficial since then one 98 would have to be concerned with compatibility between the old and the 99 new scheme, carry around the code for the old scheme, etc. Thus it 100 makes sense for the WG to look carefully at these suggestions and 101 make a conscious decision whether to reject them or accept them, and 102 not try to postpone this discussion until later. 104 These ideas are not mine alone - most of them have been suggested by 105 others on the Mobile IPv6 or IPNG mailing lists over the years but 106 have not resulted in much of discussion. 108 With one notable exception the suggested changes do not change the 109 set of features available in Mobile IPv6. The exception is the 110 suggestion to remove the "update of previous default router" which, 111 in the author's opinion, is a pre-mature optimization. Given the 112 "securing binding updates in the absence of a global PKI" discussion 113 that the working group is having it less clear than ever whether the 114 use of the previous default router as a temporary Home Agent for the 115 previous Care of Address will reduce the packet loss due to handoffs 116 - securely updating the previous default router is likely to take at 117 least one round-trip time and which point the number of packets in 118 transit between the CNs and MN's old CoA is likely to be very small. 119 In any case, there are separate efforts to make handoffs smoother. 121 1.1. Goals and Requirements 123 The goals for the proposed changes are: 125 o Simplify things to the extend possible without loosing 126 functionality. 128 o Use existing protocol mechanisms such as tunneling. In general 129 make Mobile IPv6 less different than other existing protocol 130 mechanisms. 132 o Allow IPsec to be used to authenticate control traffic in the 133 cases when a trust relationship exists e.g. between the MN and its 134 HA. 136 o Address the concerns about the use of routing headers and home 137 address options expressed in [RH-HA]. 139 1.2. Proposed Changes 141 Replace the binding update specific piggybacking in [MIPv6] with 142 generic end-to-end piggybacking i.e. the ability to send two IP 143 packet payloads in a single IP packet. 145 Make the Mobile IPv6 control packets (Binding Request, Update, 146 Acknowledgement, etc) use either a UDP port, new ICMP types, or a new 147 payload type. 149 Replace the use of the Routing Header in Mobile IPv6 with IPinIP 150 tunneling. Specify a new tunneling header which omits the source 151 address since, in this case, the conceptual outer source address and 152 inner source address are identical. The resulting header adds 24 153 bytes to the packet which is the same as a the size of the routing 154 header and it allows sites and hosts to have separate security policy 155 for processing these headers than processing routing headers as [RH- 156 HA] suggests they need. 158 Replace the use of the Home Address option conceptually with 159 tunneling. Avoid an increase in packet size by specifying a new 160 tunneling header which omits the destination address, since in this 161 case the inner and outer destination addresses would be identical. 163 For mobile to mobile communication, where both a routing header and a 164 home address option is used today this conceptual use of tunneling 165 just becomes regular IPinIP tunneling since in that case all four 166 IPv6 need to be carried; two care of addresses and two home addresses 167 in each packet. 169 There is also one idea that could be added to Mobile IPv6 at a later 170 stage, which is to make the movement detection more explicit. The 171 idea is to configure the routers on each link to advertise a single 172 global IPv6 address as the "identity" of the link in each Router 173 Advertisement. This can be done by defining a new Neighbor Discovery 174 option. Thus a Mobile Node when it receives a Router Advertisement 175 can immediately tell whether it has moved - the global identity will 176 be different for each link. 178 2. GENERIC END-TO-END PIGGYBACKING 180 This is based on the work in [PAYLOAD]. 182 The idea is to define a new extension header that is capable of 183 carrying multiple IP packet payloads between a pair of IP addresses, 184 that is defined such that IPsec can be used independently on the 185 different payloads. Thus it would be possible to have a mobile IPv6 186 control packet protected by ESP and a TCP SYN packet without any 187 IPsec protection in the same IP packet. 189 2.1. Piggybacking Packet Format 191 Extracted from [PAYLOAD]. 193 0 7 8 15 16 31 194 ----------------------------------------------------------------- 195 | | | | 196 | Nxt Hdr | Int Nxt Hdr | Length | 197 | | | | 198 ----------------------------------------------------------------- 199 | | 200 | Data (Length octets) ... | 201 | | 202 | /------------------------------------| 203 | / Trailing Padding | 204 -------------------------/--------------------------------------- 206 IP Fields: 208 Nxt Hdr 209 The payload type for the header that follows the 210 trailing padding. 212 Int Nxt Hdr 213 The payload type for the Data field. 215 Length 216 The length of the Data field in octets. 218 Data 219 Some payload of type "Int Nxt Hdr". 221 Trailing Padding 222 If the length of the whole extension header is not 223 a multiple of 8 octets this field will be present 224 so that the total length of the extension header 225 becomes a multiple of 8 octets. 227 Note that [PAYLOAD] defines the above format as the `General Payload 228 Header'' (GPH) and also defines the ``Aligned Payload Header'' with 229 32 bits of reserved field between the length field and the data 230 field. The reason for this is to provide different alignment with 231 respect to the beginning of the Data field. 233 2.2. Sending Payload Headers 235 When a sender sees a benefit of using piggybacking it can include 236 multiple payloads in the packet independent whether the payloads use 237 IPsec or not. 239 However, some firewalls might drop any packet containing the payload 240 header and other firewalls will drop such a packet if any of the 241 contained payloads violate the security policy. Hence this form of 242 piggybacking SHOULD NOT be used when retransmitting packets since 243 that could result in repeated retransmissions all being dropped by a 244 firewall when individual packets would make it through. 246 The payload header, when sent, SHOULD be placed after any 247 fragmentation header but before any IPsec headers. 249 2.3. Processing Received Payload Headers 251 Conceptually the processing of a payload header can be described as 252 using the payload header to create two separate IP packets and 253 processing those packets independently. 255 This can be described as forming two IPv6 headers (and other headers 256 like HopByHop options that precede the payload header) and appending 257 the payload from the Data field in the payload header to one of the 258 headers and the appending rest of the packet to the other header. 259 Finally adjusting the IPv6 payload length for the two headers. 261 Note that in general there can be more than one payload header per 262 packet in which case this simple way of describing the processing 263 needs to be recursive. 265 Once the two packets have been generated they are processed as they 266 had just been received from the link-layer i.e., any IPsec processing 267 takes place on the individual packets. 269 3. NO MORE DESTINATION OPTIONS IN MOBILE IPv6 271 The use of Destination options for Binding Update and other MIPv6 272 control messages allowed the use of Binding Update specific 273 piggybacking. With the introduction of the generic end-to-end 274 piggybacking above there is no longer such a need. Thus it makes 275 sense to make the Mobile IPv6 control messages use a protocol that 276 allows them both to be treated separately by IPsec [IPSEC-SA] 277 implementations, and make it easier to implement this processing 278 separately from the main "ip_input" code path. 280 This can be accomplished by using UDP or by using one or more new 281 ICMP types (assuming IPsec implementations support selecting on ICMP 282 types; it is not required according to [IPSEC-SA]), or by defining a 283 new payload/protocol type for this purpose. 285 4. USE REGULAR TUNNELING BETWEEN MOBILE NODES 287 Currently when two mobile nodes are communicating using route 288 optimization the packet ends up containing a destination options 289 extension header with a home address option, which gets padded out to 290 24 bytes, and a routing header which is also 24 bytes. The 291 suggestion to conceptually use tunneling instead means that for this 292 mobile to mobile communication an extra IPv6 header is all that is 293 needed. In addition to the conceptual simplifications of using 294 tunneling there is an added bonus in this case; saving of 8 bytes per 295 packet. 297 5. IP TUNNELING WITH REDUNDANT SOURCE OR DESTINATION ADDRESSES 299 When IPinIP tunneling is used [TUNNEL] the packet ends up containing 300 four IP addresses. However, when sending packets between a non- 301 mobile CN and a MN there is only need for three IP addresses; for 302 packets from the CN to the MN there needs to be a source address, the 303 CoA of the MN, and the Home Address (HoA) of the MN. Similarly, from 304 packets from the MN to the CN the same set of addresses are needed 305 but the source and destination sense of them is inverted. 307 5.1. Three Address Tunneling Packet Format 309 The message format is the same for the two cases. Which one is used 310 is identified by the Next Header value in the previous extension 311 header. The two values are: 313 IPinIPnoSRC TBD [Assigned by IANA] 314 IPinIPnoDST TBD [Assigned by IANA] 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Next Header | Length = 3 | Reserved | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Reserved | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 + + 325 | | 326 + Address + 327 | | 328 + + 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 TBD: Does it make sense to include transport class and flowid in the 333 reserved fields above? 335 5.2. Sending Rules 337 A possible sending rule is that based on the assumption that the 338 sender somehow knows that the receiver supports both [TUNNEL] and the 339 above two new payload types. For Mobile IPv6 once could just require 340 that all nodes participating in Mobile IP (i.e. the same set of nodes 341 that support the Home Address Option and Route Optimization today) 342 also support encapsulation including the two new extension headers. 343 Presumably Mobile IPv6 needs a mechanism, such as an ICMP error, to 344 detect when a receiver does not support the home address option. A 345 similar mechanism could be used to detect that a receiver doesn't 346 support these headers. When the headers are not supported then in 347 the case of sending packets from a MN, the only choice would be to 348 reverse tunnel the packet through the HA. When sending packets to a 349 MN after establishing a Binding Cache Entry it would be a more or 350 less fatal error if the MN did not support the IPinIPnoSRC payload 351 type. 353 When sending a packet through a conceptual tunnel as described in 354 [TUNNEL], and the sender has reason to believe that the receiver, it 355 would compare the inner source with the inner destination as well as 356 the outer source and outer destination addresses. If the source 357 addresses match it would use a IPinIPnoSRC extension header with the 358 "Address" field in the extension header being the inner destination 359 address (the Home Address when sending to a MN). If the destination 360 addresses match the sender would use a IPinIPnoDST extension header 361 with the "Address" field being the inner source address (the Home 362 Address when sending a packet from a MN). If neither addresses match 363 then a regular [TUNNEL] packet would be sent. 365 5.3. Receiving Rules 367 A conceptual way of describing the receive side behavior is to expand 368 the above extension headers to a regular IPinIP header and then 369 process that IPinIP header by the usual rules. Such a scheme allows 370 the sending implementation to use IPinIP in all cases and the use of 371 IPinIPnoSRC and IPinIPnoDST are optimizations that the sender can use 372 to save bytes on the wire. 374 For IPinIPnoSRC this step involves replacing the IPinIPnoSRC header 375 with an IPinIP header and copying the source address from the outer 376 IP header into that new header while copying the Address field in the 377 IPinIPnoSRC to the destination field in the new header and updating 378 the payload length etc. 380 The same step for IPinIPnoDST just copies the outer IP destination 381 into the new inner header and takes the new inner header source from 382 the above Address field. 384 5.4. When to Accept Tunneled Packets 386 When Mobile IPv6 is using tunneling a conservative approach 387 security-wise would be to only accept the tunneled packets, unless 388 the node has other policies that are more permissive, based on the 389 content of the Binding Cache and Binding Update List [MIPv6]. 391 Packets where the inner and outer source match and the inner and 392 outer destinations differ, whether or not IPinIPnoSRC or IPinIP was 393 used to deliver the packet, SHOULD only be accepted if all of these 394 are true: 396 o The is the CoA and HoA for 397 an entry that is in the Binding Update list. Thus only nodes that 398 have been sent an unexpired binding update should be tunneling 399 such entries towards the node. 401 o The outer destination and inner destination belong to the same 402 zone [SCOPED-ARCH]. The reasons for this is in [RH-HA]. 404 o If the receiver is a security gateway i.e. treats some network 405 interfaces as being on the "inside" and others as the "outside" 406 (or perhaps has more that two such "domains") it SHOULD also 407 verify that the inner and outer destinations are in the same such 408 "domain". 410 Packets where the inner and outer destinations match and the inner 411 and outer sources differ, whether or not IPinIPnoDST or IPinIP was 412 used to deliver the packet, SHOULD only be accepted if all of these 413 are true: 415 o The matches a in the 416 Binding Cache. This restriction says that only nodes that have 417 managed to securely create a Binding Cache entry in the 418 correspondent can send packets directly to it using this form of 419 tunneling. If this is not the case an MN needs to tunnel packets 420 through the home agent so the packets will delivered to the CN 421 without any tunneling header. 423 Packets where both the inner and outer source and destinations are 424 different SHOULD only be accepted if all of these are true: 426 o The above rules in the case of matching destinations are 427 satisfied. 429 o The above rules in the case of matching source addresses are 430 satisfied. 432 When a packet is dropped because it does not satisfy the above 433 requirements an ICMP error (type and code TBD) should be sent back to 434 the outer source address. This message is then used by the sender to 435 detect e.g. when a CN has garbage collected a Binding Cache entry. 436 [TBD: This makes packet delivery depend on ICMP errors not being 437 discarded by firewalls! If this is an issue an option is to not allow 438 CNs to garbage collect binding cache entries until the lifetime 439 expire.] 441 Packets where both the inner and outer source and destinations are 442 the same SHOULD be dropped. 444 6. EXPLICIT MOVEMENT DETECTION 446 Note that unlike the other ideas presented in this document this 447 particular one can presumably be done at a later point in time. But 448 it would simplify the Mobile Nodes if they could use this movement 449 detection scheme instead of relying on a combination of the IPv6 450 addresses of the individual routers and the on-link prefixes that the 451 routers advertise as specified in [MIPv6]. 453 6.1. Location Indication Option Format 455 This specification defines a new Location Indication option for 456 Neighbor Discovery [ND]. This option is used in Router Advertisement 457 messages to help mobile nodes quickly detect when they appear in a 458 different link without resorting to ``guessing'' based on the 459 advertised prefixes in the router advertisements and Neighbor 460 Unreachability Detection specified in [MIPv6]. 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type | Length | Location Type | Reserved | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Reserved | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 + + 471 | | 472 + Identifying Address + 473 | | 474 + + 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Fields: 480 Type 8-bit identifier of the type of option. Value TBD. 482 Length 8-bit unsigned integer. The length of the option 483 (including the type and length fields) in units of 484 8 octets. Always 5 for this option. 486 Location Type 487 8-bit field specifying what level type of location 488 (granularity etc) that is captured in the 489 Identifying Address. The following types are 490 defined in this document: 492 Link Location 1 493 AAA domain indication 2 495 Identifying Address 496 128-bit IPv6 address. An IPv6 address which 497 together with the location type uniquely identifies 498 the location. 500 A mobile node would track the last received Identifying Address of 501 type "link location". When it receives a Location Indication of that 502 type with a different Identifying Address it should as quickly as 503 possible form a new care of address. If the Router Advertisement 504 contains Prefix options with the A-bit set it can immediately so 505 this. Otherwise it needs to send one or more Router Solicitations in 506 order to receive one or more such Prefix options. Once the mobile 507 node has a new care of address it can discard the old care of address 508 and the old default router list (the default routers which have not 509 been heard from after it received the new link location) and proceed 510 to send binding updates to the home agent and correspondents in the 511 Binding Update list as specified in [MIPv6]. 513 Routers that are configured to send Location Indication options 514 should verify, in addition to what is specified in the Section on 515 Router Advertisement Consistency in [ND], that other routers on the 516 same link use the same Identifying Address for the same Location 517 Type. If these is a mismatch this should be reported to system 518 management. 520 7. SECURITY CONSIDERATIONS 522 The generic end-to-end piggybacking allows arbitrary IP payloads to 523 be included in the same packet. Thus firewalls that care about IP 524 payloads need to inspect all of them. If the firewall is not capable 525 of doing this it is likely to drop the whole packet, and if the 526 firewall has the capability to inspect the multiple payloads it is 527 likely to drop the whole packet if any payload needs to be rejected. 528 Thus any use of this multiple payload header needs to be able to have 529 retransmission policies that avoid repeatedly trying to use the 530 header for retransmitted packets. 532 As pointed out in [RH-HA] the issues of processing Routing Headers as 533 used by Mobile IP and Home Address Options seem rather similar to the 534 concerns that exist for decapsulating and optionally forwarded 535 packets when using tunneling. 537 Using the framework that exists for tunneling to express this makes 538 Mobile IPv6 be able to leverage security mechanisms. However, the 539 specific policies for when to decapsulate packets are quite different 540 for the Mobile IP use of tunneling as outlined in Section 5.4. 542 The suggestion do to explicit movement detection allows any node on 543 the link, in the absence of authenticated and authorized Router 544 Advertisements, to send Location Indication options which would make 545 a Mobile Node think it has moved and attempt to form new Care of 546 Addresses. However, similar attacks can be launched against the 547 movement detection mechanisms in [MIPv6]. None of these attacks are 548 possible for off-link senders. 550 8. ACKNOWLEDGEMENTS 552 This document is mostly a collection of ideas that others have 553 suggested that I've tried to capture or this virtual paper. 555 Robert Elz wrote [PAYLOAD] many years back and Francis Dupont found a 556 copy of the old draft. 558 Bill Sommerfeld suggested using encapsulation instead of Routing 559 Headers and Home Address options on the mobileip mailing list. 561 TBD: List more names. 563 REFERENCES 565 [RH-HA] P. Savola, "Security of IPv6 Routing Header and Home Address 566 Options", draft-savola-ipv6-rh-ha-security-00.txt 568 [TUNNEL] A. Conta, and S. Deering, "Generic Packet Tunneling in IPv6 569 Specification", RFC 2473, December 1998. 571 [PAYLOAD] R. Elz, "The IPv6 Payload Header", Expired Internet Draft, 572 draft-kre-ipv6-payload-01.txt, October 1995. 574 [ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol 575 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 576 Specification", draft-ietf-ipngwg-icmp-v3-01.txt. 578 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 579 (IPv6) Specification", RFC 2460, December 1998. 581 [MIPv6] D. Johnson, C. Perkins. "Mobility Support in IPv6", draft- 582 ietf-mobileip-ipv6-14.txt. 584 [ND] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP 585 Version 6 (IPv6)", RFC 2461, December 1998. 587 [IPSEC-SA] R. Atkinson. "Security Architecture for the Internet 588 Protocol". RFC 2401, November 1998. 590 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 591 Requirement Levels", RFC 2119, March 1997. 593 [INGRESS] P. Ferguson, D. Senie, "Network Ingress Filtering: 594 Defeating Denial of Service Attacks which employ IP Source 595 Address Spoofing.", RFC 2827, May 2000. 597 AUTHORS' ADDRESSES 599 Erik Nordmark 600 Sun Microsystems Laboratories, Europe 601 29 Chemin du Vieux Chene 602 38240 Meylan, France 604 phone: +33 (0)4 76 18 88 03 605 fax: +33 (0)4 76 18 88 88 606 email: Erik.Nordmark@sun.com