Re: Last Call: <draft-ietf-6man-rfc4941bis-10.txt> (Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6) to Proposed Standard

[Alexandre Petrescu <[e-mail]>]

Le 13/09/2020 à 06:45, Fernando Gont a écrit :
> On 12/9/20 16:49, Alexandre Petrescu wrote:
>>
>>
>> Le 12/09/2020 à 07:36, Fernando Gont a écrit :
>>> On 10/9/20 08:35, Alexandre Petrescu wrote:
>>>>
>>>>
>>>> Le 10/09/2020 à 13:26, Lorenzo Colitti a écrit :
>>>>> Having read this document again, I have the following concerns.
>>>>>
>>>>> 1. I think it should not include section 3.3.2. The reason is that it
>>>>>  needlessly suggests an algorithm that is much more complex than
>>>>> simply using an existing random number generator which all nodes
>>>>> likely already have.
>>>>
>>>> I object to that I-D paragraph at least because it says this "SHOULD
>>>> produce an output of at least 64 bits."  It should be of a more 
>>>> variable
>>>> length.  It is not 'at least 64bit'.
>>>
>>> Huh?
>>>
>>> SLAAC IIDs are currently required to be 64-bit long, hence the output 
>>> should be of at least 64 bits -- if the output is 64-bits, you take 
>>> all of them, whereas if it's more that 64-bits, you discard the 
>>> exceeding bits.
>>
>> I agree that IPv6-over-foo IIDs part of SLAAC requires that to be 
>> 64bit long.
>>
>> And I maintain it is a wrong requirement.
>>
>> The requirement should be that is a variable length.  An IID of length 
>> 45 should work in SLAAC as much as an IID of length 72.  And 
>> incidentally 64, some times.
> 
> While I'd probably agree, this is not the I-D where such work should be 
> pursued.

Fair enough, the 64bit limit discussion is not the goal of this draft.

However, like all other drafts: they all claim that is not their 
problem, and they all continue with the limit.

If this draft keeps the text that is originally discussed (SHOULD 64bit) 
then this draft continues that trend.

So, if that 64bit limit were not its problem, then it would not state 
64bit.  It would be _neutral_ with respect to it.

>> Some implementations do work the way I say it (openbsd IID length 45 
>> or 72 works).  Some implementation is under development in linux to 
>> make that work too.  They are different implementations but achieve 
>> the same thing.
> 
> To be honest, I'm curious why one would want to use *even longer* IIDs 
> than /64.  (Shorter, for sure)
> 
> 
> 
>>
>>>> I do not oppose to the existence of that section 3.3.2.  But how would
>>>> it cope with other generated Interface Identifiers, like HIT (Host
>>>> Identity Tag) or ORCHIDs.  These are too RFCs on the Standards Track.
>>>> They too are generated by a crypto function, they too are 64bit length.
>>>>   Still they are different than this F().
>>>
>>> This is orthogonal to this document.
>>
>> Hmm... orthogonal, yes, but there could be an ideal goal that RFCs at 
>> IETF make sense all together, I think.  If HIP protocols considers 
>> always that IID must be 64, but other RFCs no, then there is obviously 
>> a need to try to make sense all together.
> 
> Doesn't HIP employ 64-bit IIDs?

yes it does.

> 
> 
> 
>> True, the task might seem huge, and so we call it orthogonal: it would 
>> be hard to climb a vertical :-)
> 
> What I'm saying is that relaxing the requirement of 64-bits for the IID 
> is out of the scope of this document.

I agree.  In that sense, it might be that the draft does not want to say 
64bit.

Alex

>