>>>>> On Thu, 17 Jun 2004 05:07:42 -0400, >>>>> "Soliman Hesham" <[EMAIL PROTECTED]> said:
>> 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. > => It's not an assumption it's a fact, more below. The fact is, at least as I see it, that the prefix length advertised in an RA **for stateless address autoconfiguration" is tied with address architecture (and link-specific documents). And, in fact, rfc2462bis-02 will try to make this point much clearer than the original RFC did. Whether the prefix ***for on-link determination*** is (or should be) tied with the address architecture is a different question. I don't think we fully agreed on this point. That's why I used the term "assumption". >> 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") > => The above doesn't make sense to me. This is not about on-link > determination > or hardcoding bits in the IP stack or stateless address autoconfig. > This is about two things: > 1. The ADDRARCH RFC specifies that the only prefixes with variable lengths > are the ones with 000 in the leading bits. This is a fact. Yes, but again, how this should be related to on-link determination is a different question. > 2. The IAB in their response to Robert Elz' appeal clearly stated that there > is > an inconsistency between RFC 2461 and ADDRARCH and that it should be > addressed. This is also a fact. Okay, but if we read the IAB's response carefully, we'd notice that the IAB basically talks about the address configuration part: From http://www.iab.org/appeals/kre-ipng-address-arch-draft-standard-response.html, e) We recommend that, via a recommendation to the IESG, that the IPv6 Working Group expeditiously revise RFC-2461 to: * specifically note that it is not valid to configure an IPv6 router such that the 'autonomous configuration' bit is set to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TRUE AND the advertised IPv6 prefix length exceeds 64 bits AND ^^^^ the advertised IPv6 prefix does not start with binary 000, So, even with the "fact" that the IAB made a recommendation on rfc2461bis, it's still open how we should do with the prefix length for on-link determination (especially when the A flag is unset). > I asked the WG in Seoul what to do about the above and the answer was > that some prefixes are not fixed (i.e. 000 prefixes). No one > objected to this interpretation as it seems to avoid other drastic measures. > The last bullet above seems to ignore ADDRARCH. I'm not sure that > we want to reenter this discussion to respin ADDRARCH. I didn't ignore ADDRARCH with the bullet I provided, and I didn't intend to respin ADDRARCH. Rather, I tried to fully respect ADDRARCH in rfc2462bis. Again, even with the IAB's recommendation, it's still open how we should do when we receive a prefix information option in an RA where - the (global) prefix does not start with 000, - the A flag is not set, and - the L flag is set Whatever solution we take for this, it won't affect ADDRARCH, since it doesn't have any relationship with addressing. Although I have my own preference on the solution, I don't necessarily stick to the idea. However, I'd really like to see a clear consensus on this list. If it's different from my preference, it's okay, I'll take it. Thanks, 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 --------------------------------------------------------------------
