Subject: solution to RFC 4941 I-D action : draft-rafiee-6man-ra-privacy.txt

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 14 May 2013 22:37:22 +0200

Hello,

A new version of http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy is
available online. I considered the comments that I received and made the
pertinent changes to this version. I also improved the document to better
address the following issues that I have with RFC 4941.
1- lifetime of the IID  
The fact that the node might not generate a new IID when it receives a new
subnet prefix
Solution: Give the router prefix a higher priority than the IID's max
lifetime
2- Nodes may use an IID that was generated based on a MAC address and use
this in their response
A MAC based IID may still be valid and this RFC does not force the node to
stop using it.
 Solution: The node MUST not generate its IID based on a MAC address when
using this approach. The Privacy Extension RFC does not clearly address
this.
3- A better way to handle trouble shooting and debugging 
4-The need to maintain the status of reserved IIDs and already used IIDs
requiring  a large storage space and the fact that the randomization of IIDs
is limited.
Solution: Using modified CGA algorithm skipping the security steps
5-The cutting of connections when the max lifetime for the IID expires

I would be appreciative if you could find the time to review this draft RFC
and offer constructive comments.

Thanks,
Best,
Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 May 2013 14:34:07 +0200

> using this approach. The Privacy Extension RFC does not clearly address

So I assume that you also require such IID to vary across networks, right?

If not, it would be pretty ironic (*) that you make the effort of
clarifying that the IID of temporary addresses should change when you
move from one network to another, but then allow the stable IID to
remain constant across networks.

(*) unless we just want to rubberstamp what Microsoft has implemented
(stable addresses with IIDs that are constant across networks), and
pretend that that's the right thing to do

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492