Dear All,
Since Fernando's proposal is not going to solve the current problem with RFC
4941, I have suggested to him, on several occasions, that he resolve this
problem so that the node's privacy will be better protected but he ignored
this suggestion and claiming that his purpose is different. This is the main
reason that today I wrote an RFC draft which I will submit to the IETF
repository. This draft does not overlap Fernando's proposal it is related
to the problems with this RFC (RFC 4941) which he doesn't feel the need to
address. The problems that I address here concern the fact that the node
should also change its IID when it receives different router prefixes.
In the experimental results, Windows machine that implemented privacy
extension RFC, generates different IIDs by rebooting .But when it receives a
different prefix without a reboot, then, on the first two occasions that the
new prefixes received, the node was generated a new IID, but not for other
new prefix generations. Also, as you can see, the temporary addresses have
the same IID. This means that there is a need to change section 8 of this
RFC
6. The node is now allowed to generate different interface
identifiers for different prefixes, if it so desires.
Where a different IID should be generated when a different prefix is
received. I called it "RA-based privacy extension for SLAAC".
Physical Address. . . . . . . . . : 00-0C-29-FA-38-32
IPv6 Address. . . . . . . . . . . :
2000:abc:ab:0:3003:bfe7:125a:5c0(Preferre
d)
IPv6 Address. . . . . . . . . . . :
2000:abc:bad:bad:3003:bfe7:125a:5c0(Prefe
rred)
Temporary IPv6 Address. . . . . . :
2000:abc:ab:0:5d60:2136:554:188b(Preferre
d)
Temporary IPv6 Address. . . . . . :
2000:abc:bad:bad:5d60:2136:554:188b(Prefe
rred)
Temporary IPv6 Address. . . . . . :
2000:bad:bad:bad:5d60:2136:554:188b(Prefe
rred)
Lifetime of the addresses as long as the computer is on
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Public Preferred 3314d21m1s 779d18h22m24s
2000:abc:ab:0:3003:bfe7:125a:5c0
Temporary Preferred 6d23h51m4s 6d23h51m4s
2000:abc:ab:0:5d60:2136:554:188b
Public Preferred 3314d16m15s 779d18h17m38s
2000:abc:bad:bad:3003:bfe7:125a:
5c0
Temporary Preferred 6d23h50m22s 23h50m22s
2000:abc:bad:bad:5d60:2136:554:188b
Public Preferred 3314d21m13s 779d18h22m36s
2000:aed:ab:0:3003:bfe7:125a:5c0
Temporary Preferred 6d23h55m20s 23h55m20s
2000:aed:ab:0:5d60:2136:554:188b
Public Preferred 3314d15m26s 779d18h16m49s
2000:bad:bad:bad:3003:bfe7:125a:
5c0
Temporary Preferred 6d23h49m13s 6d23h49m13s
2000:bad:bad:bad:5d60:2136:554:188
b
A second problem that I found with that RFC is the second approach used to
generate the IID. In section 3.2.2 it describes a more randomized IID
generation approach by using CGA, but it does not explain how to use this
algorithm when security is not a consideration. In my extension, I also
explain how to use that algorithm if we do not wish to consider security as
a part of CGA. Of course, I derived that section from my last draft , SSAS,
and will remove that section from SSAS. I would prefer that the SSAS
algorithm focus more on security and then focus on privacy.
Best,
Hosnieh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
