Subject: [v6ops] I-D: draft-rafiee-v6ops-iid-lifetime-00.txt

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 22 Oct 2013 01:23:16 +0200

We submitted a new draft which compares the current mechanisms to maintain the lifetime of IIDs and then introduces a framework to enable applications maintaining their privacy by making it difficult to correlate a user's activities by using different IIDs for different applications, without negatively impacting the robustness of the applications.

We're looking forward to receiving your comments.

Filename:	 draft-rafiee-v6ops-iid-lifetime
Revision:	 00
Title:		 Interface ID lifetime Algorithms
Creation date:	 2013-10-21
Group:		 Individual Submission
Number of pages: 11
URL:             http://www.ietf.org/internet-drafts/draft-rafiee-v6ops-iid-lifetime-00.txt
Status:          http://datatracker.ietf.org/doc/draft-rafiee-v6ops-iid-lifetime
Htmlized:        http://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime-00

Abstract:
   This document introduces a framework, i.e., an application layer
   based lifetime [applicationiid] to enable applications maintaining
   their users' privacy as well as controlling the number of Interface
   IDs (IIDs) per network adapter. It will also explain different
   approaches that can be used for maintaining the lifetime of an IID.
   We also compare this framework to the other available mechanisms.
   This document also explains when to remove deprecated IP addresses
   from the a network interface.

-----------smile----------
Hosnieh
… success is a journey, not a destination….
You cannot change your destination overnight, but you can change your direction ... Focus on the journey

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 23 Oct 2013 05:52:50 +0000

</chair>

This, along with RFC 4941's observation that there may be utility in an IID that is not tied to hardware identifiers, would appear consistent with the thought and recommendations of 

https://tools.ietf.org/html/rfc1498
1498 On the Naming and Binding of Network Destinations. J. Saltzer.
     August 1993. (Format: TXT=24698 bytes) (Status: INFORMATIONAL)

and the definition of an Endpoint ID in 

https://tools.ietf.org/html/rfc1992
1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M.
     Steenstrup. August 1996. (Format: TXT=59848 bytes) (Status:
     INFORMATIONAL)

The latter is the origin of the question of a locator/id split; a locator identifies the location of a network point of attachment, and an identifier in essence identifies what we might call a "socket". Imagine - although I can't say I know *why* someone would want to do this <sarcasm> - one wanted to move an application from one physical or virtual machine to another. If the identifier could move with the application, that would simplify such motion.

Note that the NIMROD architecture and Saltzer's document are not fundamentally about security. They are about scalable management of applications interconnected by a network and routing in that network.

On Oct 22, 2013, at 3:23 AM, Hosnieh Rafiee <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

If at first the idea is not absurd, then there is no hope for it.  
Albert Einstein