Subject: Comments on RFC2462bis

From: Suresh Krishnan <[email-masked]>
Date: Mon, 12 Jul 2004 22:16:41 -0400 (EDT)

Hi Tatuya,
	I have a few comments regarding 2462bis.

Section 2:
Solicited-node multicast address: The draft mentions that the algorithm 
for computing this address is described in RFC2461. This is not true. The 
algorithm is described in the address architecture RFC [RFC3513]

Section 5.4 DAD Page 13 

The following text makes no sense to me. Maybe I am reading this wrong but 
isn't this self contradictory

  "That is, the interface must
   accept Neighbor Solicitation and Advertisement messages containing
   the tentative address in the Target Address field, but processes such
   packets differently from those whose Target Address matches an
   address assigned to the interface. Other packets addressed to the
   tentative address should be silently discarded. Note that the "other
   packets" include Neighbor Solicitation and Advertisement messages to
   the tentative address containing the tentative address in the Target
   Address field."

Section 5.4.3 Page 15 bullet point number 1 starting with "If a Neighbor 
solicitation for a tentative address..."

It is stated that 

     "This condition occurs when two nodes run Duplicate Address
      Detection simultaneously, but transmit initial solicitations at
      different times"

This condition can also occur if another node has this address already 
assigned to an interface and a third node is running a neighbor 
solicitation for this address.

5.5.3 Router Advertisement processing

Bullet points b) and c) are redundant as they belong in RFC2461/2461bis 
and not here as they are not specific to autoconfiguration. Probably these 
can be removed.

Bullet point e) references a DoS attack but there are no references to 
it. Maybe it makes sense to add an informative reference to it.

Regards
Suresh

 On Mon, 12 Jul 2004, JINMEI Tatuya / [ISO-2022-JP] 
神明達哉 wrote:

>Reminder: the following wg last call will end tomorrow (July 13th).
>So far, I've only seen one comment in response to the last call (the
>one from itojun about "disabling interface" on DAD failure).
>
>I'm afraid wg members are too busy for processing a rush of new I-Ds
>or for writing/updating their own drafts, but if anyone of you could
>review the document by the end of the last call, it would really be
>appreciated.
>
>Right now, I'm planning to revise the draft once again before the
>final I-D cutoff on July 19th.
>
>Thanks,
>
>					JINMEI, Tatuya
>					Communication Platform Lab.
>					Corporate R&D Center, Toshiba Corp.
>					[email-masked]
>
>>>>>> On Tue, 29 Jun 2004 06:31:13 -0400, 
>>>>>> Brian Haberman <[email-masked]> said:
>
>> All,
>>       This note starts a 2 week IPv6 Working Group Last Call on:
>
>> 	Title		: IPv6 Stateless Address Autoconfiguration
>> 	Author(s)	: S. Thomson, et al.
>> 	Filename	: draft-ietf-ipv6-rfc2462bis-02.txt
>> 	Pages		: 30
>> 	Date		: 2004-6-17
>
>> being recycled at Draft Standard.  All substantive comments should be
>> directed to the mailing list.  Editorial comments can be directed to
>> the mailing list or the editor.
>
>> This last call will end on July 13, 2004.
>
>--------------------------------------------------------------------
>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: "O.L.N.Rao" <[email-masked]>
Date: Tue, 13 Jul 2004 14:23:24 +0530

----- Original Message ----- 
From: "Suresh Krishnan" <[email-masked]>
To: "JINMEI Tatuya / 神明達哉" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 13, 2004 7:46 AM
Subject: Comments on RFC2462bis

>    the tentative address in the Target Address field,

OLN ===> Destination Address is not Tentative Address here

>      but processes such

OLN ==> Definitely a stack is not supposed to pick up the packet that is
*destined*
                  to a *not-yet-assigned* address.

> solicitation for this address.

In this case the node that has already assigned the address will have the
address in permanent address list and not in the tentative address list.
In this case, the first node (who owns address) defends the other fellows
DAD by sending DAD-NA
DAD-NA is NA with the DAD Performed Address in Target Address field and sent
to All Nodes Multicast.

> $B?@L@C#:H(B wrote:

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 13 Jul 2004 21:13:22 +0900

>>>>> On Mon, 12 Jul 2004 22:16:41 -0400 (EDT), 
>>>>> Suresh Krishnan <[email-masked]> said:

> 	I have a few comments regarding 2462bis.

Thanks for the review and the comments.

In short, I'll update the draft for the first point.  At the moment I
don't see the need for a revise for the rest.

> algorithm is described in the address architecture RFC [RFC3513]

Good catch!  Apparently this is an error when the specification was
updated from RFC1971 to RFC2462.  I'll correct this point in the next
revision of rfc2462bis.

>    the tentative address containing the tentative address in the Target

No, because "the other packet" is unicasted to the tentative address
while DAD NA/NS are multicasted.  I think this should be clarified in
the following part:

   ...
   Address field. Such a case should not happen in normal operation,
   though, since these messages are multicasted in the Duplicate Address
   Detection Procedure.

And I do not see the need for further clarification.

> solicitation for this address.

No, because this part is written under the assumption described in the
first paragraph of Section 5.4.3:

   On receipt of a valid Neighbor Solicitation message on an interface,
   node behavior depends on whether the target address is tentative or
   not.  If the target address is not tentative (i.e., it is assigned to
   the receiving interface), the solicitation is processed as described
   in RFC 2461 [5].  If the target address is tentative, and the source
   address is a unicast address, the solicitation's sender is performing
   address resolution on the target; the solicitation should be silently
   ignored.  Otherwise, processing takes place as described below. In
             ^^^^^^^^^
   all cases, a node MUST NOT respond to a Neighbor Solicitation for a
   tentative address.

> and not here as they are not specific to autoconfiguration. Probably these 

I don't think the duplication is redundant in the first place, since
the processes of ND and autoconf can be done separately.  For example,
RFC2461 says in Section 6.3.4 that:

      Note: Implementations can choose to process the on-link aspects of
      the prefixes separately from the address autoconfiguration aspects
      of the prefixes by, e.g., passing a copy of each valid Router
      Advertisement message to both an "on-link" and an "addrconf"
      function.  Each function can then operate independently on the
      prefixes that have the appropriate flag set.

Besides, bullet c) does not seem to be duplicate with RFC2461.
rfc2461bis clarified this point (maily) from the sender (router) side,
but it still does not contain the validity check at the receiver's
side (and I think it's intentional).

> it. Maybe it makes sense to add an informative reference to it.

I don't think so.  There is actually no appropriate difference since
this was discussed in the update work from RFC1971 to RFC2462.  And,
in fact, detailed explanation about the attack is provided in bullet
e).

					JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 13 Jul 2004 11:31:50 -0400 (EDT)

Hi Jinmei,
  See comments inline.

Thanks
Suresh

On Tue, 13 Jul 2004, JINMEI Tatuya / [ISO-2022-JP] 

>updated from RFC1971 to RFC2462.  I'll correct this point in the next

==> Sounds good.

>And I do not see the need for further clarification.

==> I see your point but this is still fuzzy. 
This is what it says
====================
"Note that the "other packets" include Neighbor Solicitation
 and Advertisement messages to the tentative address containing the
 tentative address in the Target Address field."

This is what it actually means
==============================
"Note that the "other packets" include Neighbor Solicitation
 and Advertisement messages with the tentative address as the IP 
destination address and contain the tentative address in the 
Target Address field."

>> If another node is simultaneously doing DAD on the same tentative 
address 
>   all cases, a node MUST NOT respond to a Neighbor Solicitation for a

==> Mea culpa. Did not see that the processing stops there when the 
destination is unicast.

>      prefixes that have the appropriate flag set.

==> I disagree. check out the following text in RFC2461bis in section 
4.6.2 under the definition of prefix information option.

"A router SHOULD NOT send a prefix
 option for the link-local prefix and a host SHOULD
 ignore such a prefix option"

Note that this is an unqualified statement. The processing of the prefix 
information whether it is for on-link or addrconf functions must obey 
this.

>side (and I think it's intentional).

==> I don't think 2461bis differentiates between sending and receiving in 
this regard. 2461bis specifies the format of the prefix information 
option in section 4.6.2. The contents of this option field specify that 
that preferred lifetime MUST NOT be greater than valid lifetime

"Preferred lifetime ...
 Note that the value of this field MUST NOT exceed
 the Valid Lifetime field to avoid preferring
 addresses that are no longer valid."

>in fact, detailed explanation about the attack is provided in bullet

==> OK. I was more interested about the rationale behind choosing the 2 
hour magic number sice the Max possible interval between router 
advertisements is 30 minutes.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 13 Jul 2004 19:23:04 -0400 (EDT)

Hi Mr.Rao,
  See comments inline.

Thanks
Suresh

>OLN ===> Destination Address is not Tentative Address here

==>I did not see the word destination address mentioned in the paragraph. 
Maybe that is the intention but it is not mentioned explicitly. See my 
other mail to Jinmei Tatuya regarding the wording of this sentence and 
let me know if you disagree. 

>                  to a *not-yet-assigned* address.

==> True, but besides the point. I was in no way implying that the 
stack must or must not do that. Again, please check my reply to Jinmei 
Tatuya and see if you disagree. It was just a question of fuzzy wording. 

>
>>
>> Section 5.4.3 Page 15 bullet point number 1 sqytarting with "If a 
Neighbor
>DAD-NA is NA with the DAD Performed Address in Target Address field and sent

==> I was not talking about the vanilla case. This was the case I was 
talking about.

Assume there are three nodes A, B and C. Let's say node A has 
autoconfigured address "x" and is trying to do a DAD for it. Node B has 
this address assigned to one of its interfaces and node C is trying to 
communicate to node B. It will send a NS to the solicited-node multicast 
address of "x" which both A and B will receive.  

This is no longer an issue for me since Jinmei Tatuya clarified this in 
his previous mail. If the source address of the NS is an unicast the 
reception procedure terminates immediately and does not continue to check 
other cases. This is the part I misunderstood.

<snipped>

---

From: "O.L.N.Rao" <[email-masked]>
Date: Wed, 14 Jul 2004 10:09:22 +0530

Hi Suresh,

    See comments inline :)

Thanks,
O.L.N. Rao

----- Original Message ----- 
From: "Suresh Krishnan" <[email-masked]>
To: "O.L.N.Rao" <[email-masked]>
Cc: "Suresh Krishnan" <[email-masked]>; <[email-masked]>;
"JINMEI Tatuya / 神明達哉" <[email-masked]>
Sent: Wednesday, July 14, 2004 4:53 AM
Subject: Re: Comments on RFC2462bis

Hi Mr.Rao,
  See comments inline.

Thanks
Suresh

On Tue, 13 Jul 2004, O.L.N.Rao wrote:

>To: "JINMEI Tatuya / ç¥zæ~Zé"å"?" <[email-masked]>
>Cc: <[email-masked]>

>let me know if you disagree.

OLN ==> You are right. No mention of "Destination Address".
May be I have got the meaning directly as I have implemented it :).

>Tatuya and see if you disagree. It was just a question of fuzzy wording.

OLN ==> I agree here too.  For the new reader, this paragraph is not giving
the direct intended meaning.

Neighbor

OLN ==> hmm...fine.. In this case
OLN ==> [AR - Address Resolution]
OLN ==> DAD-NS and AR-NS are just different only in SOURCE Address.
OLN ==> Anyway by this time, you might have got this difference.

[PS : DAD-NA & AR-NA are different only in DESTINATION Address, FYI]

<snipped>

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 14 Jul 2004 22:55:32 +0900

>>>>> On Tue, 13 Jul 2004 11:31:50 -0400 (EDT), 

>>> isn't this self contradictory

(snip)

>> while DAD NA/NS are multicasted.  I think this should be clarified in

(snip)

> This is what it actually means

Okay, while I don't think the current wording is that fuzzy, I admit
the text could be improved.  I'll replace the current sentence with
the latter one.

> information whether it is for on-link or addrconf functions must obey 

I see the point, but I still strongly believe rfc2462bis should have
the complete list of checks despite the duplication.  Implementors
will read rfc2462bis (or do read RFC2462) Section 5.5.2, and will
implement the listed checks one by one.  If we omit bullet (b) (check
for the link-local prefix) just due to the duplicate description with
RFC2461 (or rfc2461bis), they might miss implementing this part.

In any event, as long as the duplicate part is consistent (and it
actually is), it's a tradeoff issue and a matter of sense whether we
should leave it in both the documents or we should only describe it
once.  In this particular case, I strongly believe it is much more
helpful to have the check in rfc2462bis explicitly.

I guess you can also live with this policy since you said the
duplicate check "can" be removed.  If so, please let me leave this
bullet as is.

If we can agree here, we'd not need to discuss more about bullet c,
but I'll answer the following part just in case (and since this might

>  addresses that are no longer valid."

Believe me, I know rfc2461bis (or at least the original intent)
differentiates these since it was me who originally raised this issue
1.5 years ago.  See
  http://www.atm.tut.fi/list-archive/ipng/msg07250.html
and its follow-ups for the past discussion.

The consensus in the discussion was:

- routers MUST NOT send a prefix with preferred lifetime > valid
  lifetime
- it doesn't matter whether a host accepts or ignores such a prefix
  information option for on-link determination (i.e., in terms of
  RFC2461)
- RFC2462 is already clear on the host's behavior in its scope: hosts
  should ignore such a prefix information option

but...hmm, perhaps the description in Section 4.6.2 of rfc2461bis is
overspecification in terms of the above consensus: the restriction for
AdvPreferredLifetime (Section 6.2.1) is probably enough and the "MUST
NOT" rule in Section 4.6.2 should probably be removed.

>> I don't think so.  There is actually no appropriate difference since
                                                       ^^^^^^^^^^oops...I
meant "reference" here.

> advertisements is 30 minutes. 

I think the current text has enough information to be published
(actually it was not changed from RFC2462), but I understand one may
want to know the rationale.  I don't quite remember the past
discussion on this, but if someone can provide that information, I'm
willing to add that to rfc2462bis.

					JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 15 Jul 2004 12:59:29 -0400 (EDT)

Hi Jinmei,
  I am happy with all the resolutions you proposed. I looked through the 
mailing list archives but I was not able to find the rationale behind 
picking 2 hours. Probably it is there so that we can miss 3 RAs at 
maximum intervals and still get a proper valid lifetime.

Thanks
Suresh

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 16 Jul 2004 17:40:25 +0900

>>>>> On Thu, 15 Jul 2004 12:59:29 -0400 (EDT), 

> maximum intervals and still get a proper valid lifetime.

Okay, thanks for searching for the information.

You're probably correct on the rationale, but I won't do anything on
this in rfc2462bis since we do not have a specific pointer about the
original intent (sorry about that).

					JINMEI, Tatuya