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

[Tim Chown <[e-mail]>]

> On 20 Jul 2017, at 12:58, Fernando Gont <[e-mail]> wrote:
> 
> 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.

I think the purpose and spirit are very similar though, just with a few years of extra experience.

One of the RFC4941 authors is explicitly copied above; have a chat :)

(That’s what I did for example with 6724 and 6434-bis)

Tim