RE: <draft-ietf-6man-rfc4291bis-09.txt>

["Manfredi, Albert E" <[e-mail]>]

-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 
Sent: Wednesday, July 19, 2017 22:41

>> why ask the question?
>
> a) Because of the several subtly different meanings of 'prefix' in IPv6.

Some prefixes can be on-link, while others are not. Okay, but this is a question of address architecture, and whatever prefix bits exist in that 128-bit address, the remaining bits are by definition IID.


   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |       subnet prefix           |           interface ID          |
   +-------------------------------+---------------------------------+

> b) Because some people seem to be limiting their use of 'IID' to the SLAAC
> meaning of 'prefix'.

I see only a small ambiguity in this regard. From RFC 4862:

   interface identifier -  a link-dependent identifier for an interface
      that is (at least) unique per link [RFC4291].  Stateless address
      autoconfiguration combines an interface identifier with a prefix
      to form an address.  From address autoconfiguration's perspective,
      an interface identifier is a bit string of known length.  The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).  Note that the address architecture
      [RFC4291] also defines the length of the interface identifiers for
      some set of addresses, but the two sets of definitions must be
      consistent.  In many cases, the identifier will be derived from
      the interface's link-layer address.

This definition does not limit the IID to 64 bits either, giving RFC 2464 only as an example, and saying only that "in many cases," the IID is derived from the link layer address. Without specifying how long that might be. And it refers back to RFC 4291, which does not limit IID to 64 bits.

The ambiguity is this:

      a link-dependent identifier for an interface
      that is (at least) unique per link [RFC4291].

IMO, that should now be stated as "unique per subnet prefix," as clearly stated in 2.5.1 of RFC 4291. I think we mentioned this in discussion recently. Still, this doesn't change the main point, that IIDs should not be constrained to always 64 bits, unless formed using SLAAC, as a self-imposed, artificial limitation. (Which as you pointed out, some clever hack can change in due course.)

Bert