RE: [rfc2461bis] Receiving a prefix option with prefix length > 64
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





 > 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
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.