Subject: RE: new rev. of rfc2462bis will be coming

From: "Elwyn Davies" <[email-masked]>
Date: Fri, 3 Sep 2004 11:57:36 +0200

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-masked] 
> [mailto:[email-masked]] 
> Sent: 03 September 2004 06:40
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: [email-masked]'
> Subject: Re: new rev. of rfc2462bis will be coming
> 
> 
> >>>>> On Fri, 03 Sep 2004 12:44:21 +0900, 
> >>>>> JINMEI Tatuya <[email-masked]> 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-masked]
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 03 Sep 2004 19:21:29 +0900

>>>>> On Fri, 3 Sep 2004 11:57:36 +0200 , 
>>>>> "Elwyn Davies" <[email-masked]> said:

> rest of the bits should be as well as putting back the double maintenance

Okay, I see your first point.  Regarding the double maintenance issue,
I still think it's controversial.  In addition to the points I raised
in my previous message, we've already have several double-maintenance
issues on the unicast link-local prefix: several RFCs has already
hard-coded the concrete prefix of FE80::/10 or FE80::/64.  To name a
few:

  RFC2464, RFC2472, RFC2491, RFC2497, RFC2590, RFC3146 (IPv6 over xxx links)
  RFC2529 (6over4)
  RFC2546 (6bone routing practice)
  RFC3315 (DHCPv6)
  ...

and I'm quite sure several other I-Ds also hard-coding the concrete
prefix.

Will we really want to generalize the description for the existing
RFCs when they are to be revised?  Also, do we really want to "correct"
all those I-Ds, before publication, not to hardcode the constant to
avoid double maintenance problem?  I don't think so.  And if not, why
is rfc2462bis so special?

So,

> [RFC3513] with the interface identifier as follows:
...

the organization of the suggested text looks fine, but I'd still
rather be concrete on the constant.  And then the revised text would
be as follows:

=========================== from here =================================
A link-local address is formed by combining the well-known link-local
prefix FE80::0 [RFC3513] (of appropriate length) 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 ...
=========================== to here ===================================

Can we live with this?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]