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

From: "Soliman Hesham" <[email-masked]>
Date: Tue, 15 Jun 2004 09:31:51 -0400

> (I'd personally avoid using the magic number of 64, but anyway)

=> Why? It's a reality, at least for 2462.

 > 
 > In that case, the host can configure the on-link prefix but cannot
 > configure an address by the stateless autoconfiguration mechanism.
 > So, in this case, if the administrator fully understands 
 > what they are
 > doing, they would not set the "A" flag in the prefix information
 > option.  Even if they did set the flag, the validation check in
 > RFC2462 (or 2462bis) would reject the prefix for address
 > configuration.
 > 
 > Note that RFC2461 clearly says that a same single prefix information
 > option can be handled in terms of on-link determination and for
 > address configuration separately:
 > 
 >       Note: Implementations can choose to process the 
 > on-link aspects of
 >       the prefixes separately from the address 
 > autoconfiguration aspects
 >       of the prefixes by, e.g., passing a copy of each valid Router
 >       Advertisement message to both an "on-link" and an "addrconf"
 >       function.  Each function can then operate independently on the
 >       prefixes that have the appropriate flag set.
 > (Section 6.3.4)
 > 
 > So, I don't see any contradiction in my understanding.
 > 
 > Of course, it's a different question whether this kind of
 > configuration is practical. 

=> Exactly. I find it confusing to read about on-link determination and the 
use of short prefixes in a spec that deals with 64-bit IFIDs. We should at
least
indicate the ramifications of such configuration. Alternatively, RFC 2462
should
not talk about on-link determination since it's outside its scope.

   Well, admittedly this is unlikely happen
 > in a practical environment, and I'm not actually advocating this
 > usage.  But at the same time, I can imagine a single physical link
 > sharing the four /64 on-link prefixes where all addresses are
 > configured manually or by DHCPv6.

=> Sure, but this should be hinted at in the same sentence (I mean
DHCPv6). 

 > One last remark: the forthcoming rfc2462bis-01 will have a
 > clarification on the prefix length based on my interpretation:
 > 
 >       It is the responsibility of the system administrator to insure
 >       that the lengths of prefixes contained in Router Advertisements
 >       are consistent with the length of interface 
 > identifiers for that
 >       link type. It should be noted, however, that this does not mean
 >       the advertised prefix length is meaningless. In fact, the
 > -->   advertised length has non trivial meaning for on-link
 > -->   determination in RFC 2461 [5] where the sum of the 
 > prefix length
 > -->   and the interface identifier length may not be equal 
 > to 128. Thus,
 >       it should be safe to validate the advertised prefix 
 > length here,
 >       in order to detect and avoid a configuration error 
 > specifying an
 >       invalid prefix length in the context of address 
 > autoconfiguration.
 > 
 > this part will need another revise if my understanding is incorrect.

=> ok. 

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
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 15 Jun 2004 23:02:17 +0900

>>>>> On Tue, 15 Jun 2004 09:31:51 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

> => Why? It's a reality, at least for 2462.

Even RFC2462 says the length is "typically" 64 bits, and does not
assume the number as an invariable constant.  (But it's a different
issue, and let's concentrate on the main point in this thread not to
diverge.)

> not talk about on-link determination since it's outside its scope.

I'm not sure about your intention here, but RFC2462 does actually not
talk about on-link determination.  rfc2462bis-01 will mention it
referring to RFC2461 (or its bis) as cited in my previous message, but
it's just for clarifying the background story for readers.

Anyway...I really want to hear from someone very much familiar with
the original specification about the intention.  If my understanding
is incorrect, I won't stick to it.  Even if I'm correct, someone else
may still want to change the original intention, in which case we'll
need a separate discussion on which behavior is desirable.

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