Re: Review of draft-ietf-6man-rfc4291bis-06

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

Regards
   Brian Carpenter



On 14/01/2017 08:44, Fernando Gont wrote:
> On 01/12/2017 10:55 PM, Brian E Carpenter wrote:
>> On 13/01/2017 13:50, Randy Bush wrote:
>>>> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception.
>>>> To be precise it says:
>>>>
>>>>    The de facto length of almost all IPv6 interface identifiers is
>>>>    therefore 64 bits.  The only documented exception is in [RFC6164],
>>>>    which standardizes 127-bit prefixes for point-to-point links between
>>>>    routers, among other things, to avoid a loop condition known as the
>>>>    ping-pong problem.
>>>>
>>>> I would suggest adding a similar exception statement in 4291bis.
>>>
>>> and then next year we will go through another draft and have another
>>> exception.  just get rid of classful addressing.  we went through this
>>> in the '90s.
>>
>> The problem is (and why we wrote 7421) is that stuff breaks with subnet
>> prefixes longer than 64, *except* for the point-to-point case covered
>> by 6164. Yes, I see the problem in enshrining this but I think we face
>> signifcant issues if we do otherwise.
>>
>> What we could conceivably say is that /64 is mandatory except for
>> links where SLAAC will never be used. (SLAAC itself is designed
>> to work with any reasonable length of IID, but again in practice it
>> only works with /64, because we need mix-and-match capability. So
>> although IID length is a parameter in the SLAAC design, it's a
>> parameter whose value needs to be fixed globally.)
> 
> Well, yes and no. With the traditional slaac (embed the mac address) it
> only works with 64-bit IIDs. With something like RFC7217 (grab as many
> bits as needed to for an IID), it could work.

Technically that's true, but you can't mix IID sizes on a given link
and expect it to work, so any legacy system will force the whole link
to use /64.

    Brian