Index: [Article Count Order] [Thread]

Date: Fri, 12 Sep 2008 09:20:59 +0900
From: Yukiyo Akisada <akisada@tahi.org>
Subject: [users:00896] Re: Self Test 4.0.2 nd.p2/v6LC_2_2_19.seq failure
To: pcarney@treck.com
Cc: users@tahi.org
Message-Id: <20080912092059.17bb4edf.akisada@tahi.org>
In-Reply-To: <753EF94A8CD3E6439DCD566B99F4D742792737@ms1.treck.com>
References: <753EF94A8CD3E6439DCD566B99F4D742792737@ms1.treck.com>
X-Mail-Count: 00896

Hi, Peter.

The velification point is not the address asignment.
You can recognize the prefix information option as the invalid from the viewpoint of the address asignment,
but you must recognize it as the valid from the on-link determination.

In this case,
you must know that 3ffe:501:ffff:0:200:ff::/96 is the same link.

Please refer RFC 4861.

6.3.4.  Processing Received Router Advertisements

   3074                                                            Similarly,
   3075    [ADDRCONF] may impose certain restrictions on the prefix length for
   3076    address configuration purposes.  Therefore, the prefix might be
   3077    rejected by [ADDRCONF] implementation in the host.  However, the
   3087    prefix length is still valid for on-link determination when combined
   3088    with other flags in the prefix option.

And <http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-1/freebsd61.host/nd.p2/167.html> can be helpful
to understand the expected behavior.

Thanks,


On Thu, 11 Sep 2008 17:16:52 -0400
"Peter Carney" <pcarney@treck.com> wrote:

> Hello,
> 
> I am experiencing a test failure with Self Test 4.0.2, Section 2: RFC
> 4861, test # 167 "Router Advertisement Processing, On-link determination
> (Hosts Only)".
> 
> The failure is due to my node not configuring an address using the
> prefix information listed in the second router advertisement. Here are
> the contents of the router advertisement Prefix Information option:
> Prefix length: 96
> Flags: 0xc0
> Valid lifetime: 259,200
> Preferred lifetime: 604,800
> Prefix: 3ffe:501:ffff:0:200:ff:fe00:100
> 
> My node rejects the Prefix information option because the Prefix length
> is 96.
> 
> >From RFC 4862:
> 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 the
> address architecture [RFC4291] (see Section 2).
> 
> >From RFC 4291 Section 2:
> For all unicast addresses, except those that start with the binary value
> 000, Interface IDs are required to be 64 bits long and to be constructed
> in Modified EUI-64 format.
> 
> 
> Is it a bug that the router advertisement's Prefix Information option
> specifies a 96-bit prefix length?
> 
> Where in the RFC's does it allow me to process a Prefix Information
> option with a 96-bit prefix length?
> 
> 
> 
> Thank you,
> 
> Peter Carney
> Development Engineer
> Treck Inc.
> 
> 
> Treck, Inc. - Confidentiality Notice
> 
> This electronic transmission may contain information that is proprietary or
>  confidential. You are hereby notified that any dissemination,
>  distribution or duplication of this electronic transmission to some other
>  entity, without the expressed written consent of Treck, Inc. is strictly
>  prohibited, unless the contents of this electronic transmission
>  specifically authorizes you to do so. If your receipt of this electronic
>  transmission is in error, please notify the corporate offices of Treck,
>  Inc. immediately by calling (513) 528-5732, or by reply to
>  this transmission.
> 
> 
> 
> 
> 


-- 
Yukiyo Akisada <akisada@tahi.org>