Re: RFC4291bis (historical sub-thread)

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

Comment at the very end:

On 08/08/2018 17:56, David Farmer wrote:
> On Wed, Aug 8, 2018 at 12:40 AM, Brian E Carpenter <
> [e-mail]> wrote:
> 
>> On 08/08/2018 15:47, David Farmer wrote:
>>> On Tue, Aug 7, 2018 at 6:39 PM, Brian E Carpenter <
>>> [e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Assuming that we adopt draft-farmer-6man-exceptions-64
>>>> for the standards track or BCP, I suggest that we should
>>>> also update draft-ietf-6man-rfc4291bis as proposed below,
>>>> and plan for the two documents to be published as RFCs
>>>> simultaneously:
>>>>
>>>> OLD:
>>>>    Interface Identifiers are 64 bit long except if the first three bits
>>>>    of the address are 000, or when the addresses are manually
>>>>    configured, or by exceptions defined in standards track documents.
>>>>    The rationale for using 64 bit Interface Identifiers can be found in
>>>>    [RFC7421].  An example of a standards track exception is [RFC6164]
>>>>    that standardises 127 bit prefixes on inter-router point-to-point
>>>>    links.
>>>>
>>>>       Note: In the case of manual configuration, the Prefix and
>>>>       Interface Identifier can be any length as long as they add up to
>>>>       128.
>>>>
>>>> NEW:
>>>>    Interface Identifiers for stateless address autoconfiguration
>>>>    are 64 bits long except if the first three bits
>>>>    of the address are 000, or when the addresses are manually
>>>>    configured, or by exceptions defined in standards track documents.
>>>>    The rationale for using 64 bit Interface Identifiers can be found in
>>>>    [RFC7421].  An example of a standards track exception is [RFC6164]
>>>>    that standardises 127 bit prefixes on inter-router point-to-point
>>>>    links. The relationship between prefix length and Interface
>> Identifier
>>>>    length is discussed in [I-D.farmer-6man-exceptions-64].
>>>>
>>>>       Note: In the case of manual configuration, the Prefix and
>>>>       Interface Identifier can be any length as long as they add up to
>>>>       128. In all cases, routing and forwarding processes must be
>>>>       designed to process prefixes of any length up to /128 [BCP198].
>>>>
>>>> Comments:
>>>>
>>>> 1. This change makes it clear that the 64-bit IID length is for SLAAC.
>>>> 2. It specifically send the reader to draft-farmer for details.
>>>> 3. It underlines that routing must work for any length prefix.
>>>>
>>>>     Brian
>>>>
>>>
>>> That works for me, but I've been thinking "Standard Interface Identifiers
>>> are 64 bit long..." and when refing to 64-bit IID later on in the
>> documnet
>>> use the term "Standard IIDs"
>>
>> That only seems to concern two places:
>>
>> 1. The definition of Link-Local IPv6 Unicast Addresses,
>> which is explicit about the 64.
>>
>> 2. A rather unnecessary reference to RFC 3587, which IMHO
>> could simply be dropped at this point in history.
>>
>>> One of the sources of confusion in all of this is not distingusing
>> between
>>> the generic concept of IIDs used in section 2.4, and the standardised
>>> 64-bit IID, it gives the faulse impression that all IIDs are 64 bits in
>>> length.
>>>
>>> Something to think about, was the change from RFC1884 to RFC2373 intended
>>> to be backward compatible? Or was there a flag day where we went from
>>> RFC1884 (IPv6.0) and to RFC2373 (IPv6.1)?
>>
>> July 1998? From what I recall of the implementation and deployment
>> status then, backwards compatibility wasn't really an issue. As
>> long as all hosts on a given link were at the same level, all
>> would be well. Somebody might remember how AIX managed this, since
>> it had the first commercial release of IPv6 in 1997. But maybe it
>> didn't have SLAAC initially.
>>
>> SLAAC was specified from the beginning (RFC1971) for an arbitrary
>> length interface ID (called "interface token" in RFC1971).
>>
>>> As I see it RFC2373 was an
>>> incremental change, adding SLAAC with a standardized IID length of 64
>> bits,
>>> and the subnet assignment prefix (the PIO with the A flag) and allowing
>>> backward compatibility with manual configuration and DHCPv6 based on
>>> RFC1884. The Standard IIDs are required for SLAAC and recommended for
>>> manual configuration and DHCPv6.
>>
>> Sure, but RFC1971 implied 48 bit interface tokens.
>>
>>    Brian
>>
> 
> Ok, I guess I got the SLAAC part wrong, but the 48-bit to 64-bit was that a
> flag day or intended to be backward compatable?

I'm pretty sure we expected it to be a flag-day on any individual
link.

    Brian