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

Soliman Hesham <H.Soliman@flarion.com> Tue, 10 February 2004 12:30 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 HAA13786 for <ipv6-archive@odin.ietf.org>; Tue, 10 Feb 2004 07:30:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX1R-0006fC-LW for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:29:49 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ACTnwp025608 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 07:29:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqX1R-0006ex-I7 for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 07:29: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 HAA13755 for <ipv6-web-archive@ietf.org>; Tue, 10 Feb 2004 07:29:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqX1Q-0000Xc-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:29:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqX0W-0000Rt-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:28:53 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqWzi-0000Mp-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 07:28:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqWzh-0006Ci-MV; Tue, 10 Feb 2004 07:28:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqWzX-0006C4-Fd for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 07:27:51 -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 HAA13671 for <ipv6@ietf.org>; Tue, 10 Feb 2004 07:27:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqWzW-0000Lh-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:27:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqWyb-0000Gv-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:26:54 -0500
Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AqWyO-0000Bq-00 for ipv6@ietf.org; Tue, 10 Feb 2004 07:26:41 -0500
Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGWJYH>; Tue, 10 Feb 2004 07:26:16 -0500
Message-ID: <9E3BA3946476AD4EB94672712B12A85F042123@ftmail.lab.flarion.com>
From: Soliman Hesham <H.Soliman@flarion.com>
To: IETF Mailing List <ipv6@ietf.org>
Subject: [2461bis issue 250] Reception of prefix option with prefix length > 64
Date: Tue, 10 Feb 2004 07:26:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
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=none autolearn=no version=2.60

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?

So far I haven't received any comments on this issue.
It seems that there are few options to consider:

1. A host should ignore this field if it's not set to 
64 and form an address based on the leading 64 bits.

2. A host should ignore the field if not set to 64
and log an error. The host MUST NOT form an address
based on this prefix.

3. This field should be removed and a 64-bit prefix
always assumed by hosts. 

4. Leave this field as is and design a mechanism that
allows the host to form an address based on the 
length of the interface identifier (i.e. 128 - prefixlen). 

Realistically I don't think we should go with option 1. 
Option 4 requires more work and I don't know how we 
can proceed with this dependency on another spec. 
In any case, options 2,3,and 4 are the most realistic. 

Note that none of the options above are backward compatible.
In a sense, we can't be backward compatible because 
this seems like a bug given the current address architecture
RFC. 

Which option should we pick to solve this problem?
Other options are certainly welcome.

Hesham

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