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

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Mon, 24 May 2004 12:54 UTC

Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02951 for <ipv6-archive@odin.ietf.org>; Mon, 24 May 2004 08:54:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEoz-0002DA-Sg for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 08:44:50 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4OCinw4008499 for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 08:44:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEhq-0000TQ-7Y for ipv6-web-archive@optimus.ietf.org; Mon, 24 May 2004 08:37:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02112 for <ipv6-web-archive@ietf.org>; Mon, 24 May 2004 08:37:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEho-0006Pu-T2 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 08:37:24 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEgy-00068d-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 08:36:33 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSEgV-0005qh-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 08:36:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSETu-00077Q-4E; Mon, 24 May 2004 08:23:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEIv-0005VH-5G for ipv6@optimus.ietf.org; Mon, 24 May 2004 08:11:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00757 for <ipv6@ietf.org>; Mon, 24 May 2004 08:11:38 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSEIu-0006GC-1a for ipv6@ietf.org; Mon, 24 May 2004 08:11:40 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEI3-0005wv-00 for ipv6@ietf.org; Mon, 24 May 2004 08:10:48 -0400
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BSEGw-0005dJ-00 for ipv6@ietf.org; Mon, 24 May 2004 08:09:38 -0400
Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:455a:453:f505:e499]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0CC2B15263 for <ipv6@ietf.org>; Mon, 24 May 2004 21:09:37 +0900 (JST)
Date: Mon, 24 May 2004 21:09:38 +0900
Message-ID: <y7v65am10xp.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: ipv6@ietf.org
Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID
In-Reply-To: <y7v3c5vcka9.wl@ocean.jinmei.org>
References: <y7visetykfy.wl@ocean.jinmei.org> <40AA2FC7.302@zurich.ibm.com> <y7vvfisx1n1.wl@ocean.jinmei.org> <40AB33FB.8020300@zurich.ibm.com> <y7v3c5vcka9.wl@ocean.jinmei.org>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
Sender: ipv6-admin@ietf.org
Errors-To: ipv6-admin@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60

>>>>> On Thu, 20 May 2004 22:14:54 +0900, 
>>>>> JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> said:

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

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

(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
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------