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

[Tim Chown <[e-mail]>]

> 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.

Tim