Subject: Re: Node requirements: RFC3041 - Privacy Extensions for Address C onfiguration in IPv6

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Nov 2002 15:24:21 -0500

>   > Updating the node requirements and I came to this RFC.  
>   > This RFC raised a lot
>   > of discussion during the Cellular Hosts draft - I wonder 
>   > what the consensus
>   > is for the Node requirements.  This could be useful for 
>   > end-user hosts,

> => for _stationary_ end hosts.

Not sure why you say that. RFC 3041 specifically says:

2.3.  The Concern With IPv6 Addresses

   The division of IPv6 addresses into distinct topology and interface
   identifier portions raises an issue new to IPv6 in that a fixed
   portion of an IPv6 address (i.e., the interface identifier) can
   contain an identifier that remains constant even when the topology
   portion of an address changes (e.g., as the result of connecting to a
   different part of the Internet).  In IPv4, when an address changes,
   the entire address (including the local part of the address) usually
   changes.  It is this new issue that this document addresses.

   If addresses are generated from an interface identifier, a home
   user's address could contain an interface identifier that remains the
   same from one dialup session to the next, even if the rest of the
   address changes.  The way PPP is used today, however, PPP servers
   typically unilaterally inform the client what address they are to use
   (i.e., the client doesn't generate one on its own).  This practice,
   if continued in IPv6, would avoid the concerns that are the focus of
   this document.

   A more troubling case concerns mobile devices (e.g., laptops, PDAs,
   etc.) that move topologically within the Internet.  Whenever they
   move (in the absence of technology such as mobile IP [MOBILEIP]),
   they form new addresses for their current topological point of
   attachment.  This is typified today by the "road warrior" who has

Narten & Draves             Standards Track                     [Page 5]

RFC 3041      Extensions to IPv6 Address Autoconfiguration  January 2001

   Internet connectivity both at home and at the office.  While the
   node's address changes as it moves, however, the interface identifier
   contained within the address remains the same (when derived from an
   IEEE Identifier).  In such cases, the interface identifier can be
   used to track the movement and usage of a particular machine
   [SERIALNUM].  For example, a server that logs usage information
   together with a source addresses, is also recording the interface
   identifier since it is embedded within an address.  Consequently, any
   data-mining technique that correlates activity based on addresses
   could easily be extended to do the same using the interface
   identifier.  This is of particular concern with the expected
   proliferation of next-generation network-connected devices (e.g.,
   PDAs, cell phones, etc.) in which large numbers of devices are in
   practice associated with individual users (i.e., not shared).  Thus,
   the interface identifier embedded within an address could be used to
   track activities of an individual, even as they move topologically
   within the internet.

   In summary, IPv6 addresses on a given interface generated via
   Stateless Autoconfiguration contain the same interface identifier,
   regardless of where within the Internet the device connects.  This
   facilitates the tracking of individual devices (and thus potentially
   users).  The purpose of this document is to define mechanisms that
   eliminate this issue, in those situations where it is a concern.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 4 Nov 2002 20:59:07 +0100

> > => I took out the RFC text to make the mail shorter. 
  > > When I made that comment I meant to distinguish IPv6
  > > nodes from MNs based on whether they implement MIPv6
  > > MN functions or not. So when I said "stationary" I meant
  > > IPv6 nodes that do not implement MN functions as described
  > > in MIPv6.
  > 
  > OK, though choosing to call such nodes "stationary" isn't very
  > intuitive. My "stationary" laptop goes with me to lots of 
  > places, yet
  > would be a good example of where temporary addresses might well be
  > appropriate.

=> ok, my point was not related to physical mobility, but 
topological mobility. Of course, you're saying that topological 
mobility does not imply session continuity and consequently
does not imply MIPv6. 

  > > For those MNs, we do not yet have a mechanisms
  > > to allow for RFC3041 type home addresses. So there would be
  > > no point in having them for the CoA since the HoA is always
  > > visible for traffic analysis.
  > 
  > Specifically, I assume you mean that there is no way for an 
  > MN to use
  > temporary addresses because there is no way for the MN to 
  > tell the HA
  > what other addresses it is using?

=> Correct. There is no IETF _specified_ way for this yet. Of course
one can think of ways of solving this problem for some scenarios 
but there is nothing specified today. 

  > 
  > Also, how much of a problem is this perceived to be?

=> Which problem? The fact that the mobile node cannot 
generate 3041 home addresses? 
If so, it's a significant challenge. I can think of 
several ways of addressing this problem but they are not 
free and I don't think they solve this problem for 
all possible scenarios. 
For example (not an exhaustive analysis at all): 

- CGAs can fix this problem. However, frequently generating
PKs is computationally intensive. Also, HAs are likely to
need a higher level identifier for the MN in order to offer
their forwarding services. For instance, an ISP offering a HA
"service" to its MNs is likely to not want every other MN
to use its HA, when it hasn't paid for this service. 

- If a HA is configured with every possible "allocated"
HoA. It might be able to accept 3041 HoAs. By "allocated"
I mean that it is used to allow MNs to be reachable. But 
this idea will certainly need significant specification
work and cannot be generalised for all scenarios. For example, 
how does a HA know if a MN has updated the DNS with its 
new 3041 HoA? What happens when the MN stops using 
that address? What happens if the MN goes out of coverage
for a period where the binding times out and another one
takes that address? 

Perhaps with enough restrictions and changes to existing 
specs these problems could be solved, but they're not trivial. 

Hesham

---

From: [email-masked]
Date: Tue, 5 Nov 2002 06:47:23 +0200

Hello all,

With regards to 3041, the Node Requirements have a MAY requirement.
We should add text, to better capture this, though.  Mobile Nodes,
Servers, etc. may have different requirements, but how to quantify
this?  So, I'd respectfully ask someone to submit text to cover
this.

John