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

From: Soliman Hesham <[email-masked]>
Date: Tue, 10 Feb 2004 07:26:05 -0500

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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Tue, 10 Feb 2004 14:38:28 +0200

> From: Soliman Hesham <[email-masked]>

> length set to a value >64?
...
> length of the interface identifier (i.e. 128 - prefixlen). 

Well, just a datapoint: I do basicly 4. I have 128 bits or less of
interface id. (128 - prefixlen) bits from the least significant part
of the interface id is copied into real address (and rest is ignored).

I could as well have prefixlen < 64. Makes no difference.

However, I would really prefer that all prefixes on the link do use
the same prefixlen :-)

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2004 16:20:00 +0900

Catching up an old topic...

>>>>> On Tue, 10 Feb 2004 07:26:05 -0500, 
>>>>> Soliman Hesham <[email-masked]> said:

> 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.
					[email-masked]