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

[JINMEI Tatuya / 神明達哉 <jinmei at isl.rdc.toshiba.co.jp>]

>>>>> On Thu, 17 Jun 2004 05:07:42 -0400, 
>>>>> "Soliman Hesham" <H.Soliman at flarion.com> 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.
					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
--------------------------------------------------------------------