[dna] Comments on draft-ietf-dna-simple-11
Erik Nordmark <erik.nordmark@sun.com> Thu, 10 December 2009 11:22 UTC
Return-Path: <erik.nordmark@sun.com>
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 2C0213A6AF8 for <dna@core3.amsl.com>; Thu, 10 Dec 2009 03:22:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, 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 rTUzkCo0g3lU for <dna@core3.amsl.com>; Thu, 10 Dec 2009 03:22:47 -0800 (PST)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id F3A023A67E4 for <dna@ietf.org>; Thu, 10 Dec 2009 03:22:46 -0800 (PST)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBABMUl7015132; Thu, 10 Dec 2009 11:22:30 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nBABMQ2t164761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 03:22:29 -0800 (PST)
Message-ID: <4B20D9A2.70406@sun.com>
Date: Thu, 10 Dec 2009 03:21:06 -0800
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090929)
MIME-Version: 1.0
To: dna@ietf.org, Suresh Krishnan <suresh.krishnan@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [dna] Comments on draft-ietf-dna-simple-11
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: Thu, 10 Dec 2009 11:22:48 -0000
Bernard's question about STALE made me carefully read the whole document. A few comments and questions. --- Section 2.2 says When a host moves to a completely new link that is previously unknown, the performance of the Simple DNA protocol will be identical to that using standard neighbor discovery procedures [RFC4861]. I don't think this was the intent. The default timers in RFC 4861 means that a host that implements that to the letter will retain the global IPv6 addresses from the old link for 30 days, and retain the old set of default routers 30 minutes. AFAIK the intent is that a DNA host flush information related to the old link when it determines that it has moved to a new link. (Alternatively, flush information learned from a particular router when DNA detects that that router is gone.) In fact, section 4.8 specifies that the addresses in the SDAT must be unconfigured. But we also need to specify what should be done to the default router list, the prefix list, and to Neighbor Cache Entries for link-local addresses (such a addresses might be duplicated between the old and the new link). For the link-local NCEs we can either mark them as STALE or just discarding them. If we do that, then we don't need the STALE text in section 4.3; the state of the NCEs can remain unchanged while the host sends the NS and/or DHCP packets. --- Section 4.1 defines the SDAT and says it contains o Link-local IPv6 address of the router that advertised the prefix. o Link-layer (MAC) address of the router that advertised the prefix. That doesn't specify how things are supposed to work when there is more than one router that advertises the same prefix; a common configuration on LANs. I think it should say "router or routers" above. I wonder if it makes sense to add some more text in section 4.1 to specify that when multiple routers advertise the same prefix a host should independently remove those routers from the SDAT when they stop advertising the prefix. That requires tracking in the SDAT the last time the prefix was heard from each router that advertises it. Related to this is the text in section 4.4 in how the SDAT is used. I suggest that paragraph in 4.4 say something like this: For each of the addresses in the candidate set, the host looks up the SDAT to find out the link-local and MAC addresses of the router or routers that advertised the prefix used to form the address. If multiple routers have advertised the same prefix the host needs to select one router per SDAT; it is RECOMMENDED that it select the router that most recently advertized the prefix. It then sends an unicast Neighbor Solicitations for each candidate SDAT. It is sent to the selected router's link-local address. The host SHOULD NOT send unicast Neighbor Solicitations to a test node corresponding to an IPv6 address that is no longer valid. (BTW: I don't understand what a "test node" is hence I don't understand the last sentence above that I copied from the draft, so I left it alone.) --- We had talked about the SDAT retaining information from previously visited links but the document is rather silent on the whole area of SDAT management; when are things added and deleted from the SDAT? If a host is allowed to retain the SDAT until the prefixes time out (or the default router lifetime times out?) then we should say that somewhere in the document. --- Section 4.7 says before utilizing the configuration associated with the detected network (prefixes, MTU etc.). That wording implies that the host had somehow stopped using the state earlier, but there is no text in the documenting saying it should stop using the state before the probing. I think we can *describe* the same protocol behavior in two different ways: 1. The host stops using all information (prefixes, default routers, NCEs) when it gets the link-up indication. As a result of gathering the results it will reinstate (possibly a subset) of that information. If the host remembers SDAT information from previous links it will reinstate that information when it receives a NA or RA from that router (matching source MAC and source IP address). 2. The host continues as normal while sending the probes. As it gathers the results it might conclude that the information currently used is no longer valid. If it hears from an old router it will reinstate information from that router. The above text in 4.7 seems to assume description #1 (but the "stop using" part is missing from the document) but the text in section 4.8 about removing addresses assume #2. We should use a single way to describe this in the document. --- Section 4.8 has what is either a typo or a fundamental misunderstanding. It says o The host SHOULD select a default router as described in [RFC4861]. But RFC 4861 doesn't talk about selecting *a* default router; it specifies that hosts maintain a default router list. Thus I don't know what the above bullet is trying to convey. Can it be removed? --- Question on this text in 4.7: When the host receives an advertisement containing only prefixes which are disjoint from known advertised prefixes, the host MUST determine whether the solicited advertisement corresponds to any of the routers probed via NS. If it does, then the host SHOULD conclude that the IPv6 addresses corresponding to that router are no longer valid. Since any NS probes to that router will no longer provide useful information, further probing of that router SHOULD be aborted. Thus the last sentence imply that the (now incorrect) information for that router should be removed from the SDAT? --- Question: How does a host tell that a RA is sent in response to a a particular host's RS? Section 4.7 says When the host receives a Router Advertisement in reply to the Router Solicitation it sent, ... The only possibility I can think of is when the RA is unicast. If that is the case then it would make sense to add "unicast" to the above text. --- Erik
- [dna] Comments on draft-ietf-dna-simple-11 Erik Nordmark