[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