[dna] comments on draft-ietf-dna-tentative

Jari Arkko <jari.arkko@piuha.net> Fri, 23 October 2009 10:47 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: dna@core3.amsl.com
Delivered-To: dna@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 1A7FE3A682D for <dna@core3.amsl.com>; Fri, 23 Oct 2009 03:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id FEDN62hQoKqX for <dna@core3.amsl.com>; Fri, 23 Oct 2009 03:47:37 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AE74F3A6828 for <dna@ietf.org>; Fri, 23 Oct 2009 03:47:36 -0700 (PDT)
Received: from localhost (localhost []) by p130.piuha.net (Postfix) with ESMTP id F15B4D4949; Fri, 23 Oct 2009 13:47:46 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([]) by localhost (p130.piuha.net []) (amavisd-new, port 10024) with ESMTP id rfXbRIa-H3es; Fri, 23 Oct 2009 13:47:45 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CA57AD4904; Fri, 23 Oct 2009 13:47:45 +0300 (EEST)
Message-ID: <4AE189D1.2080907@piuha.net>
Date: Fri, 23 Oct 2009 13:47:45 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird (X11/20090817)
MIME-Version: 1.0
To: draft-ietf-dna-tentative@tools.ietf.org, Greg Daley <gdaley@netstarnetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: DNA <dna@eng.monash.edu.au>, "dna@ietf.org" <dna@ietf.org>
Subject: [dna] comments on draft-ietf-dna-tentative
X-BeenThere: dna@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <dna.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dna>
List-Post: <mailto:dna@ietf.org>
List-Help: <mailto:dna-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2009 10:47:38 -0000

Here are a few comments on this draft. Overall, this document is in 
reasonable shape, but contained a number of small errors.

Detailed comments:

First, which status would this document be published with? 
Historic/Informational as in the case of draft-ietf-dna-protocol? Or 
something else?

Second, the document needs to be re-submitted to the directories before 
I can enter it to the tracker.

> In a case where it is safe to send a Source Link-Layer Address
> Option, a host SHOULD NOT send a TO, since the message may be
> misinterpreted by legacy nodes.
> Importantly, a node MUST NOT send a Tentative Option in the same
> message where a Source Link-Layer Address Option is sent
> Any Router Solicitation from a Preferred, Deprecated or Optimistic
> address MAY be sent with a Tentative Option [RFC4429 <http://tools.ietf.org/html/rfc4429>].

Aren't these two text excerpts in conflict with each other? RS typically 
includes a SLLA, so normally we would not be able to use a TO based on 
the rule in the earlier text. Also, if the source address is Preferred 
or Deprecated, an SLLA can be used and per the earlier rule, should not 
be used.

> An extension which allows Router Solicitations to be sent with a TO
> from the unspecified address is described in Appendix C <http://tools.ietf.org/html/draft-ietf-dna-tentative-02#appendix-C>.

I understood from Greg that this has not been implemented. Does it make 
sense to remove it from the draft as well?

> For standardization, this document requires that the IANA allocate
> the Tentative Option for link-layer addressing (Section Section 2.1 <http://tools.ietf.org/html/draft-ietf-dna-tentative-02#section-2.1>)
> from the IPv6 Neighbour Discovery options for IPv6.
This document asks the IANA to allocate ...

> Previous (older) experimental implementations have used the value
> 0x11 (17) for the Tentative Option, before the IPv6 Neighbour
> Discovery experimental range was defined [RFC4727 <http://tools.ietf.org/html/rfc4727>].
This value does not appear to be free anymore, according to 

I would suggest deleting this paragraph.

> The use of the Tentative Option in Neighbour and Router Solicitation
> messages acts in a similar manner to SLLAO, updating neighbour cache
> entries, in a way which causes packet transmission.

Did you mean "affects the transmission of subsequent packets"?

> Particular care should be taken that transmission of messages
> complies with existing IPv6 Neighbour Discovery Procedures, so that
> unmodified hosts do not receive invalid messages.
I'm not sure what you are asking for here.

Missing things: the document should clearly state somewhere how you deal 
with legacy nodes that do not implement this RFC. My understanding is 
that since unknown options are ignored, the resulting behaviour is 
equivalent to sending an ND message without SLLAO (which is the current 
behaviour with standard ND anyway). Correct?