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

[Fernando Gont <[e-mail]>]

On 07/20/2017 02:34 PM, Tim Chown wrote:
>> On 20 Jul 2017, at 12:03, Fernando Gont <[e-mail]> wrote:
>>
>> 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.
> 
> But the structure of your document is exactly the same as 3041 and 4941:
> 
> 3.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   3
> 4.  Generation of Temporary IPv6 Addresses  . . . . . . . . . . .   6 
> 5.  Update to existing RFCs . . . . . . . . . . . . . . . . . . .   8
> 
> Basically, it's “the problem” and “generating temporary addresses”.
> 
> I think we are discussing two things that are actually quite similar in structure.

Just trying to get a clear picture in my head: Does the discussion boil
down to renaming "draft-gont-6man-non-stable-iids" to
"draft-gont-6man-rfc4941bis"?

My mental model is that a bis document essentially incorporates errata
and minor changes to a previous RFC. But this doesn't seem whre we want
to go here.

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