Re: "RFC4941bis" and draft-gont-6man-non-stable-iids

[Fernando Gont <[e-mail]>]

On 07/20/2017 11:21 AM, Suresh Krishnan wrote:
> Hi Tim,
> 
>> On Jul 19, 2017, at 6:00 PM, Tim Chown <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>> On 19 Jul 2017, at 13:57, Fernando Gont <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>> On 07/19/2017 01:58 PM, Tim Chown wrote:
>>>>> On 18 Jul 2017, at 15:52, Fernando Gont <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>> wrote:
>>>>>
>>>>> Folks,
>>>>>
>>>>> Among the list of RFCs to be progressed to full std is/was RFC4941 
>>>>> ("Privacy Extensions for Stateless Address Autoconfiguration in
>>>>> IPv6").
>>>>>
>>>>> As it stands, RFC4941 has a number of issues:
>>>>>
>>>>> * Using the same IID for multiple prefixes * Not changing the IID
>>>>> upon "security events" (including e.g., change in the underlying
>>>>> MAC address) * Using MD5 as opposed to something better * Requiring
>>>>> the use of temporary addresses along stable addresses (preventing
>>>>> use of temporary-only, for nodes that feel like) * Not treating
>>>>> IIDs as opaque values (see RFC7136)  when generating the randomized
>>>>> IIDs (see step 3 in section 3.2.1 of RFC4941) * Mandating one
>>>>> specific algorithm, when the same goals/properties can be achieved
>>>>> with multiple algorithms (see section 4 of 
>>>>> draft-gont-6man-non-stable-iids-01)
>>>>>
>>>>>
>>>>> Based on the above, I personally don't think that it would make
>>>>> sense to progress RFC4941 to Internet Standard, but rather think
>>>>> that we should work on  a replacement of it -- our proposal being 
>>>>> draft-gont-6man-non-stable-iids-01.
>>>>>
>>>>> Thoughts?
>>>>
>>>> Certainly any update on 4941 needs to be done in the light of a few
>>>> deficiencies that have emerged over the years, and the publication of
>>>> RFC7217.
>>>>
>>>> I think it’s still possible to do a -bis off 4941.
>>>
>>> My questions would be:
>>>
>>> 1) Can you actually address the aforementioned deficiencies without
>>> significant changes to RFC4941? -- It would seem to me that in order to
>>> address them, rfc4941bis would not be a bis document anymore.
>>>
>>> 2) If you were to address such deficiencies, could the bis document be
>>> progressed to Internet Standard? -- My assessment of this question
>>> is: No.
>>>
>>> If RFC4941 would take significant work, and the end result would
>>> actually be significantly different from what's in RFC4941, then I'm not
>>> sure that'd be different than starting from the I-D we already have...
>>
>> Just to be clear, I like the material in your new draft.
>>
>> That said, it seems you could do a similar style of update from 3041
>> to 4941, with a similar structure; the content is there in your draft,
>> it “just" needs to be merged in.
>>
>> That would mean obsoleting 4941, just as 4941 obsoleted 3041.  So you
>> would include the details in 4941 that would carry forward.
> 
> <AD hat off>. I agree. If we are planning a drop in replacement to
> RFC4941 creating a bis document from there is the right thing to do.

Can you explain your rationale? (along with answering the two questions
I posed to Tim).

RFC4941 can be summarized as consisting of two parts:

1) A discussion of privacy implications of Identifiers, and of IIDs in
particular

2) Specification of an algorithm to generate the IID


"1)" was much needed when RFC3041 was published, and then carried to
RFC4941 (when it was probably still needed). Nowadays, the security and
privacy properties of IPv6 addresses are discussed more thoroughly (and
in more dimensions) in RFC7721.  And the discussion of identifiers in
documents such as RFC6973 and draft-gont-predictable-numeric-ids
(besides the fact that one can always refer back to RFC3041 or even
RFC4941 for such discussion, in the same way we referenced RFC3041 in
RFC7721).

When it comes to "2)", if you really want to address the issues found in
RFC4941, essentially you need to replace the algorithm with something
else. One may tweak a few things here and there (e.g., the update we
propose in our I-D), but still there are drawbacks in RFC4941 that
cannot be addressed without fundamentally changing the algorithm (for
instance, RFC4941 has notable drawbacks when compared to simply
generating the IID as a random number that is not tied to previously
selected IIDs). If one were to do rfc4941bis, such document could not be
progressed to STD. And since there are better and/or alternative
approaches for generating temporary addresses, I'm not sure what would
be the benefit here.

Thanks!

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