Re: RFC4291bis

[David Farmer <[e-mail]>]

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?

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