Jinmei,
(B
(BI guess I'm confused by something here. The way you make your point
(Bmakes me think that there are two prefixes being advertised, one for on-link
(Bdetermination and one for address configuration. I've questioned the
(Bpracticality
(Bof this before and I think we can say that this is an atypical scenario based
(Bon
(Bour knowledge today. Given this, I don't see a big benefit in spending a lot
(Bof
(Btext on this scenario, because it's an unusual case and I think a reader
(Bwould
(Bfind this quite confusing.
(B
(BI'm happy with a text suggestion but I don't think we should ignore the
(Brestriction
(Bon prefix lengths in the RA, which is likely to be the norm.
(B
(BHesham
(B
(B > -----Original Message-----
(B > From: [EMAIL PROTECTED]
(B > [mailto:[EMAIL PROTECTED]
(B > Sent: Thursday, June 17, 2004 10:25 AM
(B > To: Soliman Hesham
(B > Cc: [EMAIL PROTECTED]
(B > Subject: Re: [rfc2461bis] Receiving a prefix option with
(B > prefix length > 64
(B >
(B >
(B > >>>>> On Thu, 17 Jun 2004 05:07:42 -0400,
(B > >>>>> "Soliman Hesham" <[EMAIL PROTECTED]> said:
(B >
(B > >> The above text seems to assume that the "Prefix Length"
(B > in terms of
(B > >> RFC2461 (and its bis) is somehow tied with the address
(B > >> architecture...
(B > >>
(B > >> Again, I'd still like to see a consensus on the assumption itself.
(B >
(B > > => It's not an assumption it's a fact, more below.
(B >
(B > The fact is, at least as I see it, that the prefix length advertised
(B > in an RA **for stateless address autoconfiguration" is tied with
(B > address architecture (and link-specific documents). And, in fact,
(B > rfc2462bis-02 will try to make this point much clearer than the
(B > original RFC did.
(B >
(B > Whether the prefix ***for on-link determination*** is (or should be)
(B > tied with the address architecture is a different question. I don't
(B > think we fully agreed on this point. That's why I used the term
(B > "assumption".
(B >
(B > >> Of course, others may have different opinions, and so
(B > it's probably
(B > >> too early to make a concrete suggestion. But, for what
(B > it's worth,
(B > >> I'd rather suggest, assuming we agree the original intention makes
(B > >> sense, that rfc2461bis clarify that
(B > >>
(B > >> - a prefix for on-link determination is irrelevant to the address
(B > >> architecture, particularly for the purpose of stateless address
(B > >> autoconfiguration,
(B > >> - thus the prefix length can be an arbitrary number
(B > between 0 and 128
(B > >>
(B > >> (with this approach, we won't have to be bothered with a
(B > particular
(B > >> hard-coded leading bits like "000")
(B >
(B > > => The above doesn't make sense to me. This is not about on-link
(B > > determination
(B > > or hardcoding bits in the IP stack or stateless address
(B > autoconfig.
(B > > This is about two things:
(B >
(B > > 1. The ADDRARCH RFC specifies that the only prefixes with
(B > variable lengths
(B > > are the ones with 000 in the leading bits. This is a fact.
(B >
(B > Yes, but again, how this should be related to on-link
(B > determination is
(B > a different question.
(B >
(B > > 2. The IAB in their response to Robert Elz' appeal clearly
(B > stated that there
(B > > is
(B > > an inconsistency between RFC 2461 and ADDRARCH and that it
(B > should be
(B > > addressed. This is also a fact.
(B >
(B > Okay, but if we read the IAB's response carefully, we'd notice that
(B > the IAB basically talks about the address configuration part:
(B >
(B > From
(B > http://www.iab.org/appeals/kre-ipng-address-arch-draft-standa
(Brd-response.html,
(B
(B e) We recommend that, via a recommendation to the IESG, that the IPv6
(B Working Group expeditiously revise RFC-2461 to:
(B
(B * specifically note that it is not valid to configure an IPv6
(B router such that the 'autonomous configuration' bit is set to
(B ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(B TRUE AND the advertised IPv6 prefix length exceeds 64 bits AND
(B ^^^^
(B the advertised IPv6 prefix does not start with binary 000,
(B
(BSo, even with the "fact" that the IAB made a recommendation on
(Brfc2461bis, it's still open how we should do with the prefix length
(Bfor on-link determination (especially when the A flag is unset).
(B
(B> I asked the WG in Seoul what to do about the above and the answer was
(B> that some prefixes are not fixed (i.e. 000 prefixes). No one
(B> objected to this interpretation as it seems to avoid other drastic
(Bmeasures.
(B
(B> The last bullet above seems to ignore ADDRARCH. I'm not sure that
(B> we want to reenter this discussion to respin ADDRARCH.
(B
(BI didn't ignore ADDRARCH with the bullet I provided, and I didn't
(Bintend to respin ADDRARCH. Rather, I tried to fully respect ADDRARCH
(Bin rfc2462bis.
(B
(BAgain, even with the IAB's recommendation, it's still open how we
(Bshould do when we receive a prefix information option in an RA where
(B
(B- the (global) prefix does not start with 000,
(B- the A flag is not set, and
(B- the L flag is set
(B
(BWhatever solution we take for this, it won't affect ADDRARCH, since
(Bit doesn't have any relationship with addressing.
(B
(BAlthough I have my own preference on the solution, I don't necessarily
(Bstick to the idea. However, I'd really like to see a clear consensus
(Bon this list. If it's different from my preference, it's okay, I'll
(Btake it.
(B
(BThanks,
(B
(B JINMEI, Tatuya
(B Communication Platform Lab.
(B Corporate R&D Center, Toshiba Corp.
(B [EMAIL PROTECTED]
(B
(B===========================================================
(BThis email may contain confidential and privileged material for the sole use
(B of the intended recipient. Any review or distribution by others is strictly
(B prohibited. If you are not the intended recipient please contact the sender
(B and delete all copies.
(B===========================================================
(B
(B
(B--------------------------------------------------------------------
(BIETF IPv6 working group mailing list
(B[EMAIL PROTECTED]
(BAdministrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
(B--------------------------------------------------------------------
