Re: [rfc2461bis] Receiving a prefix option with prefix length > 64
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rfc2461bis] Receiving a prefix option with prefix length > 64
>>>>> On Tue, 15 Jun 2004 09:31:51 -0400,
>>>>> "Soliman Hesham" <H.Soliman at flarion.com> said:
>> (I'd personally avoid using the magic number of 64, but anyway)
> => 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.)
>> 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.
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.
jinmei at isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.