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

[Fernando Gont <[e-mail]>]

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.



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



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

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