>>>>> On Fri, 03 Sep 2004 12:44:21 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> In Section 5.3:
>> A link-local address is formed by prepending the well-known
>> link-local prefix [RFC3513] (of appropriate length) to the interface
>> identifier. If the interface identifier has a length of N bits, the
>> interface identifier replaces the right-most N zero bits of the
>> link-local prefix. If the sum of the link-local prefix length and N
>> is larger than 128,...
>> Using both the phrases 'of appropriate length' and 'the link local prefix
>> length' is confusing.
>> The link-local prefix length is fixed in RFC 3513 - it might be clearer to
>> say:
>> A link-local address is formed by prepending the well-known
>> link-local prefix [RFC3513] (padded to the appropriate length with zero
>> bits) to the interface
>> identifier. If the interface identifier has a length of N bits, the
>> interface identifier replaces the right-most N zero bits of the
>> link-local prefix extended to 128 bits with zero bits. If the sum of the
>> link-local prefix length and N
>> is larger than 128,...
> Ack.
Hmm...I should have said this after actually editing the text based on
the suggestion. Now I'm wondering if this is the right way to go.
The reason for the change from RFC2462 was to address the following
comment from you:
s.5.3: Putting the value of the link local prefix in explicitly makes a
potential double maintenance problem.
On one hand, I agree (and so I've made the change). On the other,
however, this change will make the expected behavior vague (which is a
typical result of generalization). I originally thought the benefit
of the generalization would outweigh its disadvantage. I'm not sure
with the actual result.
In RFC2462, this part was as follows:
A link-local address is formed by prepending the well-known link-
local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the
interface identifier. If the interface identifier has a length of N
bits, the interface identifier replaces the right-most N zero bits of
the link-local prefix. If the interface identifier is more than 118
bits in length, autoconfiguration fails and manual configuration is
required.
(where [ADDR-ARCH] is RFC2373)
And we are now going to change this to:
A link-local address is formed by prepending the well-known
link-local prefix [RFC3513] (padded to the appropriate length with
zero bits) to the interface identifier. If the interface identifier
has a length of N bits, the interface identifier replaces the
right-most N zero bits of the link-local prefix extended to 128 bits
with zero bits. If the sum of the link-local prefix length and N is
larger than 128, autoconfiguration fails and manual configuration is
required.
If I were a new-comer implementor understanding rfc2462bis, I'd
probably be annoyed on what the author meant by "padded to the
appropriate length with zero bits" or "the link-local prefix extended
to 128 bits with zero bits". I'd also probably ask what it actually
means in this list.
On the other hand, the RFC2462 text is very clear (I've never seen a
question on what it means.) Of course, the clarity is a trade-off
against the risk of double maintenance problems. In this particular
case, however, it's very unlikely that we'll ever use a different
prefix for unicast link-local addresses (at least IMO).
Note that we've seen a similar tradeoff issue on the length of
interface identifiers, and we've generalized the description in
rfc2462bis so as not to use the hard-coded prefix length of 64. In
that case, however, the situation was quite different. The
description in RFC2462 on this had been confusing implementors (and we
had seen the same question on this multiple times in this list). And
one of the reason is a kind of a "double maintenance" problem (i.e.,
multiple documents mentions the length of IPv6 prefixes with a little
bit different nuances). So I believe the resolution in rfc2462bis on
this was correct.
Thus, I'd now rather be more concrete on this. My latest proposal to
this part is as follows:
A link-local address is formed by prepending the well-known link-
local prefix FE80::0/10 [RFC3513] to the interface identifier. If
the interface identifier has a length of N bits, the interface
identifier replaces the right-most N zero bits of the link-local
prefix. If the interface identifier is more than 118 bits in
length, autoconfiguration fails and manual configuration is
required.
the point is to use the concrete prefix of FE80::0/10, but explicitly
specifying the length of 10 and removing the phrase "(of appropriate
length)".
I'd like to make an explicit consensus on this before submitting the
new revision if possible, but if I cannot get quick responses I'll
submit it anyway and solicit comments afterwards.
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
--------------------------------------------------------------------
