>>>>> On Tue, 15 Jun 2004 01:03:36 -0400,
>>>>> "Soliman Hesham" <[EMAIL PROTECTED]> said:
>> Not necessarily an objection, but I'd like you to review my thoughts
>> below (attached), which is mainly for the rfc2462bis work
>> but has some
>> relationship with rfc2461bis.
>>
>> In short, in my interpretation the prefix length for an
>> on-link prefix
>> can be an arbitrary number, and is even not related to
>> ADDRARCH at all.
>> I could be wrong, of course, but I've not seen any comments (either
>> positive or negative) on the previous post, so right now I think I'm
>> correct on this.
> => I guess what puzzles me is how a host can form a valid address
> using 2462 if the prefix advertised != 64 bits? Sure there are other uses for
> the prefix length for on-link determination but I think it is important to
> include the entire prefix in the prefix option. For instance, in your example
> where the RA includes a /62 prefix to indicate that all prefixes longer than
> that are on-link, the host will understand the on-link part, but how does it
> configure an address in a stateless fashion?
(I'd personally avoid using the magic number of 64, but anyway)
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. 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.
Anyway...it's just my personal interpretation about RFC2461, and I
don't have a strong opinion on it. If someone else (preferably the
original designers of ND) can correct my understanding with
confidence, I'm willing to follow that.
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.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
