< draft-haddad-momipriv-problem-statement-00.txt   draft-haddad-momipriv-problem-statement-01.txt >
Internet Engineering Task Force Wassim Haddad Internet Engineering Task Force Wassim Haddad
Mobility and Multi-homing Privacy Ericsson Mobility and Multi-homing Privacy Ericsson
Internet Draft Erik Nordmark Internet Draft Erik Nordmark
Expires March 2005 Sun Microsystems Expires July 2005 Sun Microsystems
Francis Dupont Francis Dupont
GET/ENST Bretagne Point6
Marcelo Bagnulo Marcelo Bagnulo
UC3M UC3M
Soohong Daniel Park Soohong Daniel Park
Samsung Electronics Samsung Electronics
Basavaraj Patil Basavaraj Patil
Nokia Nokia
October 2004 February 2005
Privacy for Mobile and Multi-homed Nodes: Privacy for Mobile and Multi-homed Nodes:
MoMiPriv Problem Statement MoMiPriv Problem Statement
<draft-haddad-momipriv-problem-statement-01>
<draft-haddad-momipriv-problem-statement-00>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware disclosed, or will be disclosed, and any of which I become aware
will be disclosed, in accordance with RFC 3668. will be disclosed, in accordance with RFC 3668.
This document is an Internet Draft and is in full conformance with This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
skipping to change at page 1, line 43 skipping to change at page 1, line 42
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as Drafts as reference material or to cite them other than as
"work in progress." "work in progress."
The list of current Internet Drafts can be accessed at The list of current Internet Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited Distribution of this memo is unlimited
Abstract Abstract
This memo describes the privacy in mobility and multi-homing This memo describes the privacy in mobility and multi-homing
problem statement. problem statement.
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction................................................2
2. Glossary....................................................3 2. Glossary....................................................3
3. Problem Statement...........................................6 3. Problem Statement...........................................6
3.1. The MAC Layer Problem..................................6 3.1. Location Privacy vs. Privacy...........................6
3.2. The IP Layer Problem...................................8 3.2. The MAC Layer Problem..................................8
3.3. The Interdependency Problem............................9 3.3. The IP Layer Problem...................................9
4. Security Considerations....................................10 3.4. The Interdependency Problem...........................11
5. References.................................................10 4. Security Considerations....................................11
6. Authors' Addresses.........................................11 5. Acknowledgments............................................11
Intellectual Property Statement...............................13 6. References.................................................12
Disclaimer of Validity........................................13 7. Authors' Addresses.........................................13
Copyright Statement...........................................13 Intellectual Property Statement...............................15
Disclaimer of Validity........................................15
Copyright Statement...........................................15
1. Introduction 1. Introduction
In the near future, the mobility and multi-homing features will In the near future, mobility and multi-homing functionalities
coexist in the majority of small devices, e.g., terminals, PDAs, will coexist in the majority of end hosts, such as terminals,
etc. In order to enable these features, Mobile IPv6 [MIPv6] PDAs, etc. For this purpose, Mobile IPv6 [MIPv6] protocol has
protocol has already been designed to solve the mobility issues, been designed to provide a solution for the mobility at the
while addressing the multi-homing issues is still an ongoing network layer while Multi-homing is still an ongoing work.
work.
However, MIPv6 protocol does not provide any mean/support to MIPv6 does not provide any mechanism to protect the mobile
protect the mobile node's privacy when moving across the node's privacy when moving across the Internet, while in the
internet, while in the multi-homing area, the privacy may well multi-homing area, the privacy may well be supported in any
be supported in any potential solution but may probably lack potential solution but may probably lack some features. This is
some features. This is mainly due to the fact that the privacy mainly due to the fact that the privacy issues are not limited
issues are not limited to the IP layer only. to the IP layer only.
This memo describes the privacy in mobility and multi-homing This memo describes the privacy in mobility and multi-homing
(momipriv) problem statement based on IPv6 only. (momipriv) problem statement based on IPv6 only.
2. Glossary 2. Glossary
Anonymity Anonymity
Anonymity is a property of network security. An entity "A" Anonymity is a property of network security. An entity "A"
in a system has anonymity if no other entity can identify in a system has anonymity if no other entity can identify
skipping to change at page 4, line 39 skipping to change at page 4, line 39
Consequently, neither the mobile node nor its system Consequently, neither the mobile node nor its system
software shall support the creation of user-related usage software shall support the creation of user-related usage
profiles. Such profiles basically comprise of a correlation profiles. Such profiles basically comprise of a correlation
of time and location of the node's use, as well as the type of time and location of the node's use, as well as the type
and details of the transaction performed. and details of the transaction performed.
Privacy can even be achieved by disconnectivity, i.e., not Privacy can even be achieved by disconnectivity, i.e., not
being connected to a network. being connected to a network.
Location Privacy
Location Privacy means the capability of a mobile node to
conceal the relation between its location and the personal
identifiable information from third parties.
MAC Address MAC Address
A MAC Address is a 48 bits unique value associated with a A MAC Address is a 48 bits unique value associated with a
network adapter. The MAC address uniqueness is by default network adapter. The MAC address uniqueness is by default
global. A MAC Address is also known as the device/hardware global. A MAC Address is also known as the device/hardware
identifier. identifier.
Link Link
A communication facility or medium over which nodes can A communication facility or medium over which nodes can
skipping to change at page 6, line 7 skipping to change at page 6, line 7
A system used to interconnect a set of basic service sets A system used to interconnect a set of basic service sets
(BSSs) and integrated local area networks (LANs) to create (BSSs) and integrated local area networks (LANs) to create
an extended service set (ESS). an extended service set (ESS).
For more literature about the Glossary content, please refer to For more literature about the Glossary content, please refer to
[ANON], [ISO99], [Priv-NG], [Freedom] and [ANON-PRIV]. [ANON], [ISO99], [Priv-NG], [Freedom] and [ANON-PRIV].
3. Problem Statement 3. Problem Statement
There are two main reasons for writing this document. First, The growing ability to trace a mobile node by an untrusted
the growing ability to trace a mobile node by an untrusted
third party, especially in public access networks, is a direct third party, especially in public access networks, is a direct
and serious violation of the mobile user's privacy and can and serious violation of the mobile user's privacy and can
cause serious damage to its personal, social and professional cause serious damage to its personal, social and professional
life. The second reason is the fact that the privacy problem life. Privacy becomes a real concern especially when the mobile
is not limited to one layer only and should not be solved node (MN) uses permanent device and/or network identifiers.
independantly on one layer. Unfortunately, the privacy problem is not limited to a single
layer and should not be solved independantly on one layer.
As it appeared in the above, privacy is a more general term
than anonymity/pseudonymity. Privacy becomes a real concern
especially when the mobile node (MN) uses permanent device
and/or network identifiers.
However, in many scenarios, protecting the user's privacy can Protecting the user's privacy can be achieved, in many
be achieved by providing one or many of the privacy aspects scenarios, by providing one or many of the privacy aspects
defined above with regards to the mobile node's requirements defined above with regards to the mobile node's requirements
and/or location. and/or location. For this purpose, we try in the rest of this
For this purpose, we try in the rest of this document to use document to use the terms defined above, in order to highlight
the terms defined above, in order to highlight the issues in a the issues in a more precise way.
more precise way.
It should be noted that this document focus on the privacy It should be noted that this document focuses only on the
problem for a mobile and multi-homed node only and does not privacy problem for a mobile and multi-homed node only and does
make any assumption regarding the privacy of static node, not make any assumption regarding the privacy of a static node,
e.g., static correspondent node (CN). In addition, this e.g., static correspondent node (CN). In addition, this
document assumes that the real IPv6 address is not hidden by document assumes that the real IPv6 address is not hidden by
default, i.e., any node is always reachable via its real IPv6 default, i.e., any node is always reachable via its real IPv6
address. address.
The problem statement can be divided into three problems. The The problem statement is divided into three problems. The first
first two problems are related to the identifiers associated two problems are related to the identifiers associated with a
with a mobile device, i.e., the MAC address and the IP address, mobile device, i.e., the MAC address and the IP address, and the
and the third problem highlights their interdependency. third problem highlights their interdependency. But before
delving into these problems, a quick overview on differences
between location privacy and privacy is provided.
3.1 The MAC Layer Problem 3.1. Location Privacy vs. Privacy
Before describing privacy problems related to the IP and the
link layer, it seems useful to highlight the differences between
the location privacy and privacy, in order to avoid a possible
confusion later.
Location privacy is the ability to prevent other parties from
learning one's current or past location [LOPRIPEC]. In order
to get such ability, the mobile node must conceal any relation
between its location and the personal identifiable information.
Note that in the momipriv context, the mobile node location
refers normally to the topological location and not the
geographic one. The latter is provided by other means (e.g.,
GPS) than an IPv6 address. But it should be noted that it may
possible sometimes to deduce the geographical location from
the topological one.
However, concealing any relation between the location and the
user's identifier(s) does not guarantee that the identifier(s)
itself will not be disclosed, since it may be possible to hide
the real location alone. But, having at least one user's
identifier disclosed may be enough (e.g., if coupled with prior
knowledge about few possible whereabouts) for other party to
discover the user's current and/or previous location(s).
For example, in a context limited to IP and MAC layers, the
only available identifiers and/or locators are the IP and MAC
addresses, and only the IP address carries information, which
can directly disclose the MN's location (note that mobile IPv6
discloses both the mobile node's home and current locations).
The MAC address alone does not provide any hint regarding the
mobile node current/previous location. But if the other party
has already established the link between the target and its
MAC address and gained knowledge about some of the user's
possible current/future whereabouts, then it will be possible
to locate and even track the target.
On the other side, it should be noted that the two main
privacy aspects, i.e., anonymity and pseudonymity, provide
implicitly the location privacy feature by concealing the
real user's identifiers regardless of his/her location(s).
Actually, in both privacy aspects, real identifiers are
replaced by static or dynamic ones, thus making the other
party no more able to identify its target even at the
correct location, i.e., any past/current location
information becomes practically useless for locating and
tracking purposes.
3.2. The MAC Layer Problem
The first problem focus on the MAC layer and is raising growing The first problem focus on the MAC layer and is raising growing
concerns related to the user's privacy, especially with the concerns related to the user's privacy, especially with the
massive ongoing indoor/outdoor deployment of WLAN technologies. massive ongoing indoor/outdoor deployment of WLAN technologies.
A mobile device attached to a particular link is uniquely A mobile device attached to a particular link is uniquely
identified on that link by its MAC address, i.e., the device identified on that link by its MAC address, i.e., the device
identifier. In addition, the device identifier is disclosed in identifier. In addition, the device identifier is disclosed in
any packet sent by/to the MN when it reaches that particular any packet sent by/to the MN when it reaches that particular
link, thus making it a very efficient tool to trace a mobile link, thus making it a very efficient tool to trace a mobile
user in a shared wireless medium access. Similar problems have user in a shared wireless medium access. Similar problems have
caused bad press for cellular operators. caused bad press for cellular operators.
For example, an eavesdropper located in one distributed system For example, a malicious node located in one distributed system
(DS) can trace a mobile node via its device identifier while (DS) can trace a mobile node via its device identifier while
moving in the entire ESS, and learn enough information about moving in the entire ESS, and learn enough information about
the user's activities and whereabouts. Having these information the user's activities and whereabouts. Having these information
available in the wrong hands, especially with the exact time available in the wrong hands, especially with the exact time
when they occur, may have bad consequences on the user. when they occur, may have bad consequences on the user.
Another concern on the MAC layer, which can also be exploited Another concern on the MAC layer, which can also be exploited
by an eavesdropper to trace its victim is the sequence number by an eavesdropper to trace its victim, is the sequence number
carried by the frame header. The sequence number is incremented carried by the frame header. The sequence number is incremented
by 1 for each data frame and allows the bad guy to trace its by 1 for each data frame and allows the bad guy to trace its
targeted node, in addition to the MAC address. targeted node, in addition to the MAC address.
In addition, the sequence number allows also the malicious node In addition, the sequence number allows also the malicious node
to keep tracing the MN, if/when the real MAC address is replaced to keep tracing the MN, if/when the real MAC address is replaced
by one or many pseudo-identifier(s) during an ongoing session by one or many pseudo-identifier(s) during an ongoing session
[WLAN-IID]. [WLAN-IID].
However, it should be noted that even if the real MN's device In addition, it should be noted that even if the real MN's device
identifier remains undisclosed during all the session(s), it may identifier remains undisclosed during all the session(s), it may
probably not be enough to provide the unlinkability protection probably not be enough to provide the unlinkability protection
on the MAC layer, between ongoing session(s). on the MAC layer, between ongoing session(s).
Actually, if the MN's MAC address is replaced with a static Actually, in a scenario, where the malicious node is located on
pseudo-identifier, i.e., to provide pseudonymity, or with the link or in the distributed system, replacing the real MAC
temporary ones, i.e., to provide anonymity, the unlinkability address with a static pseudo-identifier, i.e., to provide
protection on the MAC layer can be easily broken if the MN's pseudonymity, or with temporary ones, i.e., to provide anonymity,
IPv6 address remains unchanged. it will always be possible to break the unlinkability protection
provided by the MAC layer if the MN's IPv6 address remains
unchanged.
Note that in such scenario, even a periodical change of the Note that in such scenario, even a periodical change of the
sequence number won't prevent the eavesdropper from correlating sequence number won't prevent the eavesdropper from correlating
ongoing session(s), pseudo-identifiers and the mobile node. ongoing session(s), pseudo-identifiers and the mobile node.
However, it should be mentioned that replacing the real device However, it should be mentioned that replacing the real device
identifier with static/dynamic pseudo-identifiers, in order to identifier with static/dynamic pseudo-identifiers, in order to
provide anonymity/pseudonymity, during an ongoing session(s), provide anonymity/pseudonymity, during an ongoing session(s),
raises another critical issue on the MAC layer level, which raises another critical issue on the MAC layer level, which
concerns the uniqueness of these new pseudo-identifier(s). concerns the uniqueness of these new pseudo-identifier(s).
Note that any temporary identifiers MUST be unique within the In fact, any temporary/static identifiers MUST be unique within
Extended Service Set (ESS) and the distributed system (DS). the Extended Service Set (ESS) and the distributed system (DS).
3.2 The IP Layer Problem 3.3. The IP Layer Problem
The second problem focus on the IP layer and analyzes the The second problem focus on the IP layer and analyzes the
privacy problems related to IPv6 only. privacy problems related to IPv6 only.
A MN can configure its IPv6 address either from a DHCP server A MN can configure its IPv6 address either from a DHCP server
or by itself. The latter scenario is called the stateless or by itself. The latter scenario is called the stateless
address autoconfiguration [STAT], and discloses the MN MAC address autoconfiguration [STAT], and discloses the MN MAC
address in the IPv6 address, thus enabling an eavesdropper to address in the IPv6 address, thus enabling an eavesdropper to
easily learn both addresses in this case. easily learn both addresses in this case.
In order to mitigate the privacy concerns raised, from using In order to mitigate the privacy concerns raised from using
the stateless address auto-configuration [PRIV-STAT], [PRIVACY] the stateless address auto-configuration [PRIV-STAT], [PRIVACY]
introduced a method allowing to periodically change the MN's introduced a method allowing to periodically change the MN's
interface identifier. interface identifier.
However, being limited to the interface identifier only, such However, being limited to the interface identifier only, such
change discloses the real network identifier, which in turn can change discloses the real network identifier, which in turn can
reveal enough information about the user or can even be the reveal enough information about the topological location, the
exact piece of information needed by the eavesdropper. user or can even be the exact piece of information needed by the
Another limitation to its efficiency lays in the fact that such eavesdropper. Another limitation to its efficiency lays in the
change cannot occur during an ongoing session. fact that such change cannot occur during an ongoing session.
Note that while using only a different IPv6 address for each While using only a different IPv6 address for each new session
new session may prevent/mitigate the ability to trace a MN on may prevent/mitigate the ability to trace a MN on the IP layer
the IP layer level, it remains always possible to trace it level, it remains always possible to trace it through its device
through its device identifier(s) on the MAC layer level and identifier(s) on the MAC layer level, i.e., when a malicious node
consequently, to learn all IPv6 addresses used by the MN by (or another one) is also attached to the same link/DS than its
correlating different sessions, thus breaking any unlinkability target. Consequently, it will be possible to learn all IPv6
protection provided at the IP layer. addresses used by the MN by correlating different sessions, thus
breaking any unlinkability protection provided at the IP layer.
MIPv6 allows an MN to move across the internet while ensuring MIPv6 allows an MN to move across the Internet while ensuring
optimal routing (i.e., by using route optimization (RO)) mode optimal routing (i.e., by using route optimization (RO)) mode
and keeping ongoing session(s) alive. Although these two and keeping ongoing session(s) alive. Although these two
features make the RO mode protocol looks efficient, they features make the RO mode protocol looks efficient, they
disclose the MN's home IPv6 address and its current location, disclose the MN's home IPv6 address and its current location,
i.e., care-of address (CoA) in each data packet exchanged i.e., care-of address (CoA), in each data packet exchanged
between the MN and the correspondent node (CN). between the MN and the correspondent node (CN).
Furthermore, each time a MN switches to a new network, it has Furthermore, each time a MN switches to a new network, it has
to send in clear a binding update (BU) message to the CN to to send in clear a binding update (BU) message to the CN to
notify it about its new location. notify it about its new location.
Consequently, a malicious node located between the MN and the Consequently, MIPv6 RO mode discloses to a malicious node
CN is able to identify any packet sent/received by the MN and located between the MN and the CN, all data required to
trace its movements at any time and any place once it moves identify, locate and trace in real time its mobile target,
outside its home network(s) [Priv-NG]. once it moves outside its home network(s) [Priv-NG].
MIPv6 defines another mode called the bidirectional tunneling MIPv6 defines another mode called the bidirectional tunneling
(BT), which allows the MN to hide its movements and locations (BT), which allows the MN to hide its movements and locations
from the CN by sending all data packets through its HA (i.e., from the CN by sending all data packets through its HA (i.e.,
encapsulated). In such mode, the CN uses only the MN's home encapsulated). In such mode, the CN uses only the MN's home
IPv6 address to communicate with the MN. IPv6 address to communicate with the MN.
Note that if the CN initiates a session with a MN then it has But if the CN initiates a session with a MN then it has to use
to use the MN's home IPv6 address. In such scenario, if the MN the MN's home IPv6 address. In such scenario, if the MN wants
wants to keep its movements hidden from the CN, then it has to to keep its movements hidden from the CN, then it has to switch
switch to the bidirectional tunneling mode. to the bidirectional tunneling mode.
Consequently, all data packets sent/received by the MN are Consequently, all data packets sent/received by the MN are
exchanged through the MN's HA and the MN needs to update only exchanged through the MN's HA and the MN needs to update only
its HA with its location. its HA with its location.
Although, the BT mode allows hiding the MN's location to the Although, the bi-directional tunneling mode allows hiding the
CN, it can disclose its real identity and current location to MN's care-of address to the CN, it can disclose its real
an eavesdropper located between the HA and the MN (e.g., by identity, i.e., IPv6 home address, and current location to a
looking to the data packets inner header). malicious node located between the HA and the MN (e.g., by
looking to the data packets inner header), unless the HA-MN
tunnel is protected by using ESP.
In addition to mobility, the multi-homing feature allows a In addition to mobility, the multi-homing feature allows a
mobile node to belong to different home networks and to switch mobile node to belong to different home networks and to switch
between these home networks without interrupting ongoing between these home networks without interrupting ongoing
session(s) [MULTI]. session(s) [MULTI].
Although multi-homing can be considered as another aspect of Although multi-homing can be considered as another aspect of
mobility, switching between different home networks, in addition mobility, switching between different home networks, in addition
to moving between foreign networks, can disclose to a malicious to moving between foreign networks, can disclose to a malicious
node well located between the multi-homed MN and the CN, part or node well located between the multi-homed MN and the CN, part or
skipping to change at page 9, line 45 skipping to change at page 11, line 8
For example, a malicious node located between the MN and the CN For example, a malicious node located between the MN and the CN
can start tracing its victim based on prior knowledge of one of can start tracing its victim based on prior knowledge of one of
its home address or MAC address, and by tracking the BU messages its home address or MAC address, and by tracking the BU messages
(e.g., the MN is using the RO mode). (e.g., the MN is using the RO mode).
After that, the malicious eavesdropper can correlate between After that, the malicious eavesdropper can correlate between
different signaling messages and possibly data packets to expand different signaling messages and possibly data packets to expand
his knowledge to other victim's home/MAC addresses. his knowledge to other victim's home/MAC addresses.
Learning new identifiers offer the eavesdropper additional tools Learning new identifiers offer the eavesdropper additional tools
to detect and track future movements. to detect and track future movements.
3.3 The Interdependency Problem 3.4. The Interdependency Problem
The MAC and IP layers problems described above highlight another The MAC and IP layers problems described above highlight another
concern that needs to be addressed in order to protect the MN's concern that needs to be addressed in order to protect the MN's
identifiers and/or hiding its locations: any change/update of identifiers and/or hiding its locations: any change/update of
the IP address and the pseudo-identifier must be performed in a the IP address and the pseudo-identifier must be performed in a
synchronized way. synchronized way.
Otherwise, a change/update at the IP layer only, may allow the Otherwise, a change/update at the IP layer only, may allow the
eavesdropper to keep tracing the MN via the device identifier eavesdropper to keep tracing the MN via the device identifier
and consequently to learn how/when the MN's identifiers are and consequently to learn how/when the MN's identifiers are
modified on the MAC layer, thus making such change(s) modified on the MAC layer, thus making such change(s)
meaningless. meaningless.
4. Security Considerations 4. Security Considerations
Any potential solution for the momipriv problem, which allows This document is a problem statement, which describes privacy
using temporary device identifiers, dynamic pseudo-IP addresses issues related to a mobile and multi-homed node, and does not
and other parameters during an ongoing session should not allow introduce security considerations by itself.
a malicious eavesdropper to learn how nor when these identifiers
are updated. However it should be noted that any potential solution for
the momipriv problem, which allows using temporary device
identifiers, dynamic pseudo-IP addresses and other parameters
during an ongoing session should not allow a malicious
eavesdropper to learn how nor when these identifiers are
updated.
Any potential solution must protect against replaying messages Any potential solution must protect against replaying messages
using old identifiers and/or hijacking an ongoing session during using old identifiers and/or hijacking an ongoing session
an update of the identifiers. during an update of the identifiers.
Any potential solution should not allow exploiting any aspect of Any potential solution should not allow exploiting any aspect
privacy, in order to gain access to networks. of privacy, in order to gain access to networks.
5. References 5. Acknowledgements
Many Thanks to Hannes Tschofenig for his review and comments on
the draft.
6. References
[ANON] A. Pfitzmann et al. "Anonymity, Unobservability, [ANON] A. Pfitzmann et al. "Anonymity, Unobservability,
Pseudonymity, and Identity Management - A Proposal Pseudonymity, and Identity Management - A Proposal
for Terminology", Draft v0.21, September, 2004. for Terminology", Draft v0.21, September, 2004.
[ANON-PRIV] M. Schmidt, "Subscriptionless Mobile Networking: [ANON-PRIV] M. Schmidt, "Subscriptionless Mobile Networking:
Anonymity and Privacy Aspects within Personal Area Anonymity and Privacy Aspects within Personal Area
Networks", IEEE WCNC 2002. Networks", IEEE WCNC 2002.
[Freedom] A.F. Westin, "Privacy and Freedom", Atheneum Press, [Freedom] A.F. Westin, "Privacy and Freedom", Atheneum Press,
New York, USA, 1967. New York, USA, 1967.
[ISO99] ISO IS 15408, 1999, http://www.commoncriteria.org/. [ISO99] ISO IS 15408, 1999, http://www.commoncriteria.org/.
[LOPRIPEC] A. Beresfold, F. Stajano, "Location Privacy in
Pervasive Computing", IEEE Pervasive Computing,
2(1):46-55, 2003 IEEE.
[MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[MULTI] N. Montavont, R. Wakikawa, T. Ernst, T. Noel, C. Ng, [MULTI] N. Montavont, R. Wakikawa, T. Ernst, T. Noel, C. Ng,
"Analysis of Multihoming in Mobile IPv6", "Analysis of Multihoming in Mobile IPv6",
draft-montavont-mobileip-multihoming-pb-statement-01, draft-montavont-mobileip-multihoming-pb-statement-03,
July, 2004. January, 2005.
[PRIV-NG] A. Escudero-Pascual, "Privacy in the Next Generation [PRIV-NG] A. Escudero-Pascual, "Privacy in the Next Generation
Internet", December 2002. Internet", December 2002.
[PRIV-STAT] S. Deering, B. Hinden, "Statement on IPv6 Address [PRIV-STAT] S. Deering, B. Hinden, "Statement on IPv6 Address
Privacy", http://playground.sun.com/pub/ipng/html/ Privacy", http://playground.sun.com/pub/ipng/html/
specs/ipv6-address-privacy.html November, 1999. specs/ipv6-address-privacy.html November, 1999.
[Privacy] T. Narten, R. Draves, S. Krishnan, "Privacy [Privacy] T. Narten, R. Draves, S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration Extensions for Stateless Address Autoconfiguration
in IPv6", draft-ietf-ipv6-privacy-addrs-v2, in IPv6", draft-ietf-ipv6-privacy-addrs-v2-02,
September, 2004. December, 2004.
[STAT] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless [STAT] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", Address Autoconfiguration",
draft-ietf-ipv6-rfc2462bis-05, August 2004. draft-ietf-ipv6-rfc2462bis-07, December, 2004.
[WLAN-IID] M. Gruteser, D. Grunwald, "Enhancing Location [WLAN-IID] M. Gruteser, D. Grunwald, "Enhancing Location
Privacy in Wireless LAN Through Disposable Interface Privacy in Wireless LAN Through Disposable Interface
Identifiers: A Quantitative Analysis, September Identifiers: A Quantitative Analysis, September
2003", First ACM International Workshop on Wireless 2003", First ACM International Workshop on Wireless
Mobile Applications and Services on WLAN Hotspots, Mobile Applications and Services on WLAN Hotspots,
September 2003. September 2003.
6. Authors'Addresses 6. Authors'Addresses
skipping to change at page 11, line 49 skipping to change at page 13, line 44
Sun Microsystems, Inc. Sun Microsystems, Inc.
17 Network Circle 17 Network Circle
Mountain View, CA Mountain View, CA
USA USA
Phone: +1 650 786 2921 Phone: +1 650 786 2921
Fax: +1 650 786 5896 Fax: +1 650 786 5896
E-Mail: Erik.Nordmark@sun.com E-Mail: Erik.Nordmark@sun.com
Francis Dupont Francis Dupont
GET/ENST Bretagne Point6
c/o GET/ENST Bretagne
Campus de Rennes Campus de Rennes
2, rue de la Chataigneraie 2, rue de la Chataigneraie
CS 17607 CS 17607
35576 Cesson-Sevigne Cedex 35576 Cesson-Sevigne Cedex
France France
E-Mail: Francis.Dupont@enst-bretagne.fr E-Mail: Francis.Dupont@enst-bretagne.fr
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
 End of changes. 40 change blocks. 
111 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/