Re: RFC4291bis

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

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

> 
> Thanks.
> 
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>