>>>>> On Mon, 14 Jun 2004 10:13:24 -0400,
>>>>> "Soliman Hesham" <[EMAIL PROTECTED]> said:
> 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.
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.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
One more question about the prefix (and IFID) length.
Since the IFID length is defined in the link specific document (which
must be consistent with addr-arch, based on discussions so far) and
the prefix length is 128 - IFID_length by definition, the appropriate
prefix length must implicitly given by the link specific document.
The implementors may wonder why the RA bothers to specify the prefix
length in its prefix information option.
Recall that we have had a similar discussion in the context of 2461bis:
https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01600.html
My conclusion to this point including the one in the 2461bis context
is as follows:
The prefix length in the prefix information option has non trivial
meaning for specifying an on-link prefix with the L flag. For this
purpose, the length can be shorter (or perhaps even longer) than
"128 - IFID_length". For example, if the following four prefixes
should be regarded as "on-link":
2001:db8:0:00::/64,
2001:db8:0:01::/64,
2001:db8:0:10::/64,
2001:db8:0:11::/64
then the administrator may want to advertise the set of the prefixes
as "on-link" by sending a single aggregated prefix
"2001:db8::/62" with the L flag being set, instead of sending the
four prefixes separately.
So, my answer to Hesham's question (see the message available at the
above URL), what we should do is:
just accept any lengths of prefixes in terms of the "on-link"
processing. We may or may not want to add an explicit note that
the "prefix length + IFID_length" may not be equal to 128 but it's
okay for the on-link determination.
For rfc2462bis, I'd add a note to bullet d) of Section 5.5.3:
If the sum of the prefix length and interface identifier length
does not equal 128 bits, the Prefix Information option MUST be
ignored.
like this:
Note that the appropriate prefix length should be determined
by the interface identifier length and in that sense the
advertised prefix length is meaningless information. However,
the advertised prefix length has non trivial meaning for
on-link determination in Neighbor Discovery where the sume 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.
Comments?
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
--------------------------------------------------------------------
--- End Message ---
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
