>>>>> On Mon, 7 Mar 2005 20:04:57 +0200,
>>>>> Markku Savela <[EMAIL PROTECTED]> said:
>> If the sum of the prefix length and interface identifier length
>> does not equal 128 bits, the Prefix Information option MUST be
>> ignored. An implementation MAY wish to log a system management
>> (Section 5.5.3, bullet d).
> Then, I suppose I will technically correct, if I just declare, that on
> my own ethernet at home I can have identifier length = 56, and
> announce prefix length = 72. It's local implementation issue. :-)
I don't know how you came to that conclusion or whether you were just
joking...the appropriate prefix length (and thus the appropriate
interface identifier length) is specified as a link-specific constant
by the specification (RFCs), e.g, it's 64bits for ethernet links. Thus,
"declaring the length is 56 bits" (whereas the standard constant is
different) is not a local implementation issue; such an implementation
is just non-compliant.
>> rfc2462bis will even make this point clearer, with an attempt of
>> clarifying the consistency between the address architecture RFC and
>> link-specific RFCs wrt the appropriate prefix length.
> Why do such limiting change? It only gives users more configuration
> options. I don't mind it being by default 64+64, but it does not need
> to be mandated.
I don't recall all past discussions, but there are always obvious
tradeoffs in this type of "flexibility" discussions:
- if we only use a fixed constant, we can avoid unexpected hazardous
cases due to configuration error (e.g., very long prefix causing
very likely address collisions).
- if we only use a fixed constant, the receiving side implementation
can be simpler, in that it doesn't have to care about non-default
cases.
- on the other hand, a fixed constant value decreases configuration
flexibility
Since this is a matter of tradeoffs, opinions can always vary. But in
my vague memory, we've discussed the tradeoff multiple times (perhaps
some directly and some implicitly), and somehow came to the consensus
with the fixed constant. And, again, I don't think revisiting the
discussion at this stage is worth trying.
Of course, one can still make a separate new draft, proposing to relax
the constraint, if they think they can convince the community (I
personally won't support the document though:-)
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
