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

Brian E Carpenter <brc@zurich.ibm.com> Mon, 24 May 2004 13:31 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05157 for <ipv6-archive@odin.ietf.org>; Mon, 24 May 2004 09:31:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFPX-0007bx-IS for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 09:22:35 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4ODMZ1J029257 for ipv6-archive@odin.ietf.org; Mon, 24 May 2004 09:22:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSFFl-00062P-RF for ipv6-web-archive@optimus.ietf.org; Mon, 24 May 2004 09:12:29 -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 JAA03965 for <ipv6-web-archive@ietf.org>; Mon, 24 May 2004 09:12:26 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSFFk-0001eB-6b for ipv6-web-archive@ietf.org; Mon, 24 May 2004 09:12:28 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSFEm-0001KO-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 09:11:28 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSFDn-00011M-00 for ipv6-web-archive@ietf.org; Mon, 24 May 2004 09:10:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSF3k-0003zC-94; Mon, 24 May 2004 09:00:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSEqY-0002Sp-L6 for ipv6@optimus.ietf.org; Mon, 24 May 2004 08:46: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 IAA02494 for <ipv6@ietf.org>; Mon, 24 May 2004 08:46: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 1BSEqX-0001LT-7v for ipv6@ietf.org; Mon, 24 May 2004 08:46:25 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSEpZ-00012Z-00 for ipv6@ietf.org; Mon, 24 May 2004 08:45:26 -0400
Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx with esmtp (Exim 4.12) id 1BSEod-0000Rb-00 for ipv6@ietf.org; Mon, 24 May 2004 08:44:27 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4OChvlg049442 for <ipv6@ietf.org>; Mon, 24 May 2004 12:43:57 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4OChu6M119020 for <ipv6@ietf.org>; Mon, 24 May 2004 14:43:56 +0200
Received: from zurich.ibm.com (sig-9-145-240-202.de.ibm.com [9.145.240.202]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA43656 for <ipv6@ietf.org>; Mon, 24 May 2004 14:43:56 +0200
Message-ID: <40B1EE10.8020704@zurich.ibm.com>
Date: Mon, 24 May 2004 14:44:00 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID
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>
In-Reply-To: <y7v3c5vcka9.wl@ocean.jinmei.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

OK

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




JINMEI Tatuya wrote:
>>>>>>On Wed, 19 May 2004 12:16:27 +0200, 
>>>>>>Brian E Carpenter <brc@zurich.ibm.com> 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.
> 
> 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
> 					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
> --------------------------------------------------------------------
> 

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