From dna-owner@webcamserver.eng.monash.edu.au Fri Jan 13 07:59:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExOWK-00029v-6e for dna-archive@megatron.ietf.org; Fri, 13 Jan 2006 07:59:08 -0500 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03046 for ; Fri, 13 Jan 2006 07:57:45 -0500 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LXQHEBS4K69AUXSA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 13 Jan 2006 23:58:13 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3E0BBAB55C; Fri, 13 Jan 2006 23:58:09 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id ED6664FB11; Fri, 13 Jan 2006 23:58:08 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k0DCrml27449 for dna-list; Fri, 13 Jan 2006 23:53:48 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k0DCrmu27444 for ; Fri, 13 Jan 2006 23:53:48 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LXQH8M25JC9IJFVT@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 13 Jan 2006 23:53:33 +1100 Received: by localhost (Postfix, from userid 510) id EEA2AAB559; Fri, 13 Jan 2006 23:53:32 +1100 (EST) Received: from iramx1.ira.uni-karlsruhe.de (iramx1.ira.uni-karlsruhe.de [141.3.10.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 9A75E4FB03 for ; Fri, 13 Jan 2006 23:53:31 +1100 (EST) Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ExOQj-0007id-1u for ; Fri, 13 Jan 2006 13:53:27 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id E2B7D7E2E for ; Fri, 13 Jan 2006 13:53:20 +0100 (CET) Date: Fri, 13 Jan 2006 13:53:20 +0100 From: Christian Vogt Subject: [DNA] Delay Analysis for Handoffs with Mobile IPv6 Route Optimization Sender: owner-dna@ecselists.eng.monash.edu.au To: DNA Message-id: <43C7A2C0.20309@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Transfer-Encoding: 7BIT I would like to call your attention on work that we have done on IPv6 handoff procedures: "A Comprehensive Delay Analysis for Reactive and Proactive Handoffs with Mobile IPv6 Route Optimization" http://doc.tm.uka.de/2006/vogt-2006-delay-analysis-for-reactive-and-proactive-handoffs.pdf Abstract: Optimizations to reduce handoff delays inherent in Mobile IPv6 Route Optimization as well as IPv6 router discovery, address configuration, and movement detection have so far been mostly considered on an individual basis. This document evaluates three integrated solutions for improved handoff experience in surroundings with different preconditions: reactive handoffs with unmodified routers, reactive handoffs with router support, and movement anticipation and proactive handoff manage- ment. Your feedback will be welcome! Regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 16 09:21:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyVEU-00029U-Q7 for dna-archive@megatron.ietf.org; Mon, 16 Jan 2006 09:21:18 -0500 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16050 for ; Mon, 16 Jan 2006 09:19:52 -0500 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LXUR3ORKVU9AV6JC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 17 Jan 2006 01:19:09 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DACA8AB543; Tue, 17 Jan 2006 01:19:03 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 8A5CE4FB29; Tue, 17 Jan 2006 01:19:03 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k0GEH4J15522 for dna-list; Tue, 17 Jan 2006 01:17:04 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k0GEH3u15518 for ; Tue, 17 Jan 2006 01:17:03 +1100 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LXUR0VD97S9IK52L@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 17 Jan 2006 01:16:48 +1100 Received: by localhost (Postfix, from userid 510) id 7608680002; Tue, 17 Jan 2006 01:16:48 +1100 (EST) Received: from iramx1.ira.uni-karlsruhe.de (iramx1.ira.uni-karlsruhe.de [141.3.10.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 1A4043C017 for ; Tue, 17 Jan 2006 01:16:47 +1100 (EST) Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1EyV9t-0006Zd-AI for ; Mon, 16 Jan 2006 15:16:41 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 396FA8BC0 for ; Mon, 16 Jan 2006 15:16:33 +0100 (CET) Date: Mon, 16 Jan 2006 15:16:33 +0100 From: Christian Vogt Subject: [DNA] EBU/CBA Implementation Sender: owner-dna@ecselists.eng.monash.edu.au To: DNA Message-id: <43CBAAC1.2080000@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Transfer-Encoding: 7BIT Everybody, here is a link to our software implementation of Early Binding Updates and Credit-Based Authorization: http://www.tm.uka.de/~chvogt/ebucba/ The implementation is a patch for the Kame- Shisa Mobile IPv6 software, version 20050822, for FreeBSD 5.4. Kind regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ From dna-owner@webcamserver.eng.monash.edu.au Fri Jan 20 04:27:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzsY6-00009f-4l for dna-archive@megatron.ietf.org; Fri, 20 Jan 2006 04:27:14 -0500 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24731 for ; Fri, 20 Jan 2006 04:25:45 -0500 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LY0223ITCU9IKRZD@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 20 Jan 2006 20:26:35 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9534EAB545; Fri, 20 Jan 2006 20:26:19 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 34EF54FB21; Fri, 20 Jan 2006 20:26:19 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k0K9NrG13587 for dna-list; Fri, 20 Jan 2006 20:23:53 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k0K9Nqu13583 for ; Fri, 20 Jan 2006 20:23:52 +1100 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LY01XRT2A2ANBSTZ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 20 Jan 2006 20:23:37 +1100 Received: by localhost (Postfix, from userid 510) id 7A088AB544; Fri, 20 Jan 2006 20:23:37 +1100 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 97BF54FB1D for ; Fri, 20 Jan 2006 20:23:35 +1100 (EST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ITD002RTWQDGL@mailout3.samsung.com> for dna@eng.monash.edu.au; Fri, 20 Jan 2006 18:23:01 +0900 (KST) Received: from jinchoe ([75.2.91.245]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0ITD009H5WQCEM@mmp2.samsung.com> for dna@eng.monash.edu.au; Fri, 20 Jan 2006 18:23:01 +0900 (KST) Date: Fri, 20 Jan 2006 18:23:00 +0900 From: JinHyeock Choi Subject: [DNA] [Announce] CPL I-D Update Sender: owner-dna@ecselists.eng.monash.edu.au To: DNA Message-id: <01ee01c61da3$1ba7bbd0$f55b024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <43CBAAC1.2080000@tm.uka.de> Content-Transfer-Encoding: 7BIT Dear DNA Group We have updated and submitted the following draft. DNA with unmodified routers: Prefix list based approach draft-ietf-dna-cpl-02.txt Main changes are First, we made it clear that a host is recommended to declare its Prefix List complete after 1 RS/ RA exchange. Also we added a text about why we recommend such. Second, we try to make the definition of "successful exchange" more precise in section 4.1. Third, we made a few editorial changes. For example, we used PoA (Point of Attachment) instead of attachment point in accordance with Bernard's DNAv4 draft. Currently this document is available at the URL: http://www.diffeo.com/drafts/draft-ietf-dna-cpl-02.txt CPL was around for a while, so we wish to advance it to WG last call soon (hopefully till Dallas meeting). We are looking forward to your feedback. Best Regards JinHyeock Choi and Erik Nordmark (Authors) From dna-owner@webcamserver.eng.monash.edu.au Fri Jan 20 15:54:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03Gi-0004LT-Jj for dna-archive@megatron.ietf.org; Fri, 20 Jan 2006 15:54:00 -0500 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18368 for ; Fri, 20 Jan 2006 15:52:31 -0500 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LY0PYLT8WG9AUV0B@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 21 Jan 2006 07:51:35 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 43F3EAB577; Sat, 21 Jan 2006 07:51:29 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id BF2E24FB1D; Sat, 21 Jan 2006 07:51:28 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k0KKoGT21266 for dna-list; Sat, 21 Jan 2006 07:50:16 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k0KKoGu21262 for ; Sat, 21 Jan 2006 07:50:16 +1100 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LY0PWY7SLW9C545J@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 21 Jan 2006 07:50:09 +1100 Received: by localhost (Postfix, from userid 510) id 6A2B9AB544; Sat, 21 Jan 2006 07:50:09 +1100 (EST) Received: from newodin.ietf.org (unknown [132.151.6.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id A32BC4FB1F for ; Sat, 21 Jan 2006 07:50:06 +1100 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F03Cs-0003UK-FG; Fri, 20 Jan 2006 15:50:02 -0500 Date: Fri, 20 Jan 2006 15:50:02 -0500 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-cpl-02.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_AjLGKk+ItRlzBXBrbkhZOw)" X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) --Boundary_(ID_AjLGKk+ItRlzBXBrbkhZOw) Content-type: TEXT/PLAIN Content-Transfer-Encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : DNA with unmodified routers: Prefix list based approach Author(s) : E. Nordmark, J. Choi Filename : draft-ietf-dna-cpl-02.txt Pages : 32 Date : 2006-1-20 Upon establishing a new link-layer connection, a host determines whether a link change has occurred, that is, whether or not it has moved at layer 3 and therefore needs new IP configuration. This draft presents a way to robustly check for link change without assuming any changes to the routers. We choose to uniquely identify each link by the set of prefixes assigned to it. We propose that, at each attached link, the host generates the Complete Prefix List, that is, a prefix list containing all the valid prefixes on the link, and when it receives a hint that indicates a possible link change, it detects the identity of the currently attached link by consulting the existing prefix list. This memo describes how to generate the Complete Prefix List and to robustly detect the link identity even in the presence of packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-cpl-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-cpl-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dna-cpl-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_AjLGKk+ItRlzBXBrbkhZOw) Content-type: multipart/alternative; boundary="Boundary_(ID_2BtAh4HzVxPGJdYkrVP0cA)" --Boundary_(ID_2BtAh4HzVxPGJdYkrVP0cA) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-20125137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-cpl-02.txt --Boundary_(ID_2BtAh4HzVxPGJdYkrVP0cA) Content-type: Message/External-body; name=draft-ietf-dna-cpl-02.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-cpl-02.txt Content-Type: text/plain Content-ID: <2006-1-20125137.I-D@ietf.org> --Boundary_(ID_2BtAh4HzVxPGJdYkrVP0cA)-- --Boundary_(ID_AjLGKk+ItRlzBXBrbkhZOw)-- From dna-owner@webcamserver.eng.monash.edu.au Tue Jan 24 20:53:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ZqQ-0001B7-5A for dna-archive@megatron.ietf.org; Tue, 24 Jan 2006 20:53:10 -0500 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26114 for ; Tue, 24 Jan 2006 20:51:37 -0500 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LY6LL2AIAW9AV8II@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 Jan 2006 12:50:51 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72A32AB604; Wed, 25 Jan 2006 12:50:47 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2A89B4FB0D; Wed, 25 Jan 2006 12:50:47 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k0P1mi730894 for dna-list; Wed, 25 Jan 2006 12:48:44 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k0P1miu30884 for ; Wed, 25 Jan 2006 12:48:44 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LY6LI75TPW9C6D2E@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 Jan 2006 12:48:29 +1100 Received: by localhost (Postfix, from userid 510) id 0E58FAB58C; Wed, 25 Jan 2006 12:48:28 +1100 (EST) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 349094FB03 for ; Wed, 25 Jan 2006 12:48:26 +1100 (EST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0P1mM7m008744 for ; Wed, 25 Jan 2006 03:48:23 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jan 2006 03:47:35 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 19:47:32 -0600 Date: Tue, 24 Jan 2006 17:47:32 -0800 From: Mohan.Parthasarathy@nokia.com Subject: [DNA] comments on draft-ietf-dna-routers-01.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <8A76136424391244A5CF01653370853701201D43@mvebe101.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: comments on draft-ietf-dna-routers-01.txt Thread-Index: AcYhUU69PTrQCkGRQe6x/8QqzpPAig== Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-OriginalArrivalTime: 25 Jan 2006 01:47:32.0826 (UTC) FILETIME=[4F025BA0:01C62151] Content-Transfer-Encoding: 7BIT Hi, I reviewed the draft-ietf-dna-routers-01.txt. I did not find any major issues. Just a few technical comments/questions and Editorials. Technical --------- -In section 1.2, Host wishes to identify if their current prefix is still valid on a link before the prefix expires. Existing IPv6 Neighbour Discovery procedures make this difficult. If the host can determine that the target router is still reachable through a NS/NA exchange, it does not mean that the prefix is still valid. Perhaps, the reason (link-local address) as to why the prefix is not valid can be stated here. -In section 1.3, Routers should include all advertised prefixes within the same RA and indicate whether a previous advertised prefix is not valid anymore. Multiple prefixes advertised in different RAs by a single router may lead to host configurations errors. This section discusses the Router Issues related to RFC 2461 that affects DNA. This parargaph is not talking about the issue but a solution. - Section 1.4 looks more like applicability statement than Summary. It does not seem to be summarizing anything :-) -In section 2.1, While IPv6 Neighbour Discovery assumes that responses to solicitations will be sent multicast, the specification allows any router to respond to RS message with a unicast RA if it desires [1]. The phrase "if it desires" sounds odd. It should be removed. Also, i am assuming that the unicast response is sent subject to MAX_RA_DELAY constraint as specified in RFC 2461. Perhaps, this should be stated to make it more clear. Routers SHOULD respond to a RS message with unicast RS message. s/unicast RS message/unicast RA message/ The stated disadvantage for unicast RA is that the router will not be able to aggregate its response from multiple hosts. But there is also the rate of unicast RAs and number of unicast RAs when there are lot of routers on the link. This is taken care of by the recommendation in section 3.2 by limiting to 3 routers per link though the rate is still left open. Perhaps, worth adding something. -In section 2.2, Where hosts have changeable connectivity, there may be a number of prefixes or routers stored in the host's memory, which are no longer directly reachable. This additional storage may make movement detection slower where hosts rapidly pass through networks, or pass through networks which have very long advertised timeouts. I read it a few times. But can't guess why it is here in this section ? Where hosts with ongoing transactions, or well known services (such as DNS) are present on a network, this duration SHOULD be greater than the maximum expected outage time (for example 9 hours for 0.999 uptime, with a single outage/year). What do you mean by hosts with ongoing transactions ? Do you mean long connections ? Also is the time recommendation for valid or preferred ? -I don't understand how section 3.1 affects DNA. At least it is not obvious. Some clarifying text needed. -In section 3.2, If using advertising intervals lower than those specified in IPv6 Neighbour Discovery, only one router MAY advertise at the elevated rate. Not sure i understand this. We are already allowing 3 routers on a link and also unicast RA in response to RS. Why do we need this additional thing ? I can see it is a MAY..hmm.. - In section 4.1, Where a Router Advertisement is sent by a router, it SHOULD contain sufficient information to prove that the router is on the same link as previously seen advertisers, or is indeed the same router. This may prevent expensive checks by hosts which will not need to immediately test the authenticity of the router through signature verification, or additional transmissions. So, we recommend SEND (just below) and we say that we want other insecure ways to detect routers faster. Not sure i understand what the intent of this paragraph is. As described in section Section 3.2, advertising common prefixes achieves this goal. This should be combined with the previous paragraph i guess. Routers supporting DNA SHOULD provide secured router discovery services using SEND [4]. The use of word "DNA" here (and perhaps other places) is confusing. The intent here is to say "Routers supporting the recommendations in this draft ...". Also, note that draft-ietf-dna-hosts does not recommend using SEND though it says one should prefer secured ones to unsecured. Note that the recommendations made here are to improve the 2461 behaviour for DNA. Even 2461bis does not recommend SEND. So, SEND here seems a bit too much.. - I see little value for the Appendix A. Editorial --------- In Introduction, It should be noted that many already deployed routers will not support these recommendations, and that hosts SHOULD NOT rely on their being in place, unless they have particular reason to do so. s /will not/ may not/ In Introduction, Several network-side factors may impact on the effectiveness and speed of DNA procedures. This document provides guidelines embodying s/on/ / In section 1.2, Host wishes to identify if their current prefix is still valid on s/Host wishes/Hosts need/ In section 1.2, Discovery procedures make this difficult. If the host can determine that the target router is still reachable through a NS/NA exchange, it does not mean that the prefix is still valid. s /prefix is still valid/ prefix is still valid on that link/ In section 2.0, Routers which are being deployed to support hosts' change detection procedures should attempt to use appropriate configurations, which s/to support hosts' change detection procedures/to aid In section 2.2, Where hosts have changeable connectivity, there may be a number of s/where hosts have changeable connectivity/When hosts are nomadic or mobile, (or something different) -mohan From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 30 16:50:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3gD4-0001Nq-M0 for dna-archive@megatron.ietf.org; Mon, 30 Jan 2006 16:05:17 -0500 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29590 for ; Mon, 30 Jan 2006 16:03:26 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LYEP93IRWU9C6HKV@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 Jan 2006 08:02:14 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6FB558038F; Tue, 31 Jan 2006 08:01:59 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 1208B3C012; Tue, 31 Jan 2006 08:01:59 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k0UKxrE05632 for dna-list; Tue, 31 Jan 2006 07:59:53 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k0UKxqu05628 for ; Tue, 31 Jan 2006 07:59:52 +1100 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LYEP6DH9LU9AVJHU@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 31 Jan 2006 07:59:49 +1100 Received: by localhost (Postfix, from userid 510) id 451ECAB87B; Tue, 31 Jan 2006 07:59:49 +1100 (EST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id CBA6B4FB02 for ; Tue, 31 Jan 2006 07:59:46 +1100 (EST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k0UKxe01023402 for ; Mon, 30 Jan 2006 15:59:40 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0UKxfqU145708 for ; Mon, 30 Jan 2006 15:59:41 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k0UKxegX017192 for ; Mon, 30 Jan 2006 15:59:40 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-194-123.mts.ibm.com [9.65.194.123]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k0UKxdmW017127 for ; Mon, 30 Jan 2006 15:59:40 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k0UKvHO3010133 for ; Mon, 30 Jan 2006 15:57:17 -0500 Date: Mon, 30 Jan 2006 15:57:17 -0500 From: Thomas Narten Subject: [DNA] draft-ietf-dna-cpl-02.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <200601302057.k0UKvHO3010133@cichlid.raleigh.ibm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) Content-Transfer-Encoding: 7BIT I have some questions/comments/concerns on this draft. General: I think the overall direction of this draft is OK (i.e., using prefixes to identify links), but I have some concerns about the specifics of what is described in this document. First, if I understand correctly, this is roughly what I think this document should be doing: Summary: This document assume routers implement RFC 2461/2462 and have not been upgraded with any DNA extensions. In addition, we assume that a node may move back-and-forth between networks it has previously visited. This could be be due to movement among a small set of links, or because of network "hiccups" that cause one to momentarily loose connectivity and then (re)connect to the same link again. This document describes how a host keeps configuration information about the links it has previously visited, attempting to reuse pre-existing configuration information (when it is safe to do so) rather than wait for the longer delay of going through the normal configuration steps. A host should maintain IP configuration info about "previous links" that it has connected to. That is, for each "previous link", it maintains the list of default routers, list of prefixes, MTU info, etc., as well as any relevant lifetime info. When connecting to a link (any link), a node always assumes it is connecting to a "new" link and starts the normal 2461/2462 procedures. In _parallel_, it also attempts to determine whether it is connected to a link it has connected to previously. When it get back an RA containing a prefix, it looks for that prefix in its "previous links" cache, and if it finds a match, it assumes it is rejoining that link. It immediately uses the cached config information (after adjusting to take into consideration elapsed time) to configure its link. Note that normal 2461/2462 continues to operate in parallel, and any info learned there simply updates the (now) configured parameters. The above seems fairly straightforward to implement/understand. But, the current document includes a number of things that I am not sure are needed at all, and some that I think are backwards. 1) the document is rather long and verbose. I actually find the text somewhat hard to follow, since the discussions seems fairly lengthy given what I understand to be a fairly simple algorithm. For example, it talks about numbers of times to transmit things, etc. I think this is all covered in 2461/2462 and shouldn't be mentioned here (I find it confusing to read about it because I'm not sure what is "new" to DNA vs. what is just being taken from other documents and should already be existing practice). Also, it seems to go to great lengths to cover all sorts of boundary cases that I think are unlikely and I don't think are worth worrying about. Remember, DNA is an optimization to speed things up in the common case. And nothing breaks if DNA fails to detect that a node has reconnected to the same link... 2) > If the host implementation does not provide any link-layer event > notifications [9], and in particular, a link UP notification, the > host needs additional logic to try to decide whether a received RA > applies to the "old" link or a "new" link. IMO, we shouldn't bother with this case. Indeed, 2461/2462 don't have any text about this, and so to the degree that this is a problem for DNA, its also a problem generally. If anything needs to be said, it should simply be: This document assumes that upon movement from one link to another, a "link-up" event of some sort will be generated, so that the IP layer is informed that a change of attachment point may have occurred. Most if not all of Section 5 could safely be deleted. 3) The entire discussion/text surrounding building a "complete prefix list" seems unnecessary and from what I can tell, doesn't really matter. That is, if you go back to the summary algorithm at the top, it doesn't matter whether a node has a "complete prefix list" or not; the algorithm works the same in either case. If you get a prefix in an RA, and it matches one in your cache, voila, you have found a link you were previously connected to. I don't see why it matters whether you are 90% certain you have a complete prefix list or not. I wonder if all of section 3.1 could be removed. 4) 3.2 Erroneous Prefix Lists > The host may generate either 1) the Incomplete Prefix List, i.e. the > prefix list that does not include all the prefixes that are assigned > to the link or 2) the Superfluous Prefix List, i.e. the prefix list > that contains some prefix that is not assigned to the link. How does this happen? why should we worry about this case? 2461/2462 doesn't... 5) > If the host is not sure that the prefix list was complete before the > hint reception, then the host needs to take several RAs into account > after the hint reception, before it can determine that it has moved > to a different link. Maybe this is just a wording issue, but the above seems to me to be backwards conceptually. A host should always assume it has moved, unless it learns of info that indicates otherwise. That should be a base assumption. (Above, the assumption seems the other way around.) If a host has multiple prefix lists, none of the prefixes in those lists should intersect. If they do, that indicates the two lists should be merged. It doesn't really matter whether a set is complete or not. > work. Thus the host needs to create a new Candidate Link object > based on the received RA, and make this object the CCL. However, it > does not yet treat this as a new link; it is merely a candidate. > Thus it MUST NOT perform the actions in Section 4.6 at this point in > time. Instead, the host should wait for MAX_RA_WAIT seconds, and all > RAs that are received during that time interval are processed as > specified above. Again, I think this logic is wrong (and too complex). You always assume a link is new as a starting point... or: > Subject to local policy, and perhaps also the host's knowledge of the > packet loss characteristics of the interface or type of L2 > technology, the host can try harder than just waiting for MAX_RA_WAIT > seconds, by sending additional Router Solicitations. It is allowed > to multicast up to MAX_RTR_SOLICITATIONS [1] RS messages spaced > RTR_SOLICITATION_INTERVAL apart. In the most conservative approach > this means a 12 second delay until the host will declare that is has > moved to a new link. Just as above, this process should be > terminated should a new link UP notification arrive during the 12 > seconds. this seems overkill, as it doesn't take 12 seconds to configure a link in the first place... so why are we making this so detailed/complex? (and again why not just assume we are attaching to a new link, unless we learn otherwise?) 6) > 3.4 Renumbering > > When the host is sure that the prefix list is complete, a false > movement assumption may happen due to renumbering when a new prefix > is introduced in RAs at about the same time as the host handles the > 'link UP' event. We may solve the renumbering problem with minor > modification like below. This will only happen if the RA is "weird' and includes only the one new prefix... In practice, it should carry more than one prefix. Why do we need to worry about this case? 7) 4.1: seems overly complicated to me. Whenever you get a link up, you assume you are at a new link. period. You then get RAs, and go from there, looking if they match anything in the "recently visited" set. If you find a match, use it. If not, you just continue doing normal ND/addrconf.. Thomas From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 30 17:42:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3hjd-0004Dz-6B for dna-archive@megatron.ietf.org; Mon, 30 Jan 2006 17:42:57 -0500 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20542 for ; Mon, 30 Jan 2006 17:41:21 -0500 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LYESNJ6YNU9AQP7F@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 Jan 2006 09:39:13 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9CB0DAB544; Tue, 31 Jan 2006 09:39:09 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 61EC74FB2F; Tue, 31 Jan 2006 09:39:09 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k0UMcIl06805 for dna-list; Tue, 31 Jan 2006 09:38:18 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k0UMcHu06801 for ; Tue, 31 Jan 2006 09:38:17 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LYESMBXT329AS8BD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 31 Jan 2006 09:38:11 +1100 Received: by localhost (Postfix, from userid 510) id 9209CAB608; Tue, 31 Jan 2006 09:38:11 +1100 (EST) Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by moe.its.monash.edu.au (Postfix) with ESMTP id CD0904FB18 for ; Tue, 31 Jan 2006 09:38:08 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k0UMc63W020051; Mon, 30 Jan 2006 14:38:07 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k0UMc5Vg422959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 30 Jan 2006 14:38:06 -0800 (PST) Date: Mon, 30 Jan 2006 14:37:44 -0800 From: Erik Nordmark Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <200601302057.k0UKvHO3010133@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <43DE9538.4030300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060113) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200601302057.k0UKvHO3010133@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > A host should maintain IP configuration info about "previous links" > that it has connected to. That is, for each "previous link", it > maintains the list of default routers, list of prefixes, MTU info, > etc., as well as any relevant lifetime info. When connecting to a link > (any link), a node always assumes it is connecting to a "new" link and > starts the normal 2461/2462 procedures. In _parallel_, it also > attempts to determine whether it is connected to a link it has > connected to previously. When it get back an RA containing a prefix, > it looks for that prefix in its "previous links" cache, and if it > finds a match, it assumes it is rejoining that link. It immediately > uses the cached config information (after adjusting to take into > consideration elapsed time) to configure its link. Note that normal > 2461/2462 continues to operate in parallel, and any info learned there > simply updates the (now) configured parameters. I'm not sure the above description with "in parallel" captures the essence. If/when the host receives an RA that indicates prefix overlap with the old attachment point, then it can declare that it hasn't moved at L3 and continue without any changes. But until then, the host can't operate 2461/62 unchanged, because that would imply that information it receives for a potentially new/different link will be added to the 2461/62 conceptual data structures for the old link. Also, DNA needs to be able to pick a point at which it will declare that is has moved at L3 and have that result in discarding the old information from the old link (old on-link prefixes, autoconfigured addresses, default routers, etc.) If DNA doesn't do that, then it doesn't help much since it will continue to use information from the old link. The last item above has some impact on your other high-level comments. > Also, it seems to go to great lengths to cover all sorts of > boundary cases that I think are unlikely and I don't think are > worth worrying about. Remember, DNA is an optimization to speed > things up in the common case. And nothing breaks if DNA fails to > detect that a node has reconnected to the same link... The issue of "discard old information" above does have the potential to break things compared to a non-DNA host today. Today a host (that only follows 2461/62) will assume it has the same information until the information times out (with default timers ranging from hours to weeks). If a DNA capable host, after detecting a change in L2 attachment point ( a link up event) erroneously decides that it has moved at L3, and as a result discards its autoconfigured IPv6 addresses, this might cause failures that are visible to applications. (The disappeared IPv6 addresses might cause existing connections to fail, even if an RA arrives milliseconds later and recreates the disappeared IPv6 address.) So your comments seem to be based on the assumption that existing IPv6 stacks always discard all IPv6 addresses and other information when they are connected to a different L2 attachment point. That certainly isn't the case for the implementation I use. If we can resolve the above point, then we can see what makes sense with respect to simplifications to the draft. > 2) > >> If the host implementation does not provide any link-layer event >> notifications [9], and in particular, a link UP notification, the >> host needs additional logic to try to decide whether a received RA >> applies to the "old" link or a "new" link. > > IMO, we shouldn't bother with this case. Indeed, 2461/2462 don't have > any text about this, and so to the degree that this is a problem for > DNA, its also a problem generally. If anything needs to be said, it > should simply be: > This document assumes that upon movement from one link to another, > a "link-up" event of some sort will be generated, so that the IP > layer is informed that a change of attachment point may have > occurred. > > Most if not all of Section 5 could safely be deleted. I also feel we don't need to worry about this case. What do others in the WG think? Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Jan 31 09:54:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3wtj-000323-Dl for dna-archive@megatron.ietf.org; Tue, 31 Jan 2006 09:54:29 -0500 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22467 for ; Tue, 31 Jan 2006 09:52:35 -0500 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYFQLUKSS2AUTC3L@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Feb 2006 01:51:41 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AB7B3AB543; Wed, 01 Feb 2006 01:51:19 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 609A44FB03; Wed, 01 Feb 2006 01:51:19 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k0VEo6j18984 for dna-list; Wed, 01 Feb 2006 01:50:06 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k0VEo6u18980 for ; Wed, 01 Feb 2006 01:50:06 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYFQK2E894AUTC3J@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Feb 2006 01:49:53 +1100 Received: by localhost (Postfix, from userid 510) id 9B844AB58C; Wed, 01 Feb 2006 01:49:53 +1100 (EST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id 379104FB18 for ; Wed, 01 Feb 2006 01:49:52 +1100 (EST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k0VEnnuN017782 for ; Tue, 31 Jan 2006 09:49:49 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0VEq9sw186784 for ; Tue, 31 Jan 2006 07:52:10 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k0VEnnM2010251 for ; Tue, 31 Jan 2006 07:49:49 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-156-76.mts.ibm.com [9.49.156.76]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k0VEnlXZ010180; Tue, 31 Jan 2006 07:49:48 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k0VEnjjL005887; Tue, 31 Jan 2006 09:49:45 -0500 Date: Tue, 31 Jan 2006 09:49:45 -0500 From: Thomas Narten Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: Message from Erik Nordmark "of Mon, 30 Jan 2006 14:37:44 PST." <43DE9538.4030300@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Message-id: <200601311449.k0VEnjjL005887@cichlid.raleigh.ibm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) Content-Transfer-Encoding: 7BIT > I'm not sure the above description with "in parallel" captures the essence. > If/when the host receives an RA that indicates prefix overlap with the > old attachment point, then it can declare that it hasn't moved at L3 and > continue without any changes. Agreed. > But until then, the host can't operate 2461/62 unchanged, because that > would imply that information it receives for a potentially new/different > link will be added to the 2461/62 conceptual data structures for the old > link. Hmm. One thing missing here is the high-level description of expected behavior when a link goes "down" and then "comes back up". 2461/2462 (to the degree I recall) doesn't say a lot, but if it does say anything, the implication is probably to "discard all information when the link goes away" and "start fresh when a link comes up", which I agree is not really what we want in practice. > Also, DNA needs to be able to pick a point at which it will declare that > is has moved at L3 and have that result in discarding the old > information from the old link (old on-link prefixes, autoconfigured > addresses, default routers, etc.) If DNA doesn't do that, then it > doesn't help much since it will continue to use information from the old > link. Right. Though in the DNA context, "discard" probably needs more description. We don't want the info assigned to the interface anymore. But do we actually want all upper-layer uses of those addresses to now explicitely fail? Or is it OK to allow continued use (even if it doesn't really work) so that if we reconnect to the link later, upper-layer applications may still recover (using the old addresses)? I think there may be pros and cons to both sides on this point. > > Also, it seems to go to great lengths to cover all sorts of > > boundary cases that I think are unlikely and I don't think are > > worth worrying about. Remember, DNA is an optimization to speed > > things up in the common case. And nothing breaks if DNA fails to > > detect that a node has reconnected to the same link... > The issue of "discard old information" above does have the potential to > break things compared to a non-DNA host today. > Today a host (that only follows 2461/62) will assume it has the same > information until the information times out (with default timers ranging > from hours to weeks). Is this just what implementations do, or is this supported (or even called for) in 2461/2462 (or other specs)? > If a DNA capable host, after detecting a change in L2 attachment point ( > a link up event) erroneously decides that it has moved at L3, and as a > result discards its autoconfigured IPv6 addresses, this might cause > failures that are visible to applications. (The disappeared IPv6 > addresses might cause existing connections to fail, even if an RA > arrives milliseconds later and recreates the disappeared IPv6 address.) Yep. I agree that this is probably not what we want. > So your comments seem to be based on the assumption that existing IPv6 > stacks always discard all IPv6 addresses and other information when they > are connected to a different L2 attachment point. That certainly isn't > the case for the implementation I use. If we can resolve the above > point, then we can see what makes sense with respect to simplifications > to the draft. That wasn't my intent. But, this discussion is good. As I read through some of the other documents I kept coming back to "what is the abstract model" governing the behavior we want? I will step back and try to describe that as well, as I think it's helpful to understand/clarify at an abstract level what the principles are and how we think things should work. From that, it's a lot easier to dive into details. Thomas From dna-owner@webcamserver.eng.monash.edu.au Tue Jan 31 11:42:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yZz-0007it-VA for dna-archive@megatron.ietf.org; Tue, 31 Jan 2006 11:42:08 -0500 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05281 for ; Tue, 31 Jan 2006 11:40:31 -0500 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYFUET7JCSAUTCGO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Feb 2006 03:40:27 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 41E81AB58D; Wed, 01 Feb 2006 03:40:11 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id E496D4FB8B; Wed, 01 Feb 2006 03:40:10 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k0VGdMd20321 for dna-list; Wed, 01 Feb 2006 03:39:22 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k0VGdLu20317 for ; Wed, 01 Feb 2006 03:39:21 +1100 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYFUDL1PNYAUTCG0@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Feb 2006 03:39:12 +1100 Received: by localhost (Postfix, from userid 510) id 1497AAB542; Wed, 01 Feb 2006 03:39:12 +1100 (EST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id AF5224FB08 for ; Wed, 01 Feb 2006 03:39:10 +1100 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k0VGd5rk019482 for ; Tue, 31 Jan 2006 11:39:05 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0VGbA1F224342 for ; Tue, 31 Jan 2006 09:37:10 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k0VGd4Dk021432 for ; Tue, 31 Jan 2006 09:39:04 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-156-76.mts.ibm.com [9.49.156.76]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k0VGd38J021307 for ; Tue, 31 Jan 2006 09:39:04 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k0VGcxbZ007692 for ; Tue, 31 Jan 2006 11:38:59 -0500 Date: Tue, 31 Jan 2006 11:38:59 -0500 From: Thomas Narten Subject: [DNA] Model: how to treat "link down" events Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <200601311638.k0VGcxbZ007692@cichlid.raleigh.ibm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) Content-Transfer-Encoding: 7BIT In thinking through this, one thing that is not clear to me is what the model is for what to do when a "link down" event takes place. This is actually important to understand as it plays into how to handle "link up" events. RFC 2461/2462 defines the IPv6 behavior for configuring a link with IPv6 information such as addresses, MTU, on-link prefixes, etc. When a link goes down, conceptually one disables the interface and discards all associated config info. However, this has the negative side-effect of causing upper-layer protocols using those addresses to possibly get "hard errors" and terminate connections when sending traffic. [Actually, is this true, or are things more nuanced, i.e., does one get errors when sending but here is no route, or when sending but using an invalid source address, or???] In the common case where a link goes away for a few seconds and then comes back up connected to the same link (with the same associated config information) this is obviously undesirable. Q: what is a good model for what to do with the config information assocated with an interface that is going down? In some cases (e.g., administrative shutdown of an interface) returning hard errors to upper-layer protocols is probably OK. But for wireless hiccups, it may not be. And if I unplug a wired ethernet from the jack, should that automatically cause all connections using the address on that interface to fail? Not clear. There are certainly times when I wish that didn't happen... One possible model: - some types of "link down" events are absolute (like an administrative shutdown) - some "link down" down events should be treated suspiciously (e.g., wireless) and should not result in (immediate) error to upper-layer protocols. - by default, one should not return hard errors immediately (in anticipation of the link coming back up) but one can do so after some timeout. So, should we say after N minutes, an interface is really dead? - can we provide guidelines for what to do in general? Proposal: There are two types of errors that can be returned upon sending a packet: hard error: means a failure of a type for which retrying is likely to result in the same error, and upper layer protocols are OK giving up. soft error: a temporary failure occured, but retrying a short time later may result in a different result. I would put "ICMP dest unreachables" into this category. When a link goes down (i.e., via a "link down" event), soft errors should be returned when a) sending through the interface, or b) if using addresses associated with that interface. Soft errors should be returned from some short time. After (say) 2 minutes, hard errors can be returned. Does this make sense? Note: in terms of DNA, when a "link up" event takes place, I would imagine that we could distinguish between a "link up" event that happens within (say) 2 minutes of a "link down" or after a much longer time period, possibly treating the behavior somewhat differently. Thomas From dna-owner@webcamserver.eng.monash.edu.au Tue Jan 31 20:53:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F47Au-0008S7-41 for dna-archive@megatron.ietf.org; Tue, 31 Jan 2006 20:53:08 -0500 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25054 for ; Tue, 31 Jan 2006 20:51:10 -0500 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYGDLPHVFAAXB2D1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Feb 2006 12:50:16 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0DFDDAB546; Wed, 01 Feb 2006 12:50:10 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id A9F664FB02; Wed, 01 Feb 2006 12:50:09 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k111mCR27292 for dna-list; Wed, 01 Feb 2006 12:48:12 +1100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k111mBu27286 for ; Wed, 01 Feb 2006 12:48:11 +1100 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31112) with ESMTP id <01LYGDIY00229C7GVC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Feb 2006 12:47:56 +1100 Received: by localhost (Postfix, from userid 510) id 7B0FFAB545; Wed, 01 Feb 2006 12:47:56 +1100 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 6998D4FB39 for ; Wed, 01 Feb 2006 12:47:54 +1100 (EST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ITZ004OSJN878@mailout3.samsung.com> for dna@eng.monash.edu.au; Wed, 01 Feb 2006 10:47:32 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0ITZ00I4RJN8R6@mmp1.samsung.com> for dna@eng.monash.edu.au; Wed, 01 Feb 2006 10:47:32 +0900 (KST) Date: Wed, 01 Feb 2006 10:47:51 +0900 From: Soohong Daniel Park Subject: Re: [DNA] Model: how to treat "link down" events Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten , dna@eng.monash.edu.au Cc: STDS-802-21@listserv.ieee.org Message-id: <02fa01c626d1$83414130$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200601311638.k0VGcxbZ007692@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT It seems a bit crossover of IEEE 802.21 stuff called MIHS (Media Independent Handover Services). It defines three kinds of services like below; -Media Independent Event Services -Media Independent Command Services -Media Independent Information Services and, especially your mention belongs to the first category. For further details, you can refer to the related link below, http://www1.ietf.org/mail-archive/web/mipshop/current/msg02410.html Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Thomas Narten" To: Sent: Wednesday, February 01, 2006 1:38 AM Subject: [DNA] Model: how to treat "link down" events > In thinking through this, one thing that is not clear to me is what > the model is for what to do when a "link down" event takes place. This > is actually important to understand as it plays into how to handle > "link up" events. > > RFC 2461/2462 defines the IPv6 behavior for configuring a link with > IPv6 information such as addresses, MTU, on-link prefixes, etc. When > a link goes down, conceptually one disables the interface and discards > all associated config info. However, this has the negative side-effect > of causing upper-layer protocols using those addresses to possibly get > "hard errors" and terminate connections when sending > traffic. [Actually, is this true, or are things more nuanced, i.e., > does one get errors when sending but here is no route, or when sending > but using an invalid source address, or???] In the common case where a > link goes away for a few seconds and then comes back up connected to > the same link (with the same associated config information) this is > obviously undesirable. > > Q: what is a good model for what to do with the config information > assocated with an interface that is going down? In some cases (e.g., > administrative shutdown of an interface) returning hard errors to > upper-layer protocols is probably OK. But for wireless hiccups, it may > not be. And if I unplug a wired ethernet from the jack, should that > automatically cause all connections using the address on that > interface to fail? Not clear. There are certainly times when I wish > that didn't happen... > > One possible model: > > - some types of "link down" events are absolute (like an > administrative shutdown) > > - some "link down" down events should be treated suspiciously (e.g., > wireless) and should not result in (immediate) error to > upper-layer protocols. > > - by default, one should not return hard errors immediately (in > anticipation of the link coming back up) but one can do so after > some timeout. So, should we say after N minutes, an interface is > really dead? > > - can we provide guidelines for what to do in general? > > > Proposal: > > There are two types of errors that can be returned upon sending a > packet: > > hard error: means a failure of a type for which retrying is likely to > result in the same error, and upper layer protocols are OK > giving up. > > soft error: a temporary failure occured, but retrying a short time > later may result in a different result. I would put "ICMP > dest unreachables" into this category. > > > When a link goes down (i.e., via a "link down" event), soft errors > should be returned when a) sending through the interface, or b) if > using addresses associated with that interface. Soft errors should be > returned from some short time. After (say) 2 minutes, hard errors can > be returned. > > Does this make sense? > > Note: in terms of DNA, when a "link up" event takes place, I would > imagine that we could distinguish between a "link up" event that > happens within (say) 2 minutes of a "link down" or after a much longer > time period, possibly treating the behavior somewhat differently. > > Thomas > >