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

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

From: ipv6 [mailto:[e-mail]] On Behalf Of james woodyatt

On Jul 17, 2017, at 23:42, David Farmer <[e-mail]> wrote:

>> I've begun to think there are two real problems here;
>>
>> 1.  RFC4291 categorically says architecturally IIDs are 64bits,

Actually, a better way to state this, to get past this "required" problem that keeps recurring, is to say that RFC 4291 "categorically states that IIDs must consist of EUI-64 format." Then that should put in perspective this whole issue. Quoting:

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

Besides which, SLAAC RFC 4862 is agnostic in principle, on the length of the IID. Everything becomes a matter of RFC 2464 (IPv6 over Ethernet), which is no better than RFC 4291. It too "categorically mandates" use of EUI-64 as IID.

RFC 4862:

   The
   length of the interface identifier is defined in a separate link-
   type-specific document, which should also be consistent with the
   address architecture [RFC4291] (see Section 2).

RFC 2464:

   The Interface Identifier [AARCH] for an Ethernet interface is based
   on the EUI-64 identifier [EUI64] derived from the interface's built-
   in 48-bit IEEE 802 address.

Enfin bref, may I suggest that all of our more recent decisions and considerations have gone well beyond what these outdated RFCs are saying? I think that any notion of "mandated 64-bit IIDs" is a bit like cherry-picking only one phrase of the requirement, and ignoring the other phrase concerning EUI-64. 

> Those other components aren’t based on IIDs at all. They’re based on
> IPv6 addresses and routing prefixes, but they’re not based on IIDs.

Good point. Still, if a prefix is permitted to be 128 bits long, that kind of implies something about IIDs too. Indirectly.

> That RFC 4291 still has this obsolescent concept of an IID that comes
> from embedding Modified EUI-64 transformations of MAC addresses isn’t
> actually causing any real problem that I’m seeing stated anywhere.

Well, no one wants to say that embedding EUI-64 is a good idea anymore. But the way we have agreed to proceed, with SLAAC retaining a 64-bit boundary, and otherwise keeping the matter flexible, is the right way to go.

> Rather than implying that operationally IID are required to be 64bits,
> how about simply stating that operationally 64 bit IIDs are recommended.

Amen.

Bert