Re: [dna] Review of draft-ietf-dna-simple-11

"Bernard Aboba" <> Tue, 24 November 2009 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3FFE3A6816 for <>; Tue, 24 Nov 2009 10:18:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h26XPW+pYnxB for <>; Tue, 24 Nov 2009 10:18:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 18DF23A67C1 for <>; Tue, 24 Nov 2009 10:18:12 -0800 (PST)
Received: from BLU137-DS7 ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 10:18:07 -0800
X-Originating-IP: []
X-Originating-Email: []
Message-ID: <BLU137-DS7F1790D475CB4996E045E939D0@phx.gbl>
From: "Bernard Aboba" <>
To: "'Ted Lemon'" <>, <>
References: <>
In-Reply-To: <>
Date: Tue, 24 Nov 2009 10:18:20 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcptLuTq2KBG1odbSZW5OOLQvFqBIQAAxuQg
Content-Language: en-us
X-OriginalArrivalTime: 24 Nov 2009 18:18:07.0385 (UTC) FILETIME=[78AC9890:01CA6D32]
Subject: Re: [dna] Review of draft-ietf-dna-simple-11
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2009 18:18:13 -0000

Ted Lemon said:

"More, from section 4.3:

  It SHOULD also set all Neighbor
  Cache entries for the routers on its Default Router List to STALE.
  This is done to speed up the acquisition of a new default router when
  link change has occurred.

It's my impression that by default, a stale routing table entry won't
be used, so if an application writes to an open tcp connection while
the routing table entry is stale, it will get an EHOSTUNREACH, and the
connection will be dropped.  I have had this exact experience with
IPv4 DNA implementations when my WiFi router signal is flaky.  This is
much worse than taking a long time (500ms isn't really that long) to
identify a new link.

This would also be a problem in the case where you are on a WiFi
network with more than one device advertising the same SSID - when you
switch to a new beacon, arguably this is a DNA event, but it would clearly
be a mistake to break existing connections in this case.

[BA] I agree that the paragraph cited does not make sense.  RFC 4436 does
not contain equivalent advice.  In general, Simple DNAv6 should seek to 
minimize connectivity disruption.