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

From: "Elwyn Davies" <[email-masked]>
Date: Thu, 2 Sep 2004 23:29:09 +0200

Sorry - I spotted a couple of other points (updated):

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,...

In Section 5.5.3 (d) [not (e) as the previous message said], last para:

      If an address is formed successfully, the host adds it to the list
      of addresses assigned to the interface, initializing its preferred
      and valid lifetime values from the Prefix Information option.

I guess it ought to be mentioned that the address also has to pass DAD
before being added to the list of addresses:

      If an address is formed successfully and DAD shows that it is unique,
      the host adds it to the list
      of addresses assigned to the interface, initializing its preferred
      and valid lifetime values from the Prefix Information option.

Otherwise it looks good.

Regards,
Elwyn

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 02 September 2004 13:45
> To: [email-masked]
> Subject: new rev. of rfc2462bis will be coming
> 
> 
> I believe we are almost done about the post-WGLC comments on
> rfc2462bis, and I'm going to submit a new revision, addressing the
> comments.
> 
> The release candidate of the new revision is temporarily available at
>   http://www.jinmei.org/draft-ietf-ipv6-rfc2462bis-06.txt .
> 
> If anyone of you finds something missing, it would be nice of you to
> report that.
> 
> Thanks, (I really hope there will be no more post-WGLC comments with
> this one:-)
> 
> 					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
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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 12:44:21 +0900

>>>>> On Thu, 2 Sep 2004 23:29:09 +0200 , 
>>>>> "Elwyn Davies" <[email-masked]> said:

> link-local prefix length and N

Ack.

>       and valid lifetime values from the Prefix Information option.

I personally think this is pretty obvious, but I'm fine with the
additional note as a pre-submit comment.  I'll apply the change to rev
06.

Thanks for the pre-review.

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

---

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

>>>>> On Fri, 03 Sep 2004 12:44:21 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> 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

---

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

> additional note as a pre-submit comment.  I'll apply the change to rev

Hmmm...(again, I should have been more careful before making a quick
response) on the second thought, I've changed my mind.  If we apply
the suggested change, it could read that DAD is always performed
without any exception.  But this is not true when
DupAddrDetectTransmits on the interface is set to 0.

We could say instead that

  If an address is formed successfully and Duplicate Address Detection
  (when performed) shows that it is unique,...
  ^^^^^^^^^^^^^^^^

but I'm afraid this can even be confusing because the reader would
then re-read section 5.4 to find the background information of the
note, even thought it is not directly related to the prefix
information processing itself.

So I now personally would keep the current (rev05) text as is unless
others want to mention DAD here.

					JINMEI, Tatuya