[psg.com #250] Reception of prefix option with prefix length > 64

rt+ipv6-2461bis@rt.psg.com Thu, 23 September 2004 19:19 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13522 for <ipv6-web-archive@ietf.org>; Thu, 23 Sep 2004 15:19:31 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAZEk-0007aL-4p for ipv6-web-archive@ietf.org; Thu, 23 Sep 2004 15:26:38 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYxH-0006XF-AD; Thu, 23 Sep 2004 15:08:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAYmR-00067G-Pn for ipv6@megatron.ietf.org; Thu, 23 Sep 2004 14:57:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10868 for <ipv6@ietf.org>; Thu, 23 Sep 2004 14:57:21 -0400 (EDT)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAYtH-00079V-HY for ipv6@ietf.org; Thu, 23 Sep 2004 15:04:28 -0400
Received: from www by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAYmP-0002cM-Jk for ipv6@ietf.org; Thu, 23 Sep 2004 18:57:21 +0000
CC: ipv6@ietf.org
MIME-Version: 1.0
In-Reply-To: <rt-250@psg.com>
X-Mailer: Perl5 Mail::Internet v1.62
Content-Type: text/plain; charset="utf-8"
RT-Originator: h.soliman@flarion.com
X-RT-Original-Encoding: utf-8
Managed-BY: RT 3.0.11 (http://www.bestpractical.com/rt/)
RT-Ticket: psg.com #250
Message-Id: <rt-3.0.11-250-2857.1.1233718328392@psg.com>
Precedence: bulk
X-RT-Loop-Prevention: psg.com
From: rt+ipv6-2461bis@rt.psg.com
Date: Thu, 23 Sep 2004 18:57:21 +0000
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Subject: [psg.com #250] Reception of prefix option with prefix length > 64
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Reply-To: rt+ipv6-2461bis@rt.psg.com
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
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>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da

Folks, 

This is now an old issue and no one objected to
the resolution below. In addition, a few people seem
to be against explicitly restricting the prefix to 64
bits in the specification. So I'm closing this 
issue with the resolution shown below.

Hesham

> [h.soliman@flarion.com - Tue Jul 20 10:02:35 2004]:
> 
> This issue was discussed in some detail.
> 
> I've done the following:
> 
> - Clarified the prefix length field in 4.6.2
> - Added clarifications to the second last paragraph in 
>    6.3.4.
> 
> Text in 4.6.2:
> 
> Prefix Length  8-bit unsigned integer. The number of leading bits
>                      in the Prefix that are valid.  The value ranges
>                      from 0 to 128. The prefix length field provides
>                      necessary information for on-link determination
>                      (when combined with other flags in the prefix
>                      option).  It also assists with address
>                      autoconfiguration as specified in [ADDRCONF], for
>                      which there may be more restrictions on the prefix
>                      length.
> 
> 
> Text in 6.3.4: 
> 
>    Stateless address autoconfiguration [ADDRCONF] may in some
>    circumstances increase the Valid Lifetime of a prefix or ignore it
>    completely in order to prevent a particular denial of service attack.
>    However, since the effect of the same denial of service targeted at
>    the on-link prefix list is not catastrophic (hosts would send packets
>    to a default router and receive a redirect rather than sending
>    packets directly to a neighbor) the Neighbor Discovery protocol does
>    not impose such a check on the prefix lifetime values. Similarly,
>    [ADDRCONF] may impose certain restrictions on the prefix length for
>    address configuration purposes. Therefore, the prefix might be
>    rejected by [ADDRCONF] implementation in the host. However, the
>    prefix length is still valid for on-link determination when
combined     
>    with other flags in the prefix option.
> 
> 
> Currently there is no text that limits the prefix length
> to 64 if the A flag is set (as recommended by the IAB). 
> I'd like to hear from the WG if this should be added.
> 
> Hesham
> 
> 


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