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

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 17 Jun 2004 05:07:42 -0400

> 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.

 > 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.
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.

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.

Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Jun 2004 23:25:23 +0900

>>>>> On Thu, 17 Jun 2004 05:07:42 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

> => 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".

> 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.

> 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).

> 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-masked]

---

From: Tim Hartrick <[email-masked]>
Date: 17 Jun 2004 10:53:29 -0700

Jinmei,

> on this list.  If it's different from my preference, it's okay, I'll

Prefixes of /64 or less in length should be allowed.

Tim Hartrick
Mentat Inc.