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 --------------------------------------------------------------------
- Re: [rfc2462bis issue 281] Requirement for 64bit … Jun-ichiro itojun Hagino
- Re: [rfc2462bis issue 281] Requirement for 64bit … Pekka Savola
- Re: [rfc2462bis issue 281] Requirement for 64bit … JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis issue 281] Requirement for 64bit … JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis issue 281] Requirement for 64bit … Erik Nordmark
- [rfc2462bis issue 281] Requirement for 64bit I/F … JINMEI Tatuya / 神明達哉
- [rfc2462bis issue 281] Requirement for 64bit I/F … JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis issue 281] Requirement for 64bit … Brian E Carpenter
- Re: [rfc2462bis issue 281] Requirement for 64bit … James Kempf
- Re: [rfc2462bis issue 281] Requirement for 64bit … JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis issue 281] Requirement for 64bit … Brian E Carpenter
- Re: [rfc2462bis issue 281] Requirement for 64bit … JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis issue 281] Requirement for 64bit … JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis issue 281] Requirement for 64bit … Brian E Carpenter