idnits 2.17.00 (12 Aug 2021) /tmp/idnits3332/draft-haddad-momipriv-problem-statement-01.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 3667, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 626. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 353: '...atic identifiers MUST be unique within...' 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 (February 2005) is 6303 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: 'Priv-NG' is mentioned on line 401, but not defined == Missing Reference: 'PRIVACY' is mentioned on line 368, but not defined == Unused Reference: 'PRIV-NG' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'Privacy' is defined on line 522, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ANON' -- Possible downref: Non-RFC (?) normative reference: ref. 'ANON-PRIV' -- Possible downref: Non-RFC (?) normative reference: ref. 'Freedom' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO99' -- 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-montavont-mobileip-multihoming-pb-statement-03 -- Possible downref: Normative reference to a draft: ref. 'MULTI' -- Possible downref: Non-RFC (?) normative reference: ref. 'PRIV-NG' -- Possible downref: Non-RFC (?) normative reference: ref. 'PRIV-STAT' == Outdated reference: draft-ietf-ipv6-privacy-addrs-v2 has been published as RFC 4941 == Outdated reference: draft-ietf-ipv6-rfc2462bis has been published as RFC 4862 -- Possible downref: Non-RFC (?) normative reference: ref. 'WLAN-IID' Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Wassim Haddad 2 Mobility and Multi-homing Privacy Ericsson 3 Internet Draft Erik Nordmark 4 Expires July 2005 Sun Microsystems 5 Francis Dupont 6 Point6 7 Marcelo Bagnulo 8 UC3M 9 Soohong Daniel Park 10 Samsung Electronics 11 Basavaraj Patil 12 Nokia 13 February 2005 15 Privacy for Mobile and Multi-homed Nodes: 16 MoMiPriv Problem Statement 17 19 Status of this Memo 21 By submitting this Internet-Draft, I certify that any applicable 22 patent or other IPR claims of which I am aware have been 23 disclosed, or will be disclosed, and any of which I become aware 24 will be disclosed, in accordance with RFC 3668. 26 This document is an Internet Draft and is in full conformance with 27 all provisions of Section 10 of RFC 2026. 29 This document is an Internet-Draft. Internet-Drafts are working 30 documents of the Internet Engineering Task Force (IETF), its 31 areas, and its working groups. Note that other groups may also 32 distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet- 36 Drafts as reference material or to cite them other than as 37 "work in progress." 39 The list of current Internet Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Distribution of this memo is unlimited 46 Abstract 48 This memo describes the privacy in mobility and multi-homing 49 problem statement. 51 Table of Contents 53 1. Introduction................................................2 54 2. Glossary....................................................3 55 3. Problem Statement...........................................6 56 3.1. Location Privacy vs. Privacy...........................6 57 3.2. The MAC Layer Problem..................................8 58 3.3. The IP Layer Problem...................................9 59 3.4. The Interdependency Problem...........................11 60 4. Security Considerations....................................11 61 5. Acknowledgments............................................11 62 6. References.................................................12 63 7. Authors' Addresses.........................................13 64 Intellectual Property Statement...............................15 65 Disclaimer of Validity........................................15 66 Copyright Statement...........................................15 68 1. Introduction 70 In the near future, mobility and multi-homing functionalities 71 will coexist in the majority of end hosts, such as terminals, 72 PDAs, etc. For this purpose, Mobile IPv6 [MIPv6] protocol has 73 been designed to provide a solution for the mobility at the 74 network layer while Multi-homing is still an ongoing work. 76 MIPv6 does not provide any mechanism to protect the mobile 77 node's privacy when moving across the Internet, while in the 78 multi-homing area, the privacy may well be supported in any 79 potential solution but may probably lack some features. This is 80 mainly due to the fact that the privacy issues are not limited 81 to the IP layer only. 83 This memo describes the privacy in mobility and multi-homing 84 (momipriv) problem statement based on IPv6 only. 86 2. Glossary 88 Anonymity 90 Anonymity is a property of network security. An entity "A" 91 in a system has anonymity if no other entity can identify 92 "A", nor is there any link back to "A" that can be used, nor 93 any way to verify that any two anonymous acts are performed 94 by "A". 96 Anonymity ensures that a user may use a resource or service 97 without disclosing the user's identity. 99 Anonymity in wireless networks means that neither the mobile 100 node nor its system software shall by default expose any 101 information, that allows any conclusions on the owner or 102 current use of the node. 104 Consequently, in scenarios where a device and/or network 105 identifiers are used (e.g., MAC address, IP address), 106 neither the communication partner nor any outside attacker 107 should be able to disclose any possible link between the 108 respective identifier and the user's identity. 110 Pseudonymity 112 Pseudonymity is a weaker property related to anonymity. It 113 means that one cannot identify an entity, but it may be 114 possible to prove that two pseudonymous acts were performed 115 by the same entity. 117 Pseudonymity ensures that a user may use a resource or 118 service without disclosing its user identity, but can still 119 be accountable for that use. 121 Consequently, a pseudonym is an identifier for a party to a 122 transaction, which is not in the normal course of events, 123 sufficient to associate the transaction with a particular 124 user. 126 Hence a transaction is pseudonymous in relation to a 127 particular party if the transaction data contains no direct 128 identifier for that party, and can only be related to them 129 in the event that a very specific piece of additional data 130 is associated with it. 132 Unlinkability 134 Two events are unlinkable if they are no more and no less 135 related than they are related concerning the a-priori 136 knowledge. 138 Unlinkability ensures that a user may make use of resources 139 or services without others being able to link these two 140 uses together. 142 Note that unlinkability is a sufficient condition of 143 anonymity, but it is not a necessary condition. 145 Privacy 147 Privacy is a more general term than anonymity. Privacy is 148 the claim of individuals, groups and institutions to 149 determine for themesleves, when, how and to what extent 150 information about them is communicated to others. 152 In wireless telecommunications, privacy addresses especially 153 the protection of the content as well as the context (e.g., 154 time, location, type of service, ...) of a communication 155 event. 157 Consequently, neither the mobile node nor its system 158 software shall support the creation of user-related usage 159 profiles. Such profiles basically comprise of a correlation 160 of time and location of the node's use, as well as the type 161 and details of the transaction performed. 163 Privacy can even be achieved by disconnectivity, i.e., not 164 being connected to a network. 166 MAC Address 168 A MAC Address is a 48 bits unique value associated with a 169 network adapter. The MAC address uniqueness is by default 170 global. A MAC Address is also known as the device/hardware 171 identifier. 173 Link 175 A communication facility or medium over which nodes can 176 communicate at the link layer, such as an Ethernet (simple 177 or bridged). A link is the layer immediately below IP. 179 IPv6 Address 181 An IP address is a unique 128-bit IP layer identifier for an 182 interface or a set of interfaces attached to an IP network. 183 An IPv6 address can be unicast, i.e., identifier for a 184 single interface, or anycast, i.e., an identifier for a set 185 of interfaces, and a packet sent to an anycast address is 186 delivered to only one interface, or multicast, i.e., an 187 identifier for a set of interfaces and a packet sent to a 188 multicast address is delivered to all these interfaces. 190 Interface Identifier 192 A number used to identify a node's interface on a link. The 193 interface identifier is the remaining low-order bits in the 194 node's IP address after the subnet prefix. 196 Basic Service Set (BSS) 198 A set of stations controlled by a single coordination 199 function. 201 Extended Service Set (ESS) 203 A set of one or more interconnected basic service set (BSSs) 204 and integrated local area networks (LANs) that appears as a 205 single BSS to the logical link control layer at any station 206 associated with one of those BSSs. 208 Distribution System (DS) 210 A system used to interconnect a set of basic service sets 211 (BSSs) and integrated local area networks (LANs) to create 212 an extended service set (ESS). 214 For more literature about the Glossary content, please refer to 215 [ANON], [ISO99], [Priv-NG], [Freedom] and [ANON-PRIV]. 217 3. Problem Statement 219 The growing ability to trace a mobile node by an untrusted 220 third party, especially in public access networks, is a direct 221 and serious violation of the mobile user's privacy and can 222 cause serious damage to its personal, social and professional 223 life. Privacy becomes a real concern especially when the mobile 224 node (MN) uses permanent device and/or network identifiers. 225 Unfortunately, the privacy problem is not limited to a single 226 layer and should not be solved independantly on one layer. 228 Protecting the user's privacy can be achieved, in many 229 scenarios, by providing one or many of the privacy aspects 230 defined above with regards to the mobile node's requirements 231 and/or location. For this purpose, we try in the rest of this 232 document to use the terms defined above, in order to highlight 233 the issues in a more precise way. 235 It should be noted that this document focuses only on the 236 privacy problem for a mobile and multi-homed node only and does 237 not make any assumption regarding the privacy of a static node, 238 e.g., static correspondent node (CN). In addition, this 239 document assumes that the real IPv6 address is not hidden by 240 default, i.e., any node is always reachable via its real IPv6 241 address. 243 The problem statement is divided into three problems. The first 244 two problems are related to the identifiers associated with a 245 mobile device, i.e., the MAC address and the IP address, and the 246 third problem highlights their interdependency. But before 247 delving into these problems, a quick overview on differences 248 between location privacy and privacy is provided. 250 3.1. Location Privacy vs. Privacy 252 Before describing privacy problems related to the IP and the 253 link layer, it seems useful to highlight the differences between 254 the location privacy and privacy, in order to avoid a possible 255 confusion later. 257 Location privacy is the ability to prevent other parties from 258 learning one's current or past location [LOPRIPEC]. In order 259 to get such ability, the mobile node must conceal any relation 260 between its location and the personal identifiable information. 261 Note that in the momipriv context, the mobile node location 262 refers normally to the topological location and not the 263 geographic one. The latter is provided by other means (e.g., 264 GPS) than an IPv6 address. But it should be noted that it may 265 possible sometimes to deduce the geographical location from 266 the topological one. 268 However, concealing any relation between the location and the 269 user's identifier(s) does not guarantee that the identifier(s) 270 itself will not be disclosed, since it may be possible to hide 271 the real location alone. But, having at least one user's 272 identifier disclosed may be enough (e.g., if coupled with prior 273 knowledge about few possible whereabouts) for other party to 274 discover the user's current and/or previous location(s). 276 For example, in a context limited to IP and MAC layers, the 277 only available identifiers and/or locators are the IP and MAC 278 addresses, and only the IP address carries information, which 279 can directly disclose the MN's location (note that mobile IPv6 280 discloses both the mobile node's home and current locations). 282 The MAC address alone does not provide any hint regarding the 283 mobile node current/previous location. But if the other party 284 has already established the link between the target and its 285 MAC address and gained knowledge about some of the user's 286 possible current/future whereabouts, then it will be possible 287 to locate and even track the target. 289 On the other side, it should be noted that the two main 290 privacy aspects, i.e., anonymity and pseudonymity, provide 291 implicitly the location privacy feature by concealing the 292 real user's identifiers regardless of his/her location(s). 293 Actually, in both privacy aspects, real identifiers are 294 replaced by static or dynamic ones, thus making the other 295 party no more able to identify its target even at the 296 correct location, i.e., any past/current location 297 information becomes practically useless for locating and 298 tracking purposes. 300 3.2. The MAC Layer Problem 302 The first problem focus on the MAC layer and is raising growing 303 concerns related to the user's privacy, especially with the 304 massive ongoing indoor/outdoor deployment of WLAN technologies. 306 A mobile device attached to a particular link is uniquely 307 identified on that link by its MAC address, i.e., the device 308 identifier. In addition, the device identifier is disclosed in 309 any packet sent by/to the MN when it reaches that particular 310 link, thus making it a very efficient tool to trace a mobile 311 user in a shared wireless medium access. Similar problems have 312 caused bad press for cellular operators. 314 For example, a malicious node located in one distributed system 315 (DS) can trace a mobile node via its device identifier while 316 moving in the entire ESS, and learn enough information about 317 the user's activities and whereabouts. Having these information 318 available in the wrong hands, especially with the exact time 319 when they occur, may have bad consequences on the user. 321 Another concern on the MAC layer, which can also be exploited 322 by an eavesdropper to trace its victim, is the sequence number 323 carried by the frame header. The sequence number is incremented 324 by 1 for each data frame and allows the bad guy to trace its 325 targeted node, in addition to the MAC address. 326 In addition, the sequence number allows also the malicious node 327 to keep tracing the MN, if/when the real MAC address is replaced 328 by one or many pseudo-identifier(s) during an ongoing session 329 [WLAN-IID]. 331 In addition, it should be noted that even if the real MN's device 332 identifier remains undisclosed during all the session(s), it may 333 probably not be enough to provide the unlinkability protection 334 on the MAC layer, between ongoing session(s). 335 Actually, in a scenario, where the malicious node is located on 336 the link or in the distributed system, replacing the real MAC 337 address with a static pseudo-identifier, i.e., to provide 338 pseudonymity, or with temporary ones, i.e., to provide anonymity, 339 it will always be possible to break the unlinkability protection 340 provided by the MAC layer if the MN's IPv6 address remains 341 unchanged. 343 Note that in such scenario, even a periodical change of the 344 sequence number won't prevent the eavesdropper from correlating 345 ongoing session(s), pseudo-identifiers and the mobile node. 347 However, it should be mentioned that replacing the real device 348 identifier with static/dynamic pseudo-identifiers, in order to 349 provide anonymity/pseudonymity, during an ongoing session(s), 350 raises another critical issue on the MAC layer level, which 351 concerns the uniqueness of these new pseudo-identifier(s). 353 In fact, any temporary/static identifiers MUST be unique within 354 the Extended Service Set (ESS) and the distributed system (DS). 356 3.3. The IP Layer Problem 358 The second problem focus on the IP layer and analyzes the 359 privacy problems related to IPv6 only. 361 A MN can configure its IPv6 address either from a DHCP server 362 or by itself. The latter scenario is called the stateless 363 address autoconfiguration [STAT], and discloses the MN MAC 364 address in the IPv6 address, thus enabling an eavesdropper to 365 easily learn both addresses in this case. 367 In order to mitigate the privacy concerns raised from using 368 the stateless address auto-configuration [PRIV-STAT], [PRIVACY] 369 introduced a method allowing to periodically change the MN's 370 interface identifier. 371 However, being limited to the interface identifier only, such 372 change discloses the real network identifier, which in turn can 373 reveal enough information about the topological location, the 374 user or can even be the exact piece of information needed by the 375 eavesdropper. Another limitation to its efficiency lays in the 376 fact that such change cannot occur during an ongoing session. 378 While using only a different IPv6 address for each new session 379 may prevent/mitigate the ability to trace a MN on the IP layer 380 level, it remains always possible to trace it through its device 381 identifier(s) on the MAC layer level, i.e., when a malicious node 382 (or another one) is also attached to the same link/DS than its 383 target. Consequently, it will be possible to learn all IPv6 384 addresses used by the MN by correlating different sessions, thus 385 breaking any unlinkability protection provided at the IP layer. 387 MIPv6 allows an MN to move across the Internet while ensuring 388 optimal routing (i.e., by using route optimization (RO)) mode 389 and keeping ongoing session(s) alive. Although these two 390 features make the RO mode protocol looks efficient, they 391 disclose the MN's home IPv6 address and its current location, 392 i.e., care-of address (CoA), in each data packet exchanged 393 between the MN and the correspondent node (CN). 394 Furthermore, each time a MN switches to a new network, it has 395 to send in clear a binding update (BU) message to the CN to 396 notify it about its new location. 398 Consequently, MIPv6 RO mode discloses to a malicious node 399 located between the MN and the CN, all data required to 400 identify, locate and trace in real time its mobile target, 401 once it moves outside its home network(s) [Priv-NG]. 403 MIPv6 defines another mode called the bidirectional tunneling 404 (BT), which allows the MN to hide its movements and locations 405 from the CN by sending all data packets through its HA (i.e., 406 encapsulated). In such mode, the CN uses only the MN's home 407 IPv6 address to communicate with the MN. 409 But if the CN initiates a session with a MN then it has to use 410 the MN's home IPv6 address. In such scenario, if the MN wants 411 to keep its movements hidden from the CN, then it has to switch 412 to the bidirectional tunneling mode. 414 Consequently, all data packets sent/received by the MN are 415 exchanged through the MN's HA and the MN needs to update only 416 its HA with its location. 418 Although, the bi-directional tunneling mode allows hiding the 419 MN's care-of address to the CN, it can disclose its real 420 identity, i.e., IPv6 home address, and current location to a 421 malicious node located between the HA and the MN (e.g., by 422 looking to the data packets inner header), unless the HA-MN 423 tunnel is protected by using ESP. 425 In addition to mobility, the multi-homing feature allows a 426 mobile node to belong to different home networks and to switch 427 between these home networks without interrupting ongoing 428 session(s) [MULTI]. 430 Although multi-homing can be considered as another aspect of 431 mobility, switching between different home networks, in addition 432 to moving between foreign networks, can disclose to a malicious 433 node well located between the multi-homed MN and the CN, part or 434 all of the MN's home IPv6 addresses, its device identifiers 435 (e.g., when stateless address autoconfiguring is used) and its 436 location(s). Such variety of identifiers can make the malicious 437 eavesdropper's task easier. 439 For example, a malicious node located between the MN and the CN 440 can start tracing its victim based on prior knowledge of one of 441 its home address or MAC address, and by tracking the BU messages 442 (e.g., the MN is using the RO mode). 443 After that, the malicious eavesdropper can correlate between 444 different signaling messages and possibly data packets to expand 445 his knowledge to other victim's home/MAC addresses. 446 Learning new identifiers offer the eavesdropper additional tools 447 to detect and track future movements. 449 3.4. The Interdependency Problem 451 The MAC and IP layers problems described above highlight another 452 concern that needs to be addressed in order to protect the MN's 453 identifiers and/or hiding its locations: any change/update of 454 the IP address and the pseudo-identifier must be performed in a 455 synchronized way. 457 Otherwise, a change/update at the IP layer only, may allow the 458 eavesdropper to keep tracing the MN via the device identifier 459 and consequently to learn how/when the MN's identifiers are 460 modified on the MAC layer, thus making such change(s) 461 meaningless. 463 4. Security Considerations 465 This document is a problem statement, which describes privacy 466 issues related to a mobile and multi-homed node, and does not 467 introduce security considerations by itself. 469 However it should be noted that any potential solution for 470 the momipriv problem, which allows using temporary device 471 identifiers, dynamic pseudo-IP addresses and other parameters 472 during an ongoing session should not allow a malicious 473 eavesdropper to learn how nor when these identifiers are 474 updated. 476 Any potential solution must protect against replaying messages 477 using old identifiers and/or hijacking an ongoing session 478 during an update of the identifiers. 480 Any potential solution should not allow exploiting any aspect 481 of privacy, in order to gain access to networks. 483 5. Acknowledgements 485 Many Thanks to Hannes Tschofenig for his review and comments on 486 the draft. 488 6. References 490 [ANON] A. Pfitzmann et al. "Anonymity, Unobservability, 491 Pseudonymity, and Identity Management - A Proposal 492 for Terminology", Draft v0.21, September, 2004. 494 [ANON-PRIV] M. Schmidt, "Subscriptionless Mobile Networking: 495 Anonymity and Privacy Aspects within Personal Area 496 Networks", IEEE WCNC 2002. 498 [Freedom] A.F. Westin, "Privacy and Freedom", Atheneum Press, 499 New York, USA, 1967. 501 [ISO99] ISO IS 15408, 1999, http://www.commoncriteria.org/. 503 [LOPRIPEC] A. Beresfold, F. Stajano, "Location Privacy in 504 Pervasive Computing", IEEE Pervasive Computing, 505 2(1):46-55, 2003 IEEE. 507 [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support 508 in IPv6", RFC 3775, June 2004. 510 [MULTI] N. Montavont, R. Wakikawa, T. Ernst, T. Noel, C. Ng, 511 "Analysis of Multihoming in Mobile IPv6", 512 draft-montavont-mobileip-multihoming-pb-statement-03, 513 January, 2005. 515 [PRIV-NG] A. Escudero-Pascual, "Privacy in the Next Generation 516 Internet", December 2002. 518 [PRIV-STAT] S. Deering, B. Hinden, "Statement on IPv6 Address 519 Privacy", http://playground.sun.com/pub/ipng/html/ 520 specs/ipv6-address-privacy.html November, 1999. 522 [Privacy] T. Narten, R. Draves, S. Krishnan, "Privacy 523 Extensions for Stateless Address Autoconfiguration 524 in IPv6", draft-ietf-ipv6-privacy-addrs-v2-02, 525 December, 2004. 527 [STAT] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless 528 Address Autoconfiguration", 529 draft-ietf-ipv6-rfc2462bis-07, December, 2004. 531 [WLAN-IID] M. Gruteser, D. Grunwald, "Enhancing Location 532 Privacy in Wireless LAN Through Disposable Interface 533 Identifiers: A Quantitative Analysis, September 534 2003", First ACM International Workshop on Wireless 535 Mobile Applications and Services on WLAN Hotspots, 536 September 2003. 538 6. Authors'Addresses 540 Wassim Haddad 541 Ericsson Research 542 8400, Decarie Blvd 543 Town of Mount Royal 544 Quebec H4P 2N2 545 Canada 547 Phone: +1 514 345 7900 548 E-Mail: Wassim.Haddad@ericsson.com 550 Erik Nordmark 551 Sun Microsystems, Inc. 552 17 Network Circle 553 Mountain View, CA 554 USA 556 Phone: +1 650 786 2921 557 Fax: +1 650 786 5896 558 E-Mail: Erik.Nordmark@sun.com 560 Francis Dupont 561 Point6 562 c/o GET/ENST Bretagne 563 Campus de Rennes 564 2, rue de la Chataigneraie 565 CS 17607 566 35576 Cesson-Sevigne Cedex 567 France 569 E-Mail: Francis.Dupont@enst-bretagne.fr 571 Marcelo Bagnulo 572 Universidad Carlos III de Madrid 573 Av. Universidad 30 574 Leganes, Madrid 28911 575 SPAIN 577 Phone: 34 91 6249500 578 E-Mail: Marcelo@it.uc3m.es 579 URI: http://www.it.uc3m.es/marcelo 581 Soohong Daniel Park 582 Samsung Electronics 583 Mobile Platform Laboratory, Samsung Electronics 584 416. Maetan-Dong, Yeongtong-Gu, Suwon 585 Korea 587 Phone: +81 31 200 4508 588 E-Mail: soohong.park@samsung.com 590 Basavaraj Patil 591 Nokia 592 6000 Connection Drive 593 Irving, TX 75039 594 USA 596 Phone: +1 972 894-6709 597 E-Mail: Basavaraj.Patil@nokia.com 599 Intellectual Property Statement 601 The IETF takes no position regarding the validity or scope of 602 any Intellectual Property Rights or other rights that might be 603 claimed to pertain to the implementation or use of the 604 technology described in this document or the extent to which any 605 license under such rights might or might not be available; nor 606 does it represent that it has made any independent effort to 607 identify any such rights. Information on the IETF's procedures 608 with respect to rights in IETF Documents can be found in BCP 78 609 and BCP 79. 611 Copies of IPR disclosures made to the IETF Secretariat and any 612 assurances of licenses to be made available, or the result of an 613 attempt made to obtain a general license or permission for the 614 use of such proprietary rights by implementers or users of this 615 specification can be obtained from the IETF on-line IPR 616 repository at http://www.ietf.org/ipr. 618 The IETF invites any interested party to bring to its attention 619 any copyrights, patents or patent applications, or other 620 proprietary rights that may cover technology that may be 621 required to implement this standard. Please address the 622 information to the IETF at ietf-ipr@ietf.org. 623 The IETF has been notified of intellectual property rights 624 claimed in regard to some or all of the specification contained 625 in this document. For more information consult the online list 626 of claimed rights. 628 Disclaimer of Validity 630 This document and the information contained herein are provided 631 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 632 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 633 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 634 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 635 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 636 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 637 FOR A PARTICULAR PURPOSE. 639 Copyright Statement 641 Copyright (C) The Internet Society (2004). This document is 642 subject to the rights, licenses and restrictions contained in 643 BCP 78, and except as set forth therein, the authors retain all 644 their rights.