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

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 17 Jun 2004 11:25:03 -0400

Jinmei,

I guess I'm confused by something here. The way you make your point
makes me think that there are two prefixes being advertised, one for on-link
determination and one for address configuration. I've questioned the
practicality
of this before and I think we can say that this is an atypical scenario based
on
our knowledge today. Given this, I don't see a big benefit in spending a lot
of 
text on this scenario, because it's an unusual case and I think a reader
would
find this quite confusing. 

I'm happy with a text suggestion but I don't think we should ignore the
restriction
on prefix lengths in the RA, which is likely to be the norm. 

Hesham

 > -----Original Message-----
 > From: [email-masked] 
 > [mailto:[email-masked]]
 > Sent: Thursday, June 17, 2004 10:25 AM
 > To: Soliman Hesham
 > Cc: [email-masked]
 > Subject: Re: [rfc2461bis] Receiving a prefix option with 
 > prefix length > 64 
 > 
 > 
 > >>>>> On Thu, 17 Jun 2004 05:07:42 -0400, 
 > >>>>> "Soliman Hesham" <[email-masked]> 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-standa
rd-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-masked]

===========================================================
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: Fri, 18 Jun 2004 15:53:37 +0900

>>>>> On Thu, 17 Jun 2004 11:25:03 -0400, 

> determination and one for address configuration.

In theory, yes, two prefixes being advertised in a single
prefix-information option if both the A and L flags are set.  In fact,
RFC2461 says in 6.3.4 as follows:

      Note: Implementations can choose to process the on-link aspects of
      the prefixes separately from the address autoconfiguration aspects
      of the prefixes by, e.g., passing a copy of each valid Router
      Advertisement message to both an "on-link" and an "addrconf"
      function.  Each function can then operate independently on the
      prefixes that have the appropriate flag set.

(I think I cited this part before in this thread, but please excuse me
repeating this.  I think this part is important to discuss the
original intention of the RFC.)

> I've questioned the

I admit this can be a discussion on an atypical scenario, and I see
your frustration.  However, even if this is related to something
atypical, I believe it's very helpful to clarify the points in
rfc2461bis, since issues regarding prefix lengths have been annoyed
readers several times.

If you do not have enough time to spend on this, I'm willing to be a
volunteer to provide text clarifying the points.  Of course, we need
to make a consensus on details before editing the text.

Just trying to summarize the points so far,

1. RFC2461 originally separated prefixes for on-link determination
   from prefixes for address configuration clearly.  This is a fact.

   1-1. in my interpretation, the RFC intended arbitrary lengths for
   prefixes for on-link determination, though the lengths may be
   invalid for prefixes for address configuration.

2. the IAB made recommended to add a restriction of the length of
   prefixes for address configuration for a certain set of prefixes.
   This is another fact.

   From http://www.iab.org/appeals/kre-ipng-address-arch-draft-standard-response.html:

        * 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
   
3. what I'd like to clarify in rfc2461bis are:

   A. whether we'll still separate prefixes for on-link determination
      from prefix for address configuration, or we'll tie the former
      with the latter more tightly than before.
   B. if we still separate the two types of prefixes, whether there
      should be restriction on the length of a prefix for on-link
      determination.  If yes, what kind of restriction?  Is this
      related to the above recommendation from the IAB?
   C. if we decide to tie on-link prefixes with address-config prefixes
      more tightly, there should be some restriction on the length of
      the prefixes.  Then, what kind of restriction should we take?

I personally prefer "keep separating" for question A, and I prefer
allowing any lengths (between 0 and 128) for the length of an
"on-link" prefix.  The relationship between this and the IAB's
recommendation needs to be discussed.

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 22 Jun 2004 11:08:11 -0700 (PDT)

> "on-link" prefix.  

I have the same preferences.

  Erik