[rrg] [ILNP] What to do when Locator Updates are lost
Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 16 July 2012 13:48 UTC
Return-Path: <bortzmeyer@nic.fr>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2083D21F8842 for <rrg@ietfa.amsl.com>; Mon, 16 Jul 2012 06:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.133
X-Spam-Level:
X-Spam-Status: No, score=-101.133 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmHMSPCbLIJQ for <rrg@ietfa.amsl.com>; Mon, 16 Jul 2012 06:48:50 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 807D221F883D for <rrg@irtf.org>; Mon, 16 Jul 2012 06:48:50 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 29246280292 for <rrg@irtf.org>; Mon, 16 Jul 2012 15:49:01 +0200 (CEST)
Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 258272801BD for <rrg@irtf.org>; Mon, 16 Jul 2012 15:49:01 +0200 (CEST)
Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id 231DD4C007F for <rrg@irtf.org>; Mon, 16 Jul 2012 15:48:31 +0200 (CEST)
Date: Mon, 16 Jul 2012 15:48:31 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: rrg@irtf.org
Message-ID: <20120716134830.GB15195@nic.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Operating-System: Debian GNU/Linux wheezy/sid
X-Kernel: Linux 3.2.0-2-686-pae i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [rrg] [ILNP] What to do when Locator Updates are lost
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 13:48:51 -0000
Another philosophical question on ILNP. draft-irtf-rrg-ilnp-eng-06 and draft-irtf-rrg-ilnp-icmpv6-06 do not mention what to do when a Locator Update (which is, after all, just an ordinary ICMP message) is lost. There is no mention of retrying (DNS-style). Retrying could be triggered by the absence of a Locator Update Acknowledgement but both drafts say nothing about the use of Acknowledgements. draft-irtf-rrg-ilnp-noncev6-06 says: Hence, the node that has had all previously valid Locators become invalid MUST include the Nonce Option with the appropriate nonce value in all packets (data or otherwise) to all correspondents for at least 3 round-trip times for each correspondent. [...] This 'gratuitous authentication' ensures that the correspondent can authenticate any received packet, even if the ICMP Locator Update control message arrives and is processed AFTER some other packet using the new Source Locator(s). But this covers only the case where the Locator Update is delayed, not the case where it is lost. Or should a node update its ILCC when receving these 'gratuitous authentication' packets with a new Source Locator? I do not find any explicit mention of it.
- [rrg] [ILNP] What to do when Locator Updates are … Stephane Bortzmeyer
- [rrg] [ILNP] What to do when Locator Updates are … Ran Atkinson
- Re: [rrg] [ILNP] What to do when Locator Updates … Stephane Bortzmeyer