On 03/05/2013 18:49, Ray Hunter wrote:
>
> Hosnieh Rafiee wrote:
>> Fernando,
>>
>> The purpose of your draft was not to obsolete or update RFC 4941 and you
>> wanted to have your approach as an optional approach in parallel with that
>> approach. So what is your problem with improving that document. It has
>> nothing to do with your proposal. The people can accept or reject yours. I
>> do not see any harmful behavior here as I also asked you 1000 times to
>> update that rfc instead of having something new or in between two RFCs.
>>
>> Hosnieh
>
> IMHO You are missing how the standards documents relate to each other.
>
> The base problem is that RFC4862 (IPv6 Stateless Address Autoconfiguration)
> uses an IID defined in RFC4291 (IP Version 6 Addressing Architecture)
> Appendix A.
>
> The fact that IID's are derived from EUI64 identifiers using a reversible
> transformation (RFC4291 Appendix A) means that the IID portion of an IPV6
> SLAAC address can be used to infer privacy information about living persons
> carrying a particular device.
>
> RFC4941 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6)
> attempted to plug that gap.
>
> RFC4941 did NOT directly update RFC4862 nor RFC4291: it was an optional
> extension to 4862. This update method was chosen so that RFC4941 was
> backwards compatible with existing implementations (goal #1 of 4941 Section
> 3). RFC4941 addresses outbound connections. But RFC4941 is an incomplete
> solution: nodes implementing RFC4941 still respond on the native SLAAC
> address generated by RFC4862.
>
>
> draft-ietf-6man-stable-privacy-addresses plugs that vestigial problem with
> nodes responding on RFC4862 SLAAC generated addresses, whether RFC4941 has
> been implemented or not.
>
>
> If draft-ietf-6man-stable-privacy-addresses updated RFC4941, it would miss
> out all implementations that did not implement (the optional) RFC4941, so
> those nodes would be left with a problem.
>
> If draft-ietf-6man-stable-privacy-addresses updated RFC4862, it would mean
> all existing implementations would have to be mandatorily updated. There's no
> need for this to guarantee interoperability, and it would clearly be
> undesirable to deprecate existing implementations (which is why RFC4941
> included goal #1).
>
> In the future there may even be better alternatives to RFC4941 and
> draft-ietf-6man-stable-privacy-addresses.
>
> IMHO These proposed solutions are all orthogonal, and are therefore best
> defined in independent standards (that use each other as normative
> references).
Exactly. I think that draft-ietf-6man-ug clarifies this to some extent,
as a side-effect of clarifying the U/G bits. Would it be useful to add
an extra sentence in that draft, simply stating that a number of
independent methods for forming an IID can exist?
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
