Index: [Article Count Order] [Thread]

Date: Thu, 24 Jul 2008 11:43:14 +0000
From: "Gunnia Chandrasekaran, Praveen Kumar" <gcpraveen@hp.com>
Subject: [users:00829] v6LC_2_2_19 conflicting RFC 4291
To: "users@tahi.org" <users@tahi.org>
Message-Id: <33AD874197876A4E9440933154AA337D20C588697F@GVW1157EXB.americas.hpqcorp.net>
X-Mail-Count: 00829

Hi,
   We have conflicts between RFC 4861 and RFC 4291 (for test case v6LC_2_2_19)w.r.t prefix length.

As per 4291 (Section 2.5.4.Global Unicast Addresses):

   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

But in case of v6LC_2_2_19, When RA is received with invalid prefix length (say 96 in this particular test case), the sum of prefix length and interface id will be greater than 128, which would be ending up in rejecting this particular prefix as per the FreeBSD stack.

But as per RFC4291 if the prefix starts with 000, the prefix length advertised in RA can be of any length. This is a must requirement for RFC 4291 which is conflicting RFC 4861 test case (Verify that a host properly reject an invalid prefix length, however the prefix length is still valid for onlink determination when the on-link flag is true).

According to RFC 4291, v6LC_2_2_19 will fail, if the prefix starts with 000 and prefix length is not equal to 64.

Please let us know your thoughts on this.

Thanks,
Praveen/Sudhir.
IPG R&D HSL, Hewlett Packard ISO,
30, Cunningham Road, Bengalooru - 560 052.
Karnataka, India.
Phone: +91 80 2205 1791