Subject: [rfc2462bis issue 281] Requirement for 64bit I/F ID

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 18 May 2004 21:43:45 +0900

[Note: if you've forgotten the discussion, please first refer to the
following URL (and its followups if necessary):
https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html ]

In this message, I pointed out that there might be possible conflict
between the IPv6 address architecture and link specific documents
(e.g. IPv6 over ethernet), and asked how we can clarify the point.

Unfortunately, I've not seen a direct answer to the question...I now
think it's time to decide how we should deal with this issue in
rfc2462bis.

In the previous discussion, some people wanted to "hard code" the
assumption that the interface identifier is 64-bit long.  But there
was an opposite opinion that wanted to avoid the hardcoding.

I personally think it is beyond the right of rfc2462bis to hardcode
the value, regardless of whether fixing the IFID length is a good idea
or not.  The real problem is the conflict I pointed out, which is
outside of rfc2462bis.  If we tried to give an "answer" in rfc2462bis,
we'd implicitly affect the other documents.

But at the same time, I guess it is irresponsible to leave the RFC2462
text on this point as is, because we know this issue has been annoying
implementors.

So, my basic idea is to clarify the current situation with realistic
compromise.

Specifically,

- add some notes after the definition of "interface identifier"
  (RFC2462 section 2) as follows:

    Note that [ADDR-ARCH] and the link-type specific document can
    potentially conflict with each other about the length of the
    interface identifier, whereas there has been no conflict in the
    actual specifications.  The case where the two documents actually
    conflict is outside the scope of this document.

- describe the possible conflict I pointed out in an appendix or
  somewhere in the document, and refer to the description from the
  above note.

- emphasize that "64-bit" is not hardcoded.  For example, after the
  following sentence of Section 5.3

     Note that interface identifiers will typically be 64-bits
     long and based on EUI-64 identifiers as described in [ADDR-ARCH].

  make an additional note like this:

     It should also be noted, however, that the exact length and the
     way the identifier is created is defined in a separate link-type
     specific document.  An implementations SHOULD NOT assume the
     typical cases, but SHOULD follow the link-type specific document.

Is this a reasonable approach?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 May 2004 17:46:15 +0200

> think it's time to decide how we should deal with this issue in

First of all let's not forget that the addressing architecture is 100%
unambiguous in saying that unicast interface IDs are required to be
64 bits, so a link-specific document that attempted to define a different
ID length would be in direct conflict with RFC 3513. So the question
*cannot* arise unless RFC 3513 is updated or the IESG approves something
that is broken.

That being so, I think it is reasonable to make 2462bis immune to
theoretical future changes. But I have some comments on your
proposals...

> we'd implicitly affect the other documents.

Fully agree

> text on this point as is, because we know this issue has been annoying

In my view, only because they failed to review the addressing architecture,
which is unambiguous.

>     interface identifier, 

No they can't, because no such link-specific document should be
allowed by the IESG without an explicit update to [ADDR-ARCH].

>     whereas there has been no conflict in the

So I think this note needs to be rewritten:

   Note that a future revision of [ADDR-ARCH] and a future link-type
   specific document could potentially allow for an interface identifier
   of length other than 64 bits.

>   somewhere in the document, and refer to the description from the

It isn't a *conflict* if the IESG does its job. It's a possible *change*.
>      long and based on EUI-64 identifiers as described in [ADDR-ARCH].

Actually the word "typically" is now a bug since [ADDR-ARCH] requires
the length to be 64.
>      typical cases, but SHOULD follow the link-type specific document.

OK but add
    As noted above, this would also require an update to [ADDR-ARCH].

       Brian

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 May 2004 09:32:26 -0700

Jinmei/Brian,

I agree with Brian's comments. RFC 3587 is very clear that unless the first
three bits of the address are set to 0, the interface id is required to be
64 bits. So there should be no conflict.

            jak

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 18, 2004 8:46 AM
Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID

>  > following URL (and its followups if necessary):
https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html
 ]

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 19 May 2004 17:27:30 +0900

>>>>> On Tue, 18 May 2004 17:46:15 +0200, 
>>>>> Brian E Carpenter <[email-masked]> said:

> *cannot* arise unless RFC 3513 is updated or the IESG approves something

I don't think I forgot the point.  I know RFC3513 and RFC 3587 are
100% unambiguous.  I know link-specific documents (e.g. IPv6 over
ethernet) are also 100% unambiguous.  The problem is that the two sets
of unambiguous documents may conflict with each other or at least the
two sets may seem to conflict for implementors.

> In my view, only because they failed to review the addressing architecture,

I don't think so, because RFC2462 uses link-specific documents as the
primary source about (the length of the) the IFID:

   interface identifier - a link-dependent identifier for an interface
        that is (at least) unique per link [ADDR-ARCH].
[...]
        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., [IPv6-ETHER]).

BTW: according to what you were saying, it seems to me that

1. the primary source should actually be the ADDR-ARCH document, not
   link-specific documents
2. link-specific documents must be consistent with ADDR-ARCH.  If not,
   the IESG will reject the document.

If this is the case, I'm just happy with it (is there any direct
reference which states that ADDR-ARCH is the primary?).  Then it will
probably be enough to revise the definition to:

   interface identifier - a link-dependent identifier for an interface
        that is (at least) unique per link [ADDR-ARCH].
[...]
        The exact length of an interface identifier is defined in
        [ADDR-ARCH] based on the address format.  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., [IPv6-ETHER]).

perhaps with a note like this:

        The link-type specific document may also define the length of
        the interface identifier.  However, it must be consistent with
        the definition in [ADDR-ARCH].

(If there is a reference that I asked above, it's also good to add the
reference here.)

					JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 May 2004 12:16:27 +0200

Jinmei, I believe your proposed new text at the bottom is correct.
2462bis should not open the door to conflict in future link-layer
specs.

    Brian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 20 May 2004 22:14:54 +0900

>>>>> On Wed, 19 May 2004 12:16:27 +0200, 

> 2462bis should not open the door to conflict in future link-layer

Okay, but after re-reading the proposed new text, I then changed my
mind a bit; it should be better to use link specific documents as the
primary source of the IFID length.  Otherwise, the implementor would
wonder how they should do if a received prefix in an RA does not match
ones for which ADDR-ARCH defines the corresponding IFID length.

So, the better text would be as follows:

   interface identifier - a link-dependent identifier for an interface
        that is (at least) unique per link [ADDR-ARCH]. 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., [IPv6-ETHER]).
(i.e., the same text as RFC2462)

with a note about the relationship between ADDR-ARCH and link specific
documents to avoid confusion:

	Note that [ADDR-ARCH] also defines the length of the interface
        identifiers for some set of addresses, but the two sets of
        definitions must be consistent.

It should also be good to emphasize that the implementation should not
assume the particular constant "64" like this:

   Note that a future revision of [ADDR-ARCH] and a future link-type
   specific document could potentially allow for an interface identifier
   of length other than 64 bits.  Thus, an implementation should not
   assume that particular constant.  Rather, it should expect any
   lengths of interface identifiers.

(the text you proposed in an earlier message)

Makes sense?

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 24 May 2004 21:09:38 +0900

>>>>> On Thu, 20 May 2004 22:14:54 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> ones for which ADDR-ARCH defines the corresponding IFID length.

(snip)

No responses..., assuming everyone is fine with the last text of mine,
here is a set of concrete proposals on this issue.  (I'm intentionally
removing the hard-coded "64"s in the proposals).  Please review the
proposals and make comments on them (if necessary).

1. revise the definition of "interface identifier" (at the end of
   Section 2) as follows:

   interface identifier - a link-dependent identifier for an interface
      that is (at least) unique per link [4]. 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., IPv6 over Ethernet [2]).  Note that [4] 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.

2. revise the last sentence of the second paragraph of Section 5.3
   as follows:

From:
   [...]  If the interface identifier is more than 118 bits
   in length, autoconfiguration fails and manual configuration is
   required. Note that interface identifiers will typically be 64-bits
   long and based on EUI-64 identifiers as described in [4].

To:
   [...]  If the interface identifier is more than 118 bits
   in length, autoconfiguration fails and manual configuration is
   required. The length of the interface identifier is defined in a
   separate link-type specific document, which should also be
   consistent with [4] (see Section 2). These documents will carefully
   define the length so that link-local addresses can be
   autoconfigured on the link.

3. revise the paragraph after the diagram in bullet d) of Section
   5.5.3 as follows:

From:
      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored. An implementation MAY wish to log a system management
      error in this case. It is the responsibility of the system
      administrator to insure that the lengths of prefixes contained in
      Router Advertisements are consistent with the length of interface
      identifiers for that link type. Note that interface identifiers
      will typically be 64-bits long and based on EUI-64 identifiers as
      described in [4].

To:
      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored. An implementation MAY wish to log a system management
      error in this case.  The length of the interface identifier is
      defined in a separate link-type specific document, which should
      also be consistent with [4] (see Section 2).

      It is the responsibility of the system administrator to insure
      that the lengths of prefixes contained in Router Advertisements
      are consistent with the length of interface identifiers for that
      link type. It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  In fact, the
      advertised length has non trivial meaning for on-link
      determination in Neighbor Discovery [5] where the sume of the
      prefix length and the interface identifier length may not be
      equal to 128.  Thus, it should be safe to validate the
      advertised prefix length here, in order to detect and avoid a
      configuration error specifying an invalid prefix length in the
      context of address autoconfiguration.

      Note that a future revision of [4] and a future link-type
      specific document, which will still be consistent with each
      other, could potentially allow for an interface identifier of
      length other than the value defined in the current documents.
      Thus, an implementation should not assume a particular
      constant. Rather, it should expect any lengths of interface
      identifiers.

					JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 May 2004 14:44:00 +0200

OK

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 May 2004 12:08:32 +0200

Architecturally, this appears to be the correct solution.

(I would expect a lot of protest at any proposal to *actually*
deviate from 64 bits, but that is another discussion.)

     Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 May 2004 13:14:07 -0400

I am still of the belief that limiting the routing prefix to 64 bits is a 
shortsighted design choice that will limit the lifetime and applicability
of IPv6.  Anything we can do to discourage the notion that an interface
ID shall be 64 bits now and forever is, IMHO, a good idea.

Keith

-- 
--
Regime change 2004 - better late than never.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 26 May 2004 13:34:12 +0900

>>>>> On Tue, 25 May 2004 13:14:07 -0400, 
>>>>> Keith Moore <[email-masked]> said:

> ID shall be 64 bits now and forever is, IMHO, a good idea.

Just checking: is this an agreement or a disagreement on the proposed
text for rfc2462bis, or is this just an opinion on the (seemingly)
fixed constant of the IFID/prefix length?

In any event, the proposed text does not contain a hard-coded "64" and
does contain a note that an implementation should expect a different
length of IFIDs/prefixes than the one currently used.  So I guess you
can live with it.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 29 May 2004 12:03:42 +0900

>>>>> On Wed, 26 May 2004 13:34:12 +0900, 

> length of IFIDs/prefixes than the one currently used.  So I guess you

No responses...I interpreted the silence as a sort of agreement, and
I'm going to close this issue with the proposed text.

					JINMEI, Tatuya

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 May 2004 23:49:48 -0400

> I'm going to close this issue with the proposed text.

If the previous message was sent to me, I missed it.  But yes, I do 
support the proposed text.

Keith

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 29 May 2004 13:24:46 +0900

>>>>> On Fri, 28 May 2004 23:49:48 -0400, 

> support the proposed text.

Okay, thanks.

					JINMEI, Tatuya