Subject: RE: [rfc2461bis] Receiving a prefix option with prefix length > 64

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 16 Jun 2004 04:05:06 -0400

So I added one sentence to the description of the prefix
length. The text now reads:

   Prefix Length  8-bit unsigned integer.  The number of leading bits
                  in the Prefix that are valid.  The value ranges
                  from 0 to 128. This field allows for variable 
                  length prefixes to be advertised (e.g. prefixes 
                  starting with 000).

I didn't want to make it sound like 000 were the only 
prefixes that can have variable lengths, given that 
ADDRARCH is still a PS and this being a controversial part
of that RFC. 

If there are no comments on the text this issue will be closed.

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On 
 > Behalf Of
 > Soliman Hesham
 > Sent: Monday, June 14, 2004 10:13 AM
 > To: [email-masked]
 > Subject: [rfc2461bis] Receiving a prefix option with prefix 
 > length > 64 
 > 
 > 
 > This issue was discussed on the list and in the 
 > last meeting.
 > 
 > There were two sub issues:
 > 
 > 1. How does a host configure an address?
 > 2. Inconsistency with ADDRARCH
 > 
 > We agreed that (1) is out of scope for 2461bis
 > and is more relevant for address configuration
 > mechanisms.
 > 
 > (2) was discussed in the meeting and we agreed
 > to reflect in the draft that since some prefixes may not
 > be 64 bits (ones starting with 000) then the prefix
 > length field is ok to allow for variable length prefixes.
 > 
 > I'll add text in the new version to reflect (2). 
 > 
 > If there are no objections to the above I intend
 > to close this issue.
 > 
 > Hesham
 > 
 > ===========================================================
 > This email may contain confidential and privileged material 
 > for the sole use
 >  of the intended recipient.  Any review or distribution by 
 > others is strictly
 >  prohibited.  If you are not the intended recipient please 
 > contact the sender
 >  and delete all copies.
 > ===========================================================
 > 
 > 
 > --------------------------------------------------------------------
 > IETF IPv6 working group mailing list
 > [email-masked]
 > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
 > --------------------------------------------------------------------
 > 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Jun 2004 16:01:56 +0900

>>>>> On Wed, 16 Jun 2004 04:05:06 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

> ADDRARCH is still a PS and this being a controversial part

The above text seems to assume that the "Prefix Length" in terms of
RFC2461 (and its bis) is somehow tied with the address architecture...

Again, I'd still like to see a consensus on the assumption itself.

According to comments from Erik, who is a co-author of the original
RFC2461, I guess the original intention is to not tie the prefix
length with the address architecture.

Then the next step should be to discuss whether the original intention
makes sense or not.  At least Erik seems to think it still makes
sense.  And I tend to agree with him, too.

Of course, others may have different opinions, and so it's probably
too early to make a concrete suggestion.  But, for what it's worth,
I'd rather suggest, assuming we agree the original intention makes
sense, that rfc2461bis clarify that

- a prefix for on-link determination is irrelevant to the address
  architecture, particularly for the purpose of stateless address
  autoconfiguration, 
- thus the prefix length can be an arbitrary number between 0 and 128

(with this approach, we won't have to be bothered with a particular
hard-coded leading bits like "000")

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]