RE: [2461bis issue 250] Reception of prefix option with prefix length > 64

"Soliman Hesham" <H.Soliman@flarion.com> Mon, 01 March 2004 05:37 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 AAA06233 for <ipv6-archive@odin.ietf.org>; Mon, 1 Mar 2004 00:37:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg6j-0006HN-C7 for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 00:36:49 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215an4u024131 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 00:36:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg6j-0006H8-6L for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:36:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06211 for <ipv6-web-archive@ietf.org>; Mon, 1 Mar 2004 00:36:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axg6g-0003IA-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:36:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axg5m-0003Bh-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:35:51 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axg5G-00033y-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:35:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg51-0005ms-UW; Mon, 01 Mar 2004 00:35:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg4X-0005lS-3o for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 00:34:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06026 for <ipv6@ietf.org>; Mon, 1 Mar 2004 00:34:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axg4U-00031W-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:34:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axg3Y-0002wB-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:33:33 -0500
Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Axg3I-0002qZ-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:33:16 -0500
Subject: RE: [2461bis issue 250] Reception of prefix option with prefix length > 64
Date: Mon, 01 Mar 2004 00:32:43 -0500
MIME-Version: 1.0
Message-ID: <F4410B91C6CC314F9582B1A8E91DC9281BE748@ftmail2000>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Thread-Topic: [2461bis issue 250] Reception of prefix option with prefix length > 64
Thread-Index: AcP9AhmmJenR3jfsRpWf6uiGS4AsEACSy+8g
From: Soliman Hesham <H.Soliman@flarion.com>
To: JINMEI Tatuya / ???? <jinmei@isl.rdc.toshiba.co.jp>
Cc: IETF Mailing List <ipv6@ietf.org>
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.5 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Thanks Jinmei, 

But there is still the conflict between the address architecture
and ND at the moment. It may not affect the actual ND spec
but it seems like a confusing contradiction for someone trying to
understand how the ADDRARCH and ND specs fit together. 

The was also mentioned in the IAB response to Robert Elz' appeal
(i.e. that ND needs to be clarified or addr arch needs to be modified...).

Hesham

 > -----Original Message-----
 > From: jinmei@isl.rdc.toshiba.co.jp 
 > [mailto:jinmei@isl.rdc.toshiba.co.jp]
 > Sent: Friday, February 27, 2004 2:20 AM
 > To: Soliman Hesham
 > Cc: IETF Mailing List
 > Subject: Re: [2461bis issue 250] Reception of prefix option 
 > with prefix length > 64
 > 
 > 
 > Catching up an old topic...
 > 
 > >>>>> On Tue, 10 Feb 2004 07:26:05 -0500, 
 > >>>>> Soliman Hesham <H.Soliman@flarion.com> said:
 > 
 > > What should a node do upon reception of a prefix option 
 > with the prefix
 > > length set to a value >64?
 > 
 > > The issue can be stated more accurately to say:
 > > What should a host do upon reception of a prefix option 
 > with the prefix
 > > length set to a value != 64?
 > 
 > You appear to focus on the address configuration side of this issue.
 > And RFC2461 is quite clear that the prefix handling in RFC2461 should
 > be separate from that in RFC2462, so I'd see this as a 2462bis issue
 > and not a 2461bis issue.
 > 
 > Regarding rfc2461bis, my impression is that the receiving node must
 > accept an prefix information in terms of the ND (2461 or bis) part
 > regardless of the prefix length.
 > 
 > For example, assuming a 64-bit interface identifier, if we receive an
 > RA containing an prefix information option with 80-bit prefix length
 > and with the L and A bits both being set, RFC2462 clearly says that
 > the prefix MUST be ignored in terms of address configuration:
 > 
 >        If the sum of the prefix length and interface 
 > identifier length
 >        does not equal 128 bits, the Prefix Information option MUST be
 >        ignored.
 > (RFC2462 Section 5.5.3, )
 > 
 > However, I think the receiving node should still consider the prefix
 > as valid in terms of ND (i.e., consider it as "on-link") and modify
 > the next-hop determination accordingly.
 > 
 > The questions are:
 > 
 > 1. is this a correct understanding of the intention of RFC2461?
 > 2. if yes, is this a reasonable behavior?
 > 3. if yes (for both 1 and 2), should this explicitly be documented in
 >    rfc2461bis?
 > 
 > And my personal answers are:
 > 
 > yes for 1 (of course.  this is my understanding).
 > not sure for 2, but I don't oppose to the behavior (though I'll need
 > to change my own implementation).
 > probably yes for 3.
 > 
 > 					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
--------------------------------------------------------------------