Re: [dna] Comments on draft-ietf-dna-protocol
Sathya Narayanan <snarayanan@csumb.edu> Sat, 31 October 2009 22:50 UTC
Return-Path: <snarayanan@csumb.edu>
X-Original-To: dna@core3.amsl.com
Delivered-To: dna@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971CA3A6820 for <dna@core3.amsl.com>; Sat, 31 Oct 2009 15:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level:
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvLBwoIiokrL for <dna@core3.amsl.com>; Sat, 31 Oct 2009 15:50:48 -0700 (PDT)
Received: from exprod5og113.obsmtp.com (exprod5og113.obsmtp.com [64.18.0.26]) by core3.amsl.com (Postfix) with SMTP id 3D9F23A680F for <dna@ietf.org>; Sat, 31 Oct 2009 15:50:48 -0700 (PDT)
Received: from source ([209.85.223.175]) by exprod5ob113.postini.com ([64.18.4.12]) with SMTP ID DSNKSuy/WXVe/xRDRcRhseVcMXoOEvxjunmv@postini.com; Sat, 31 Oct 2009 15:51:07 PDT
Received: by iwn5 with SMTP id 5so2923679iwn.11 for <dna@ietf.org>; Sat, 31 Oct 2009 15:51:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.6.153 with SMTP id 25mr1292756ibz.54.1257029465259; Sat, 31 Oct 2009 15:51:05 -0700 (PDT)
In-Reply-To: <4AEA0FCE.4000704@piuha.net>
References: <4ADE2B90.6060900@ericsson.com> <ba68e8800910210806r44552f9bub5fdb2dac7748d4@mail.gmail.com> <4AEA0FCE.4000704@piuha.net>
From: Sathya Narayanan <snarayanan@csumb.edu>
Date: Sat, 31 Oct 2009 15:50:45 -0700
Message-ID: <ba68e8800910311550n5fb93f74s78a75828125e19e2@mail.gmail.com>
To: Jari Arkko <jari.arkko@piuha.net>
Content-Type: multipart/alternative; boundary="0015176f03e0bfc009047742fae3"
X-Mailman-Approved-At: Mon, 02 Nov 2009 07:23:02 -0800
Cc: DNA <dna@eng.monash.edu.au>, "dna@ietf.org" <dna@ietf.org>
Subject: Re: [dna] Comments on draft-ietf-dna-protocol
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: Sat, 31 Oct 2009 23:16:45 -0000
Jari Thanks for the detailed comments. I wanted to acknowledge the email and let you know that this is on my to-do list; I will work on incorporating your comments on to the document over the next couple of weeks. Worst case, I will need to move it until Thanksgiving break at which point I am likely to have more time to devote to this. Hope that is alright. best Sathya On Thu, Oct 29, 2009 at 2:57 PM, Jari Arkko <jari.arkko@piuha.net> wrote: > Sathya, > > Here are a few comments on draft-ietf-dna-protocol. Overall, this is a > complex scheme and having read this again after a long break, I'm now even > more glad that we got the dna-simple document moving forward. However, I > think we should publish even dna-protocol as an RFC. It is an interesting > design worth a permanent record. I do have a long list of comments, though, > and I hope you can publish a new draft version so that the document can be > taken forward. I'm thinking of Historical or Experimental as the proper > designation for the document. > > Detailed comments: > > The document needs to be resubmitted as it is currently expired. > > Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 >> Design) >> >> > Might be better as "Design Alternative for Detecting ..." > > Abstract is too long. Maybe you should just keep this part: > > In this memo, a mechanism > that was developed for detection of network attachment is documented > for future reference. This memo is an informational document and > thus does not define a new standard. The mechanism proposed in this > informational RFC requires the hosts to monitor all the prefixes > advertised on the link and use it for link identification in the > presence of non-DNAv6 routers is presented. A more efficient link- > identification mechanism requiring the DNAv6 routers to monitor the > link for advertised prefixes to assist the hosts in link > identification combined with a fast router advertisement mechanism > that selects the order of response for the router deterministically > is also presented. > > Run spell on the document. > > This memo also defines a mechanism to exchange Source Link-Layer Address >> without affecting the neighbor caches when the host is performing Optimistic >> DAD. >> >> > > Wasn't this already in draft-ietf-dna-tentative? > > Even though this >> document recommends the use of a prefix as the representative of the >> link, future specifications can use the Learned Prefix Option to >> include a non-prefix identifier as long as this identifier is 128 bit >> long to avoid collision with any currently assigned prefix. So, any >> future non-prefix link identifier MUST be 128 bits long. >> 5.1.6.3.1 Using non-prefix identifier as common prefix >> > > I felt that this extensibility confused the document a little bit. Could > this be removed? > > DNAv6 avoids this delay by using a different mechanism to ensure that >> two routers will not respond at exactly the same time while allowing >> one of the routers on the link to respond immediately. The results of >> that function are then compared to create >> a ranking, and the ranking determines the delay each router will use >> when responding to the RS. The router which is ranked as #0 will >> respond with a zero delay. >> >> > > Do I understand correctly that there will still be several responses to a > single RS? Perhaps this should be highlighted. Note that that your scheme > does not provide the same overall limit on the number of RAs appearing on > the link as the rate limit defined in RFC 4861. > > 4.1 New Flags >> >> This document defines two new flags to be exchanged between the >> router and hosts. >> > I'd like to see these flags in the extension option defined in RFC 5075, > not directly in the RA header. > > the following information MUST be stored: >> >> 1. Link-local source address of advertising router >> >> 2. Token equal to the first 64 bits of an SHA-1 hash of the above address >> >> > It seems a bit silly to have a MUST requirement to store X and f(X)... > > Each router MUST include itself in the DNARouterList and generate a >> token for itself as described above based on the link-local address >> used in its RA messages. >> >> > As above. > > an abbreviated Router Advertisement.This abbreviated advertisement >> > > Missing space > > A CompleteRA is formed as follows: >> > > Missing space > > Note that this smallest prefix >> is the smallest of all the prefixes configured on the routers on the >> link and may not be the smallest prefix used in the link through >> stateful address configuration. >> >> > > Although, at least currently, prefixes used even for stateful address > autoconfiguration come from RAs. > > > When a router receives a new prefix in PIO, if the prefix is smaller >> than the current common prefix and has valid lifetime greater than >> LEAST_VALID_LIFETIME, the router selects that new prefix as a new >> common prefix. >> > But it is also possible that the new smallest prefix comes through > configuration in THIS router. In that case it is not the reception of the > PIO that triggers this selection. > > Whenever a router sends an RA, whether solicited or unsolicited, it >> MUST include the common prefix in it. Hence, all RAs MUST carry the >> common prefix except the abbreviated RA message sent in response to a >> RS with LO. >> > > I guess I am missing the point of having BOTH the landmark AND the common > prefix. Is there some difference in use that prevents just selecting one, > and sticking to that? > > And if the RAs responding to LO can skip the common prefix, why is it so > important to include the common prefix in other RAs? Important enough that a > MUST is needed? Or, if the MUST is really needed, is there something that > breaks when use just the landmark option? > > Sinice information from the Learned Prefix Option is only stored in >> > typo > > IF (Receive RA is a CompleteRA) THEN >> >> { >> >> /* We already checked if there are any matching prefix before. >> Since this is a CompleteRA, implies link-change.*/ >> >> Link change has occured. >> >> RETURN; // Don't have to do the following checks. >> >> } >> >> { >> >> Link change has occured. >> >> RETURN; // Don't have to do the following checks. >> >> } --> >> >> IF (DNAHostPrefixList is marked as complete (i.e. the completeness >> criteria is already met)) THEN >> >> > > The code seems broken. Is there an IF missing around the braces above? > There seems to be a RETURN followed by some further code, which does not > make sense. > > Wait for NUM_RS_RA_COMPLETE exchanges of RS/RA message to be done >> since the previous link UP event (Previous link UP event here refers >> to the link UP received before the current link UP event that lead to >> this processing). >> >> IF (One of the received RA contains a prefix matching a prefix in >> DNAHostPrefixList from before the current link UP event), THEN No >> link change has occured ELSE link change has occured. >> >> > > Pseudo-code style changed here. Please use the same style, braces etc. > > Note that this procedure does not prevent a MN from sending packets >> > s/MN/host/ > > > Missing things: I did not see a discussion of how prefixes or routers get > removed from the host or router data structures. > > received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA >> > > It seems weird that you refer to the old 2461 here. Also, is the procedure > presented in Section 5.2.7.3 according to the current understanding of the > M&O bits? > > 6.3 Tentative options >> > If you refer to draft-ietf-dna-tentative, do you need this section? > > SEND says that DAD defenses MAY be accepted even from non SEND nodes >> > > ... according to the SEND specification (RFC 3971 Section N.N) DAD defenses > ... > > SEND says that DAD defenses MAY be accepted even from non SEND nodes >> for the first configured address [4]. >> >> While deconfiguring the address is a valid action in the case where a >> host collides with another address owner after arrival on a new link, >> In the case that the host returns immediately to the same link, such >> a DAD defense NA message may be a denial-of-service attempt. >> >> > It seems that there are two separate cases. I believe 3971 & 3972 still > hold: whenever you create a new address, you should not accept collisions > beyond a certain collision count. However, IF you have confirmed that you > re-attached to the same link... I would not run DAD. > > 10. Informative References >> > > You need to split references to normative and informative. > > [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery >> for IP Version 6 (IPv6)", RFC 2461, December 1998. >> >> > > Refer to the new one instead. > > Jari > > -- Sathya Narayanan mailto://snarayanan@csumb.edu <=== Please note new email address
- [dna] Comments on draft-ietf-dna-protocol Jari Arkko
- Re: [dna] Comments on draft-ietf-dna-protocol Sathya Narayanan
- Re: [dna] Comments on draft-ietf-dna-protocol Sathya Narayanan