Getting the wording right without creating double maintenance is a problem.
The point is that an address prefix only specifies the (prefix length) left most bits. RFC3513 has examples with essentially arbitrary bits to the right of the prefix. FE80::0/10 implies but does not make explicit what the rest of the bits should be as well as putting back the double maintenance thing.
How about:
A link-local address is formed by combining the well-known link-local prefix [RFC3513] with the interface identifier as follows:
1. The left-most 'prefix length' bits of the address are the link local prefix
2. The bits in the address to the right of the link-local prefix are set to all zeroes
3. If the length of the interface identifier is N bits, the right-most N bits of the address are replaced by the interface identifier.
If the sum of the prefix length and N is larger than 128 ...
Regards,
elwyn
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: 03 September 2004 06:40
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: new rev. of rfc2462bis will be coming
>
>
> >>>>> 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 --------------------------------------------------------------------
