idnits 2.17.1 draft-haddad-momipriv-problem-statement-03.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 628. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 26, 2006) is 6507 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) ** Downref: Normative reference to an Informational RFC: RFC 3792 (ref. 'CGA') -- Possible downref: Non-RFC (?) normative reference: ref. 'EPSPR' ** Obsolete normative reference: RFC 4306 (ref. 'IKE') (Obsoleted by RFC 5996) -- Possible downref: Non-RFC (?) normative reference: ref. 'LOPRIPEC' ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-00 ** Downref: Normative reference to an Informational draft: draft-ietf-monami6-mipv6-analysis (ref. 'MULTI') == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-06 ** Downref: Normative reference to an Informational RFC: RFC 3756 (ref. 'NDPT') == Outdated reference: A later version (-06) exists of draft-haddad-alien-privacy-terminology-01 ** Downref: Normative reference to an Informational draft: draft-haddad-alien-privacy-terminology (ref. 'PRITERM') -- Possible downref: Non-RFC (?) normative reference: ref. 'Priv-NG' -- No information found for draft-ietf-ipv6-privacy-address-v2 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Privacy' -- Possible downref: Non-RFC (?) normative reference: ref. 'WLAN-IID' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Haddad 3 Internet-Draft Ericsson Research 4 Expires: December 28, 2006 E. Nordmark 5 Sun Microsystems 6 F. Dupont 7 CELAR 8 M. Bagnulo 9 UC3M 10 B. Patil 11 Nokia 12 June 26, 2006 14 Privacy for Mobile and Multi-homed Nodes: Problem Statement 15 draft-haddad-momipriv-problem-statement-03 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 28, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This memo describes the privacy in mobility and multi-homing problem 49 statement. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . 4 55 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 57 4.1. Location Privacy vs. Privacy . . . . . . . . . . . . . . . 7 58 4.2. The MAC Layer Problem . . . . . . . . . . . . . . . . . . 8 59 4.3. The IP Layer Problem . . . . . . . . . . . . . . . . . . . 9 60 4.4. The Security Problem . . . . . . . . . . . . . . . . . . . 11 61 4.4.1. The IPsec Problem . . . . . . . . . . . . . . . . . . 11 62 4.4.2. The Secure Neighbor Discovery (SEND) Problem . . . . . 12 63 4.5. The Interdependency Problem . . . . . . . . . . . . . . . 13 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 68 Intellectual Property and Copyright Statements . . . . . . . . . . 19 70 1. Introduction 72 In the near future, mobility and multi-homing functionalities will 73 coexist in the majority of end hosts, such as terminals, PDAs, etc. 74 For this purpose, Mobile IPv6 [MIPv6] protocol has been designed to 75 provide a solution for the mobility at the network layer while Multi- 76 homing is still an ongoing work. 78 MIPv6 does not provide any mechanism to protect the mobile node's 79 privacy when moving across the Internet, while in the multi-homing 80 area, the privacy may well be supported in any potential solution but 81 may probably lack some features. This is mainly due to the fact that 82 the privacy issues are not limited to the IP layer only. 84 This memo describes the privacy in mobility and multi-homing 85 (momipriv) problem statement based on IPv6 only. 87 2. Conventions used in this document 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 [TERM]. 93 3. Glossary 95 For privacy related terminology, please refer to [PRITERM]. 97 MAC Address 99 A MAC Address is a 48 bits unique value associated with a network 100 adapter. The MAC address uniqueness is by default global. A MAC 101 Address is also known as the device/hardware identifier. 103 Link 105 A communication facility or medium over which nodes can communicate 106 at the link layer, such as an Ethernet (simple or bridged). A link 107 is the layer immediately below IP. 109 IPv6 Address 111 An IP address is a unique 128-bit IP layer identifier for an 112 interface or a set of interfaces attached to an IP network. 113 An IPv6 address can be unicast, i.e., identifier for a single 114 interface, or anycast, i.e., an identifier for a set of interfaces, 115 and a packet sent to an anycast address is delivered to only one 116 interface, or multicast, i.e., an identifier for a set of interfaces 117 and a packet sent to a multicast address is delivered to all these 118 interfaces. 120 Interface Identifier 122 A number used to identify a node's interface on a link. The 123 interface identifier is the remaining low-order bits in the node's IP 124 address after the subnet prefix. 126 Basic Service Set (BSS) 128 A set of stations controlled by a single coordination function. 130 Extended Service Set (ESS) 132 A set of one or more interconnected basic service set (BSSs) and 133 integrated local area networks (LANs) that appears as a single BSS to 134 the logical link control layer at any station associated with one of 135 those BSSs. 137 Distribution System (DS) 139 A system used to interconnect a set of basic service sets (BSSs) and 140 integrated local area networks (LANs) to create an extended service 141 set (ESS). 143 4. Problem Statement 145 The growing ability to trace a mobile node by an untrusted third 146 party, especially in public access networks, is a direct and serious 147 violation of the mobile user's privacy and can cause serious damage 148 to its personal, social and professional life. Privacy becomes a 149 real concern especially when the mobile node (MN) uses permanent 150 device and/or network identifiers. Unfortunately, the privacy 151 problem is not limited to a single layer and should not be solved 152 independantly on one layer. 154 Protecting the user's privacy can be achieved, in many scenarios, by 155 providing one or many of the privacy aspects defined above with 156 regards to the mobile node's requirements and/or location. For this 157 purpose, we try in the rest of this document to use the terms defined 158 above, in order to highlight the issues in a more precise way. 160 It should be noted that this document focuses only on the privacy 161 problem for a mobile and multi-homed node only and does not make any 162 assumption regarding the privacy of a static node, e.g., static 163 correspondent node (CN). In addition, this document assumes that the 164 real IPv6 address is not hidden by default, i.e., any node is always 165 reachable via its real IPv6 address. 167 The problem statement is divided into four problems. The first two 168 problems focus on the MAC and IP layers identifiers associated with a 169 mobile device, i.e., MAC and IP addresses, and describe privacy 170 issues resulting from using these identifiers in the context of a 171 mobile and multi-homed environment. The third problem addresses 172 privacy issues resulting from applying security mechanisms, e.g., IP 173 Security (IPsec) and Securing Neighbor Discovery (SEND) while the 174 fourth problem highlights the interdependency between the three 175 problems, as being the main requirement to be considered when 176 designing any potential solution. 178 But before delving into these problems, a quick overview on 179 differences between location privacy and privacy is provided. 181 4.1. Location Privacy vs. Privacy 183 Before describing privacy problems related to the IP and the link 184 layer, it seems useful to highlight the differences between the 185 location privacy and privacy, in order to avoid a possible confusion 186 later. 188 Location privacy is the ability to prevent other parties from 189 learning one's current or past location [LOPRIPEC]. In order to get 190 such ability, the mobile node must conceal any relation between its 191 location and the personal identifiable information. Note that in the 192 momipriv context, the mobile node location refers normally to the 193 topological location and not the geographic one. The latter is 194 provided by other means (e.g., GPS) than an IPv6 address. But it 195 should be noted that it may possible sometimes to deduce the 196 geographical location from the topological one. 198 However, concealing any relation between the location and the user's 199 identifier(s) does not guarantee that the identifier(s) itself will 200 not be disclosed, since it may be possible to hide the real location 201 alone. But, having at least one user's identifier disclosed may be 202 enough (e.g., if coupled with prior knowledge about few possible 203 whereabouts) for other party to discover the user's current and/or 204 previous location(s). 206 For example, in a context limited to IP and MAC layers, the only 207 available identifiers and/or locators are the IP and MAC addresses, 208 and only the IP address carries information, which can directly 209 disclose the MN's location (note that mobile IPv6 discloses both the 210 mobile node's home and current locations). 212 The MAC address alone does not provide any hint regarding the mobile 213 node current/previous location. But if the other party has already 214 established the link between the target and its MAC address and 215 gained knowledge about some of the user's possible current/future 216 whereabouts, then it will be possible to locate and even track the 217 target. 219 On the other side, it should be noted that the two main privacy 220 aspects, i.e., anonymity and pseudonymity, provide implicitly the 221 location privacy feature by concealing the real user's identifiers 222 regardless of his/her location(s). 223 Actually, in both privacy aspects, real identifiers are replaced by 224 static or dynamic ones, thus making the other party no more able to 225 identify its target even at the correct location, i.e., any past/ 226 current location information becomes practically useless for locating 227 and tracking purposes. 229 4.2. The MAC Layer Problem 231 The first problem focus on the MAC layer and is raising growing 232 concerns related to the user's privacy, especially with the massive 233 ongoing indoor/outdoor deployment of WLAN technologies. 235 A mobile device attached to a particular link is uniquely identified 236 on that link by its MAC address, i.e., the device identifier. In 237 addition, the device identifier is disclosed in any packet sent by/to 238 the MN when it reaches that particular link, thus making it a very 239 efficient tool to trace a mobile user in a shared wireless medium 240 access. Similar problems have caused bad press for cellular 241 operators. 243 For example, a malicious node located in one distributed system (DS) 244 can trace a mobile node via its device identifier while moving in the 245 entire ESS, and learn enough information about the user's activities 246 and whereabouts. Having these information available in the wrong 247 hands, especially with the exact time when they occur, may have bad 248 consequences on the user. 250 Another concern on the MAC layer, which can also be exploited by an 251 eavesdropper to trace its victim, is the sequence number (SQN) 252 carried by the frame header. The sequence number is incremented by 1 253 for each data frame and allows the bad guy to trace its targeted 254 node, in addition to the MAC address. 255 In addition, the sequence number allows also the malicious node to 256 keep tracing the MN, if/when the real MAC address is replaced by one 257 or many pseudo-identifier(s) during an ongoing session [WLAN-IID]. 259 In addition, it should be noted that even if the real MN's device 260 identifier remains undisclosed during all ongoing session(s), it may 261 probably not be enough to provide the unlinkability protection on the 262 MAC layer, between ongoing session(s). 263 Actually, in a scenario, where the malicious node is located on the 264 link or within the distributed system, replacing the real MAC address 265 with a static pseudo-identifier, i.e., to provide pseudonymity, or 266 with temporary ones, i.e., to provide anonymity, it will always be 267 possible to break the unlinkability protection provided by the MAC 268 layer if the MN's IPv6 address remains unchanged. 270 Note that in such scenario, even a periodical change of the sequence 271 number won't prevent the eavesdropper from correlating ongoing 272 session(s), pseudo-identifiers and the mobile node. 274 However, it should be mentioned that replacing the real device 275 identifier with static/dynamic pseudo-identifiers, in order to 276 provide anonymity/pseudonymity, during an ongoing session(s), raises 277 another critical issue on the MAC layer level, which concerns the 278 uniqueness of these new pseudo-identifier(s). 280 In fact, any temporary/static identifiers MUST be unique within the 281 Extended Service Set (ESS) and the distributed system (DS). 283 4.3. The IP Layer Problem 285 The second problem focus on the IP layer and analyzes the privacy 286 problems related to IPv6 only. 288 A MN can configure its IPv6 address either from a DHCP server or by 289 itself. The latter scenario is called the stateless address 290 autoconfiguration [STAT], and discloses the MN MAC address in the 291 IPv6 address, thus enabling an eavesdropper to easily learn both 292 addresses in this case. 294 In order to mitigate the privacy concerns raised from using the 295 stateless address auto-configuration, [Privacy] introduced a method 296 allowing to periodically change the MN's interface identifier. 297 However, being limited to the interface identifier only, such change 298 discloses the real network identifier, which in turn can reveal 299 enough information about the topological location, the user or can 300 even be the exact piece of information needed by the eavesdropper. 301 Another limitation to its efficiency lays in the fact that such 302 change cannot occur during an ongoing session. 304 While using only a different IPv6 address for each new session may 305 prevent/mitigate the ability to trace a MN on the IP layer level, it 306 remains always possible to trace it through its device identifier(s) 307 on the MAC layer level, i.e., when a malicious node (or another one) 308 is also attached to the same link/DS than its target. 309 Consequently, it will be possible to learn all IPv6 addresses used by 310 the MN by correlating different sessions, thus breaking any 311 unlinkability protection provided at the IP layer. 313 MIPv6 allows an MN to move across the Internet while ensuring optimal 314 routing (i.e., by using route optimization (RO)) mode and keeping 315 ongoing session(s) alive. Although these two features make the RO 316 mode protocol looks efficient, they disclose the MN's home IPv6 317 address and its current location, i.e., care-of address (CoA), in 318 each data packet exchanged between the MN and the correspondent node 319 (CN). 321 Furthermore, each time a MN switches to a new network, it has to send 322 in clear a binding update (BU) message to the CN to notify it about 323 its new location. 325 Consequently, MIPv6 RO mode discloses to a malicious node located 326 between the MN and the CN, all data required to identify, locate and 327 trace in real time its mobile target, once it moves outside its home 328 network(s) [Priv-NG]. 330 MIPv6 defines another mode called the bidirectional tunneling (BT), 331 which allows the MN to hide its movements and locations from the CN 332 by sending all data packets through its HA (i.e., encapsulated). In 333 such mode, the CN uses only the MN's home IPv6 address to communicate 334 with the MN. 336 But if the CN initiates a session with a MN then it has to use the 337 MN's home IPv6 address. In such scenario, if the MN wants to keep 338 its movements hidden from the CN, then it has to switch to the 339 bidirectional tunneling mode. 341 Consequently, all data packets sent/received by the MN are exchanged 342 through the MN's HA and the MN needs to update only its HA with its 343 location. 345 Although, the bi-directional tunneling mode allows hiding the MN's 346 care-of address to the CN, it can disclose its real identity, i.e., 347 IPv6 home address, and current location to a malicious node located 348 between the HA and the MN (e.g., by looking to the data packets inner 349 header), unless the HA-MN tunnel is protected by using the IP 350 Encapsulation Security Payload [ESP]. 352 In addition to mobility, the multi-homing feature allows a mobile 353 node to belong to different home networks and to switch between these 354 home networks without interrupting ongoing session(s) [MULTI]. 356 Although multi-homing can be considered as another aspect of 357 mobility, switching between different home networks, in addition to 358 moving between foreign networks, can disclose to a malicious node 359 well located between the multi-homed MN and the CN, part or all of 360 the MN's home IPv6 addresses, its device identifiers (e.g., when 361 stateless address autoconfiguring is used) and its location(s). Such 362 variety of identifiers can make the malicious eavesdropper's task 363 easier. 365 For example, a malicious node located between the MN and the CN can 366 start tracing its victim based on prior knowledge of one of its home 367 address or MAC address, and by tracking the BU messages (e.g., the MN 368 is using the RO mode). 369 After that, the malicious eavesdropper can correlate between 370 different signaling messages and possibly data packets to expand his 371 knowledge to other victim's home/MAC addresses. Learning new 372 identifiers offer the eavesdropper additional tools to detect and 373 track future movements. 375 4.4. The Security Problem 377 4.4.1. The IPsec Problem 379 [IPsec] provides a set of security services at the IP layer. These 380 security services are provided through the use of two traffic 381 security protocols, i.e., namely the Authentication Header [AH] and 382 the ESP protocols, and through the use of cryptographic key 383 management procedures and protocols, e.g., Internet Key Exchange 384 [IKE] protocol. 386 ESP and AH protocols make use of Security Associations (SAs) and a 387 major function of IKE protocol is to establish and maintain these 388 SAs. An SA is always identified by a static 32-bit parameter, i.e., 389 Security Paramater Index (SPI), and possibly IP addresses. 391 Based on above, an IPsec SPI can be used to trace a particular mobile 392 node from one place to another, even if its IP address may change, 393 (e.g., if [MobIKE] or [SCTP_IPsec] is used). Tracing remains 394 possible even if care is taken to change the MAC address at the same 395 time than the IP address. 396 Consequently, the IPsec SPI can be an efficient tool to break the 397 unlinkability protection provided by a change(s) of the IP and MAC 398 addresses (even if both addresses change at the same time), and also 399 to learn and link the MN's new pseudo-IDs. 401 This is particularly problematic for the Internet Key Exchange 402 protocol (described in [IKE]) SPIs, as there is no possibility for 403 efficiently re-negotiating IKE shared secret(s), i.e., SPIs, without 404 revealing the previous SPIs in the process. Note that re-negotiating 405 an IPsec SPI may be done within the protection of the IKE SA, hence 406 hiding the change from eavesdroppers [EPSPR]. 408 4.4.2. The Secure Neighbor Discovery (SEND) Problem 410 In order to protect against threats related to the IPv6 Neighbor 411 Discovery protocol [NDP] and described in [NDPT], the IETF has 412 standardized the [SEND] protocol, which specifies security mechanisms 413 for IPv6 NDP. 415 SEND protocol enables a secure neighbor cache discovery and 416 construction by relying on the cryptographically generated addresses 417 [CGA] technology to provide a proof of address ownership. 419 CGA technology consists on generating an RSA key pair and configuring 420 an IPv6 address(es) from hashing the derived public key and other 421 parameters. When using SEND protocol, the MN has to sign NDP 422 messages with its CGA private key. 424 However, it is important to mention that generating an RSA key pair 425 on small devices is a computationally expensive and lenghty 426 procedure, i.e., power consumption is relatively high. Consequently, 427 it is likely that such limitation may force the MN to use only one 428 RSA key pair for a relatively long period of time, e.g., during an 429 ongoing session. A more optimistic scenario would consist on 430 precomputing few key pairs and using them in a random way. 432 As a result, hiding both the MN's IP and MAC addresses and 433 periodically refreshing the SPI(s) (when they are used) and SQN(s) 434 may not be enough to prevent the malicious eavesdropper from tracing 435 the MN's movements by detecting ts CGA public key(s) sent during the 436 Neighbor Discovery messages exchange, e.g., during a DAD procedure 437 following an IP handoff. Note also that tracing the public key(s) 438 can help the malicious node to link between different pseudo- 439 identifiers at the MAC and IP levels. 441 4.5. The Interdependency Problem 443 The MAC and IP layers problems described above highlight another 444 concern that needs to be addressed in order to protect the MN's 445 identifiers and/or hiding its locations: any change/update of the IP 446 address and the MAC pseudo-identifier, as well as all other static 447 parameter must be performed in a synchronized way. 449 Otherwise, a change/update for example at the IP layer only, may 450 allow the eavesdropper to keep tracing the MN via the device 451 identifier and/or other static parameters, and consequently to learn 452 how/when the MN's identifiers are modified on the MAC layer, thus 453 making such change(s) meaningless. 455 5. Security Considerations 457 This document is a problem statement, which describes privacy issues 458 related to a mobile and multi-homed node, and does not introduce 459 security considerations by itself. 461 However it should be noted that any potential solution for the 462 momipriv problem, which allows using temporary device identifiers, 463 dynamic pseudo-IP addresses and other parameters during an ongoing 464 session should not allow a malicious eavesdropper to learn how nor 465 when these identifiers are updated. 467 Any potential solution must protect against replaying messages using 468 old identifiers and/or hijacking an ongoing session during an update 469 of the identifiers. 471 Any potential solution should not allow exploiting any aspect of 472 privacy, in order to gain access to networks. 474 6. Acknowledgements 476 Soohong Daniel Park and Hannes Tschofenig have contributed to this 477 document. Many thanks to them. 479 7. References 481 [AH] Kent, S., "IP Authentication Header", RFC 4302, 482 December 2005. 484 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 485 RFC 3792, March 2005. 487 [EPSPR] Arkko, J., Nikander, P., and M. Naslund, "Enhancing 488 Privacy with Shared Pseudo Random Sequences", Security 489 Proposals, 13rd International Workshop, Cambridge, 490 April 2005. 492 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 493 RFC 4303, December 2005. 495 [IKE] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 496 RFC 4306, December 2005. 498 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 499 Internet Protocol", RFC 4301, December 2005. 501 [LOPRIPEC] 502 Beresfold, A. and F. Stajano, "Location Privacy in 503 Pervasive Computing", IEEE Pervasive Computing, 2003. 505 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 506 in IPv6", RFC 3775, June 2004. 508 [MULTI] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 509 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 510 Internet Draft, draft-ietf-monami6-mipv6-analysis-00.txt, 511 February 2006. 513 [MobIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 514 (MOBIKE)", RFC 4555, June 2006. 516 [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 517 "Neighbor Discovery for IPv6", Internet 518 Draft, draft-ietf-ipv6-2461bis-06.txt, May 2006. 520 [NDPT] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 521 Discovery (ND) Trust Models and Threats", RFC 3756, 522 May 2004. 524 [PRITERM] Haddad, W. and E. Nordmark, "Privacy Terminology", 525 Internet 526 Draft, draft-haddad-alien-privacy-terminology-01.txt, 527 June 2006. 529 [Priv-NG] Escudero-Pascual, A., "Privacy in the Next Generation 530 Internet: Data Protection in the context of the European 531 Union Policy", PhD Dissertation, December 2002. 533 [Privacy] Narten, T., Draves, R., and S. Krishnan, "Privacy 534 Extensions for Stateless Address Autoconfiguration in 535 IPv6", 536 Internet-Draft, draft-ietf-ipv6-privacy-address-v2-04.txt, 537 May 2005. 539 [SCTP_IPsec] 540 Bellovin, S., Ioannidis, J., and A. Keromytis, "On the Use 541 of Stream Control Transmission Protocol (SCTP) with 542 IPsec", RFC 3554, July 2003. 544 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 545 Neighbor Discovery (SEND)", RFC 3971, March 2005. 547 [STAT] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 548 Address Autoconfiguration", Internet 549 Draft, draft-ietf-ipv6-rfc2462bis-08.txt, May 2005. 551 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 552 Requirement Levels", RFC 2119, BCP , March 1997. 554 [WLAN-IID] 555 Gruteser, M. and D. Grunwald, "Enhancing Location Privacy 556 in Wireless LAN Through Disposable Interface Identifiers: 557 A Quantitative Analysis", First ACM International 558 Workshop Wireless Mobile Applications and Services on WLAN 559 Hotspots, September 2003. 561 Authors' Addresses 563 Wassim Haddad 564 Ericsson Research 565 Torshamnsgatan 23 566 SE-164 Stockholm 567 Sweden 569 Phone: +46 84044079 570 Email: Wassim.Haddad@ericsson.com 572 Erik Nordmark 573 Sun Microsystems 574 17 Network Circle 575 Menlo Park, CA 94025 576 USA 578 Phone: +1 650 786 2921 579 Email: Erik.Nordmark@sun.com 581 Francis Dupont 582 CELAR 583 France 585 Email: Francis.Dupont@point6.fr 587 Marcelo Bagnulo 588 UC3M 589 Universidad Carlos III de Madrid 590 Av. Universidad 30 591 Leganes, Madrid 28911 592 Spain 594 Phone: +31 91 6249500 595 Email: Marcelo@it.uc3m.es 596 URI: http://www.it.uc3m.es 597 Basavaraj Patil 598 Nokia 599 6000 Connection Drive 600 Irving, TX 75039 601 USA 603 Phone: +1 972 8946709 604 Email: Basavaraj.Patil@nokia.com 606 Intellectual Property Statement 608 The IETF takes no position regarding the validity or scope of any 609 Intellectual Property Rights or other rights that might be claimed to 610 pertain to the implementation or use of the technology described in 611 this document or the extent to which any license under such rights 612 might or might not be available; nor does it represent that it has 613 made any independent effort to identify any such rights. Information 614 on the procedures with respect to rights in RFC documents can be 615 found in BCP 78 and BCP 79. 617 Copies of IPR disclosures made to the IETF Secretariat and any 618 assurances of licenses to be made available, or the result of an 619 attempt made to obtain a general license or permission for the use of 620 such proprietary rights by implementers or users of this 621 specification can be obtained from the IETF on-line IPR repository at 622 http://www.ietf.org/ipr. 624 The IETF invites any interested party to bring to its attention any 625 copyrights, patents or patent applications, or other proprietary 626 rights that may cover technology that may be required to implement 627 this standard. Please address the information to the IETF at 628 ietf-ipr@ietf.org. 630 Disclaimer of Validity 632 This document and the information contained herein are provided on an 633 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 634 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 635 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 636 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 637 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 638 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 640 Copyright Statement 642 Copyright (C) The Internet Society (2006). This document is subject 643 to the rights, licenses and restrictions contained in BCP 78, and 644 except as set forth therein, the authors retain all their rights. 646 Acknowledgment 648 Funding for the RFC Editor function is currently provided by the 649 Internet Society.