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

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

-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 

>> IIDs used in SLAAC, LLA, 
>
> Link-local address creation is part of SLAAC

True ... although this weakens the argument for claiming that IIDs must only be 64 bits long. Strict interpretation of RFC 4862 implies that some SLAAC addresses could have other lengths of IID, at least in principle. RFC 4862 says to refer to the link layer-specific RFC to see how long the IID had to be. Is this still what people want? Sounds like another good reason for NOT redefining IIDs as only applying to 64-bit IIDs.

> There is nothing special about a ULA prefix. An address derived
> from a ULA prefix may, or may not, be created by SLAAC.

But RFC 4193 is pretty specific about IID length of ULAs:

3.1.  Format

   The Local IPv6 addresses are created using a pseudo-randomly
   allocated global ID.  They have the following format:

      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
      +--------+-+------------+-----------+----------------------------+
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
      +--------+-+------------+-----------+----------------------------+

   Where:

      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
                        addresses.

      L                 Set to 1 if the prefix is locally assigned.
                        Set to 0 may be defined in the future.  See
                        Section 3.2 for additional information.

      Global ID         40-bit global identifier used to create a
                        globally unique prefix.  See Section 3.2 for
                        additional information.

      Subnet ID         16-bit Subnet ID is an identifier of a subnet
                        within the site.

      Interface ID      64-bit Interface ID as defined in [ADDARCH].

So hey, perhaps ULAs are the *only* strictly mandated 64-bit IID, as of now? RFC 2464 is in jeopardy, sort of, given its rationale for requiring 64-bit IID over Ethernet links. For example, once upon a time, there was a 16-bit option for MAC addresses. Could that creep into RFC 2464-bis somehow? No telling what other IID lengths would be required for other link layer types, in the future? I'm pretty sure most people wouldn't approve of the direction these considerations would lead us to, on the 64-bit boundary question.

Bert