Re: draft-bourbaki-6man-classless-ipv6-00

[Brian E Carpenter <[e-mail]>]

On 10/06/2017 06:25, [e-mail] wrote:
> 
>> On 9 Jun 2017, at 14:24, Fernando Gont <[e-mail]> wrote:
>>
>> On 06/09/2017 10:46 AM, [e-mail] wrote:
>>>
>>>> On 6 Jun 2017, at 00:25, Brian E Carpenter <[e-mail]> wrote:
>>>>
>>>> On 05/06/2017 19:45, Lorenzo Colitti wrote:
>>>>> On Mon, Jun 5, 2017 at 8:05 AM, Brian E Carpenter <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> None of that is the point. The point is to establish
>>>>>> that routing is classless
>>>>>
>>>>>
>>>>> Routing is already classless because BCP 198.
>>>>>
>>>>>
>>>>>> and /64 is a parameter of specific addressing schemes.
>>>>>>
>>>>>
>>>>> It *is* a parameter. The parameter's value is 64 for all unicast addresses
>>>>> except those starting with 000.
>>>>
>>>> The parameter's *current* value, yes. But should we really be fixing
>>>> the value of the parameter once and for all in the addressing architecture?
>>>> Why don't we fix it in each IPv6-over-foo, which is what the SLAAC design
>>>> assumes?
>>>
>>> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)?
>>
>> At the time of this writing, we should probably be in the camp of "If
>> you do slaac, better stick to 64, since it's know to work with legacy
>> implementations, and besides, allows for sparse allocation (reduced
>> collisions of IIDs when you pick a random one, resistance to address
>> scans, etc.).
>>
>> There's no compelling technical argument for mandating /64 (i.e., such
>> specific value) if you do manual configuration or, for instance,
>> stateful DHCPv6. And the recommendation for /64 for slaac mostly has to
>> do with backwards compatibility than with anything else.
> 
> your goal is to remove the 64 bit boundary from RFC2464 et al and update RFC4862?
> I intended the question for Brian, as he seemed to be of a different view.

It's hard to track this conversation, but anyway IMHO 2464bis should specify
/64 as if the addressing architecture didn't even mention it. It has
to specify something for SLAAC to work, and we have 20 years of deployed
code based on /64. So we don't have the luxury of changing it, even
if we want to.

I'm not aware of any technical changes needed in 4862. Jinmei-san has
convinced me off line that 4862 does logically require the IID length
for link-local addresses and global-scope SLAAC addresses to be the same.
I wish the text stated this explicitly, but that's an editorial issue.
Apart from that, it leaves the IID length as a parameter and that's
as it should be.

    Brian