From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 04:53:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4EgI-0004ca-M2 for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 04:53:42 -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 EAA27624 for ; Wed, 1 Feb 2006 04:52:04 -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 <01LYGUCNPE029C7C4Z@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 01 Feb 2006 20:49:18 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B0E1280003; Wed, 01 Feb 2006 20:49:14 +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 65B323C009; Wed, 01 Feb 2006 20:49:14 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k119krE00902 for dna-list; Wed, 01 Feb 2006 20:46:53 +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 k119kru00898 for ; Wed, 01 Feb 2006 20:46:53 +1100 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 <01LYGU9E716Y9C72DI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 01 Feb 2006 20:46:37 +1100 Received: by localhost (Postfix, from userid 510) id E430480003; Wed, 01 Feb 2006 20:46:36 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.205]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4DC553C00F for ; Wed, 01 Feb 2006 20:46:33 +1100 (EST) Received: by uproxy.gmail.com with SMTP id k40so178708ugc for ; Wed, 01 Feb 2006 01:46:30 -0800 (PST) Received: by 10.67.23.20 with SMTP id a20mr3712450ugj; Wed, 01 Feb 2006 01:46:30 -0800 (PST) Received: by 10.66.234.6 with HTTP; Wed, 01 Feb 2006 01:46:30 -0800 (PST) Date: Wed, 01 Feb 2006 18:46:30 +0900 From: JinHyeock Choi 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: <92e919fb0602010146o69e53a96r1471875b12f6f39a@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C28mQ4WpYI7WDUV6bSg2Bsq67AtWLp6ZL3PnKzxZeeyT3sFMzS/QzL5YF4+k0JxbRPj25yKgowD/8Nnj6acuKyRGM/DpRe0Vc1KecnCO8vjvxFfrL8783kvWBhyLnnvn3PJlAqTwSRQ0BYPW38VvHkUI+16x8Cl/gbC73kKgkjo= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200601302057.k0UKvHO3010133@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Dear Thomas Thanks for your helpful and detailed feedback. In the draft, mainly we try to present a way for a host to check for link change, whether it remains at the same link or not, upon receiving a single RA (with prefixes). > 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. The draft proposes that the node also assumes it is rejoining a new link, if it doesn't find a match. To make such an assumption, the node needs to keep the information of all the prefixes on a link. > 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). We try to make a host correctly declare a link change when it receives an RA with only unknown prefixes. Without maintaining the Complete Prefix List, that would be difficult. > 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. It's ok for me to remove Section 5 unless WG objects it. > 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. The Complete Prefix List is to enable a node to correctly declare a link change when the node get a prefix in an RA and it matches none in its cache. Without the Complete Prefix List, the fact an RA includes only unknown prefixes doesn't imply that the node is moved to a new link. > 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... The Incomplete Prefix List may result from packet losses and the Superfluous Prefix List may result from the node mistakenly combines the prefixes from different links to produce a single list. The first may make a node mistakenly assume it has moved to a different link, whereas the second may make a node mistakenly assume it remains at the same link. > > 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?) We present this as the most conservative approach and doesn't recommend it. Even without the Complete Prefix List, it will take 4 secs to finish DNA according to our recommendation. > 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? We try to prevent weird cases from happening by explicitly writing down its pitfall. :-) > 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.. With our proposal, if you doesn't find a match, you can immediately detect that you have moved to a new link and substitute existing configuration information with new one. (It's also possible for you to save the existing on for the future use.) Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 09:29:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Iyu-0007YW-35 for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 09:29:16 -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 JAA03695 for ; Wed, 1 Feb 2006 09:27:25 -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 <01LYH3YY8OM69C72JP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 01:25:21 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 55527AB604; Thu, 02 Feb 2006 01:25:18 +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 0639E4FB07; Thu, 02 Feb 2006 01:25:18 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k11EOK804397 for dna-list; Thu, 02 Feb 2006 01:24:20 +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 k11EOKu04393 for ; Thu, 02 Feb 2006 01:24:20 +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 <01LYH3XLPU3M9C6ROI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 01:24:13 +1100 Received: by localhost (Postfix, from userid 510) id 495DBAB58C; Thu, 02 Feb 2006 01:24:13 +1100 (EST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) (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 1C8FD4FB03 for ; Thu, 02 Feb 2006 01:24:10 +1100 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k11EO7Ll018023 for ; Wed, 01 Feb 2006 09:24:07 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k11EO7w5161716 for ; Wed, 01 Feb 2006 09:24:07 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k11EO756009747 for ; Wed, 01 Feb 2006 09:24:07 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-203-67.mts.ibm.com [9.65.203.67]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k11EO6Lk009690; Wed, 01 Feb 2006 09:24:06 -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 k11ENemC018379; Wed, 01 Feb 2006 09:23:40 -0500 Date: Wed, 01 Feb 2006 09:23:40 -0500 From: Thomas Narten Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: Message from JinHyeock Choi "of Wed, 01 Feb 2006 18:46:30 +0900." <92e919fb0602010146o69e53a96r1471875b12f6f39a@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <200602011423.k11ENemC018379@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 JinHyeock Choi writes: > > 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). > We try to make a host correctly declare a link change when it receives > an RA with only unknown prefixes. Without maintaining the Complete > Prefix List, that would be difficult. rereading section 4.5: Receiving valid Router Advertisements, I'm (generally) fine with the first part of this section. I.e., it says that when a host receives the first RA (after a link up event): 1) if it contains a prefix in the CCL, assume no link change. 2) if it contains a prefix in retained Candidate Link Object, assume host has moved back to that link. The interesting case is where one receives an RA containing only prefixes that one has not seen before. It is this case that makes use of the "complete" state. I.e., if the CCL is complete, one assumes that learning a new prefix means an immediate move. But if the CCL is not complete, one doesn't assume one has moved (yet). Specifically: > 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. > This processing might result in finding a prefix in common between a > Candidate Link object and the CCL, in which case the host knows > whether and to which link it has moved. But should the MAX_RA_WAIT > seconds expire without any common prefix, then it will conclude that > it has moved to a new link and inform the rest of the host of the > movement (Section 4.6.) Could you clarify for me how the above relates to normal 2461/2462 processing? I.e., I would assume that the new prefix should be configured on the link immediately. Is this the case? Also, I'm not sure it's worth the complexity of waiting another 4 seconds to gather additional RAs before declaring a move. Or maybe I don't understand what it means to "declare a move" and what impact that has on the addresses configured on the interface. This goes back to my message yesterday asking what processing we are assuming happens upon a "link down" event. Given that as far as we know, most RAs include complete information, why go to so much trouble to handle the case where this is not the case, and where the cached information is "incomplete" (which also is probably not the normal case), etc. I agree that having a Complete Prefix List would be good, in the sense that upon receipt of an RA, one is more likely to make a correct determination about whether one has rejoined an existing link. However, the current document formalizes this too much, including algorithms that are used to (in some sense) "declare" when one has a complete list as opposed to maybe not having a complete list. I'm just not convinced (yet) that this complexity has sufficient benefit in practice. > > 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... > The Incomplete Prefix List may result from packet losses and the > Superfluous Prefix List may result from the node mistakenly combines > the prefixes from different links to produce a single list. The first > may make a node mistakenly assume it has moved to a different link, > whereas the second may make a node mistakenly assume it remains at the > same link. > > > 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?) > We present this as the most conservative approach and doesn't > recommend it. Even without the Complete Prefix List, it will take 4 > secs to finish DNA according to our recommendation. So, it takes 4 seconds to complete DNA? I thought the whole point was for DNA to complete quickly. Recall, using normal 2461/2462 in _MOST_ cases, a single RS will trigger the transmission of RAs from _all_ routers, and this will complete within .5 seconds. Thus, having DNA operate for 4 seconds seems to miss the bigger picture. Thomas From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 10:43:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4K8h-0003eO-PB for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 10:43:28 -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 KAA08500 for ; Wed, 1 Feb 2006 10:41:40 -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 <01LYH6OR77ZIAXB76V@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 02:43:03 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8698CAB542; Thu, 02 Feb 2006 02:42:35 +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 395EA4FB30; Thu, 02 Feb 2006 02:42:35 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k11Ffe105375 for dna-list; Thu, 02 Feb 2006 02:41:40 +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 k11Ffdu05371 for ; Thu, 02 Feb 2006 02:41:39 +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 <01LYH6NA51489AULP3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 02:41:24 +1100 Received: by localhost (Postfix, from userid 510) id 83501AB58D; Thu, 02 Feb 2006 02:41:24 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.192]) by moe.its.monash.edu.au (Postfix) with ESMTP id A303B4FB18 for ; Thu, 02 Feb 2006 02:41:22 +1100 (EST) Received: by uproxy.gmail.com with SMTP id s2so281842uge for ; Wed, 01 Feb 2006 07:41:19 -0800 (PST) Received: by 10.48.221.19 with SMTP id t19mr1720593nfg; Wed, 01 Feb 2006 07:41:19 -0800 (PST) Received: by 10.48.213.18 with HTTP; Wed, 01 Feb 2006 07:41:19 -0800 (PST) Date: Wed, 01 Feb 2006 21:11:19 +0530 From: Syam Madanapalli Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <200602011423.k11ENemC018379@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <10e14db20602010741qba4c52dv19e5d02584045643@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=keYc4tNpLjCfLRoonSpgPLPEJOoOmNrVUlhp+tR1HneGct0EB++6JCZrvzgX1ekWaHqB581Pia9BJQF9L+XjnbSb+OQWLmguroL0bezguiHTh+x0o4pYcT0Thgf/isv2wTDv1654ALhoM7ceJLX3FpQjCLUa3bz//u1e9HuSfYQ= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <92e919fb0602010146o69e53a96r1471875b12f6f39a@mail.gmail.com> <200602011423.k11ENemC018379@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT > > We present this as the most conservative approach and doesn't > > recommend it. Even without the Complete Prefix List, it will take 4 > > secs to finish DNA according to our recommendation. > > So, it takes 4 seconds to complete DNA? I thought the whole point was > for DNA to complete quickly. Recall, using normal 2461/2462 in _MOST_ > cases, a single RS will trigger the transmission of RAs from _all_ > routers, and this will complete within .5 seconds. Thus, having DNA > operate for 4 seconds seems to miss the bigger picture. draft-ietf-dna-cpl-02 is for unmodified routers. Actual DNAv6 draft can be found at http://www.ctie.monash.edu.au/dna-dt/draft-pentland-dna-protocol3-pre02.txt This protocol requires the modifications to both Routers (at least one on the link) and Hosts. With this protocol, the host can make a link change decision with one RS/RA exchange. This draft also defines Fast RA, which ensures that two routers will not respond at exactly the same time while allowing one of the routers on the link to respond immediately. From the draft-ietf-dna-cpl-02 ... MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec) + network propagation delay is the maximum delay between an RS and the resulting RAs [1]. 4 seconds would be a safe number for the host to wait for the solicited RAs. Assuming no packet loss, within 4 seconds, the host would receive all the RAs and know all the prefixes. Thus we pick 4 seconds as the value for MAX_RA_WAIT. ... An implementation, may choose to compare the prefixes as and when it receives an RA, if there is a common prefix, host can make the decision that it is at the same link and need not wait for 4 sec. 4 sec wait may be required for the cases where there is a link change. In most cases if the RA contains all the prefixes, the receipt of first RA is sufficient to check for link change. In such cases a host can wait for 4 sec to receive an RA, at that time the host can resend the RS (the first RS might not have reached the router). - Syam From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 11:01:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4KQR-0007nM-Fs for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 11:01:44 -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 LAA10064 for ; Wed, 1 Feb 2006 11:00:05 -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 <01LYH756A1U49AVIP0@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 02:55:53 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D40C7AB58C; Thu, 02 Feb 2006 02:55:49 +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 85D644FB57; Thu, 02 Feb 2006 02:55:49 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k11FteN05597 for dna-list; Thu, 02 Feb 2006 02:55:40 +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 k11Fteu05593 for ; Thu, 02 Feb 2006 02:55:40 +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 <01LYH74SQGGOAXB786@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 02:55:31 +1100 Received: by localhost (Postfix, from userid 510) id D55AEAB542; Thu, 02 Feb 2006 02:55:31 +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 9D7254FB35 for ; Thu, 02 Feb 2006 02:55:30 +1100 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k11FtSlv023354 for ; Wed, 01 Feb 2006 10:55:28 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k11FtSw5185064 for ; Wed, 01 Feb 2006 10:55:28 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k11FtRr3003418 for ; Wed, 01 Feb 2006 10:55:27 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k11FtRlW003388; Wed, 01 Feb 2006 10:55:27 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k11FtQAQ032042; Wed, 01 Feb 2006 10:55:27 -0500 Date: Wed, 01 Feb 2006 10:55:26 -0500 From: Thomas Narten Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <"Message from smadanapalli"@gmail.com> "of Wed, 01 Feb 2006 21:11:19 +0530." <10e14db20602010741qba4c52dv19e5d02584045643@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Syam Madanapalli Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <200602011555.k11FtQAQ032042@rotala.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 > draft-ietf-dna-cpl-02 is for unmodified routers. Actual DNAv6 draft > can be found at Yes, I understand this. My previous note was entirely within the specific context of receiving an RA (that contained a prefix we didn't know about) and how to handle that case. BTW, I think it is useful to divide the problem space up three ways: 1) host recommendations for interacting with non-upgraded routers (i.e., those implementing 2461/2462) 2) hosts/routers that can BOTH be upgraded with DNA extensions (the protocol3 document) 3) changes to routers that would benefit unmodified hosts. (also contained in protocol3). I view this third category as "fixes" to 2461/2462 that all routers should do and as small improvements on 2461/2462. while it may be OK to tackle cases 2&3 in the same document, I think it would be good to make it more clear that case 3 is something we want all routers to implement, and not just "if they want to support DNA". > In most cases if the RA contains all the prefixes, the receipt of first > RA is sufficient to check for link change. Right. And since I expect this case to be common, its not at all clear to me that we need to make the DNA algorith more complicated to deal with cases that are not expected to happen much in practice. Thomas From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 13:03:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4MKO-0001Mt-09 for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 13:03:36 -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 NAA19232 for ; Wed, 1 Feb 2006 13:01:58 -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 <01LYHBKJ31O2AXB7VK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 05:03:02 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C3B2DAB58D; Thu, 02 Feb 2006 05:02:43 +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 7B4BA4FB49; Thu, 02 Feb 2006 05:02:43 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k11I1bk07350 for dna-list; Thu, 02 Feb 2006 05:01:37 +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 k11I1bu07346 for ; Thu, 02 Feb 2006 05:01:37 +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 <01LYHBITPER8AXB7VF@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 05:01:22 +1100 Received: by localhost (Postfix, from userid 510) id 53FF8AB542; Thu, 02 Feb 2006 05:01:22 +1100 (EST) Received: from hotmail.com (bay106-f5.bay106.hotmail.com [65.54.161.15]) by curly.its.monash.edu.au (Postfix) with ESMTP id 645024FB08 for ; Thu, 02 Feb 2006 05:01:21 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 01 Feb 2006 10:01:20 -0800 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Wed, 01 Feb 2006 18:01:19 +0000 (GMT) Date: Wed, 01 Feb 2006 10:01:19 -0800 From: Bernard Aboba Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <02fa01c626d1$83414130$6dc6dba8@daniellaptop> X-Originating-IP: [67.182.139.247] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 01 Feb 2006 18:01:20.0112 (UTC) FILETIME=[8146EF00:01C62759] Content-Transfer-Encoding: 7BIT I'd argue that tearing down TCP connections based on LINK DOWN is a bad idea on any media. I have pulled my Ethernet cable out of the switch port, only to connect it on another port a few seconds later. Why can't the TCP/IP implementation be resilient to that? It's really just another type of route flap. Administrative disabling of an interface is a different case. There I would be ok with tearing down connections. >----- 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 > > > > From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 14:43:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Nso-00060w-JP for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 14:43:14 -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 OAA27096 for ; Wed, 1 Feb 2006 14:41:28 -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 <01LYHF20S83QAXB8F9@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 06:42:48 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E85C3AB545; Thu, 02 Feb 2006 06:42:20 +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 93A7B4FB03; Thu, 02 Feb 2006 06:42:20 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k11JfYG08648 for dna-list; Thu, 02 Feb 2006 06:41:34 +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 k11JfYu08644 for ; Thu, 02 Feb 2006 06:41:34 +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 <01LYHF0RWZIK9C6SA8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 06:41:21 +1100 Received: by localhost (Postfix, from userid 510) id 1293CAB58D; Thu, 02 Feb 2006 06:41:21 +1100 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by moe.its.monash.edu.au (Postfix) with ESMTP id 37E284FB26 for ; Thu, 02 Feb 2006 06:41:19 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.108.38]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k11JfHQj014672; Wed, 01 Feb 2006 12:41:17 -0700 (MST) 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 k11JfFSO192801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 01 Feb 2006 11:41:17 -0800 (PST) Date: Wed, 01 Feb 2006 11:40:52 -0800 From: Erik Nordmark Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <200601311449.k0VEnjjL005887@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <43E10EC4.8090706@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: <200601311449.k0VEnjjL005887@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > 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. I think RFC 2461/62 says absolutely nothing about this. All it says about a link being enabled is in the case of the system coming up, an interface being enabled, or the host attaching or re-attaching to a link. (In those cases a host can send a few RSes.) RFC 2461 talks about what a *router* can do when an interface is being administratively disabled or the router is shut down. But there is NO mention of a link going down or being detached from an link. I don't find any language about links going down or interfaces being disabled in RFC 2462. So I don't think the above implication can be read between the lines of those RFCs. If we want to find out what implementors have implemented, I suspect we need to go an survey the implementations. I suspect there might be a range of behavior from doing nothing explicitly when a link goes down, to blowing away all IPv6 addresses and all TCP connections that use those local address when a link goes down. Neither is recommended or forbidden by our sets of RFCs. (But blowing away all the TCP connections just because the 802.11 AP becomes unreachable for a few seconds might be too aggressive.) Note that in the DNA discussions we talked about using 'link down' in the protocol, but we decided that - most L2s don't have a well-defined point at which a link is declared down (the interface could have been unusable for quite a while before the device driver considers it as down). - some L2 movement might happen without the link being considered down. For instance, a handover from one access point to another. DNA needs to be notified of such events, and the current assumption is that a 'link up' event would be generated in that case without being preceded by a 'link down'. A result of these considerations is that the DNA specifications do not attach any behavior of a 'link down' event. > 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. FWIW section 4.6 in draft-ietf-dna-cpl does specify what is required to be discarded. But it is silent about any implications on ULP traffic. From the perspective of the document, it might make sense to add the same language as we have for invalid addresses in RFC 2462 (which is that the host should not send any packets using such addresses as source). I agree that the ULP implications have be argued either way, and the optimal behavior is application dependent. *If* the host might move back to the old link and the application can't easily recover, then the best thing for TCP to do would be to be patient, and keep on retransmitting. (And the IP layer might prevent those packets from going out with the invalid source address until the host moves back to the same link.) But *if* the application can quickly and easily recover by creating a new TCP connection, the best strategy would be to immediately reset the TCP connection so that the application can recreate another one. I wonder if it makes sense to add the above considarations in a non-normative appendix somewhere. >> 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)? As stated above, I find no text in 2461/2462 arguing either end of the scale (or the middle) for how a host should behave when a link goes down. I think there is a fundamental tradeoff between being quick to react and keep the host's IPv6 addresses stable. CPL as well as the DNA solution protocol do go through some extra work to come up with a reasonable tradeoff *at the IP layer* between the two, and this is why we see things like on a lossy link CPL might not be able to conclude a host has moved until after 12 seconds worst case. (But the DNA solution can always do it in one RS/RA roundtrip time.) By doing this, DNA leaves the tradeoff between quick and stable to the ULPs to cope with. And we seem to agree that there are some hard tradeoffs for TCP and the applications in that space. >> 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. OK. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 18:00:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Qxz-00020g-DK for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 18:00:47 -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 RAA24443 for ; Wed, 1 Feb 2006 17:59:07 -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 <01LYHKX2NQNI9AVDWQ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 09:30:14 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A8F9DAB545; Thu, 02 Feb 2006 09:30: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 4599C4FB2F; Thu, 02 Feb 2006 09:30:09 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k11MTFo10739 for dna-list; Thu, 02 Feb 2006 09:29:15 +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 k11MTFu10735 for ; Thu, 02 Feb 2006 09:29:15 +1100 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 <01LYHKVN75OK9C6Z47@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 09:29:01 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CA9A380003; Thu, 02 Feb 2006 09:29:00 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id B62C53C005; Thu, 02 Feb 2006 09:29:00 +1100 (EST) Received: from [150.169.1.100] by mail-store-2.its.monash.edu.au (mshttpd) ; Wed, 01 Feb 2006 17:29:00 -0500 Date: Wed, 01 Feb 2006 17:29:00 -0500 From: Greg Daley Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: Syam Madanapalli , JinHyeock Choi , dna@eng.monash.edu.au Message-id: <97275096d6ec.96d6ec972750@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Thomas, ----- Original Message ----- From: Thomas Narten Date: Wednesday, February 1, 2006 10:55 am Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt > > draft-ietf-dna-cpl-02 is for unmodified routers. Actual DNAv6 draft > > can be found at > > Yes, I understand this. My previous note was entirely within the > specific context of receiving an RA (that contained a prefix we didn't > know about) and how to handle that case. > > BTW, I think it is useful to divide the problem space up three ways: > > 1) host recommendations for interacting with non-upgraded routers > (i.e., those implementing 2461/2462) > > 2) hosts/routers that can BOTH be upgraded with DNA extensions (the > protocol3 document) > > 3) changes to routers that would benefit unmodified hosts. (also > contained in protocol3). I view this third category as "fixes" to > 2461/2462 that all routers should do and as small improvements on > 2461/2462. > > while it may be OK to tackle cases 2&3 in the same document, I think > it would be good to make it more clear that case 3 is something we > want all routers to implement, and not just "if they want to support > DNA". I think that we have these broken up into 4 documents rather than 3, with draft-ietf-dna-hosts and draft-ietf-dna-cpl taking role 1). Role 2 is provided by a successor document to draft-pentland-dna- protocol3 (can we confirm that the name is draft-ietf-dna-protocol ?) Role 3) is provided by draft-ietf-dna-routers Initially, the match for draft-ietf-dna-hosts and CPL wasn't good with regard to the detail contained in the document and authors wished for these to remain separate. > > In most cases if the RA contains all the prefixes, the receipt > of first > > RA is sufficient to check for link change. > > Right. And since I expect this case to be common, its not at all clear > to me that we need to make the DNA algorith more complicated to deal > with cases that are not expected to happen much in practice. Well, I guess we're not trying to be restrictive (the routers' document discusses the issues though). Greg > Thomas > From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 19:35:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4SRK-00011s-QH for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 19:35:12 -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 TAA06498 for ; Wed, 1 Feb 2006 19:33:25 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYHP6EDES6AXBA1F@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 11:32:57 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DACB780005; Thu, 02 Feb 2006 11:32:12 +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 843A23C00C; Thu, 02 Feb 2006 11:32:12 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k120VYq12369 for dna-list; Thu, 02 Feb 2006 11:31:34 +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 k120VYu12365 for ; Thu, 02 Feb 2006 11:31:34 +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 <01LYHP5LG2QO9AUQIF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 11:31:34 +1100 Received: by localhost (Postfix, from userid 510) id 2E130AB58C; Thu, 02 Feb 2006 11:31:34 +1100 (EST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by moe.its.monash.edu.au (Postfix) with ESMTP id 79F784FB57 for ; Thu, 02 Feb 2006 11:31:32 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k120VUSD021109; Wed, 01 Feb 2006 17:31:30 -0700 (MST) 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 k120VPhb318645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 01 Feb 2006 16:31:30 -0800 (PST) Date: Wed, 01 Feb 2006 16:31:02 -0800 From: Erik Nordmark Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <200601311638.k0VGcxbZ007692@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <43E152C6.407@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: <200601311638.k0VGcxbZ007692@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > 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. This discussion might be interesting, but I'm not sure it is critical or even relevant to DNS, since we've designed DNA to only operate using 'link up' event notifications i.e., there is no dependency on any 'link down' event notifications. > 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. FWIW I take exception to this interpretation. There is nothing in 2461/62 that leads me to believe this was the intent. In fact, the default timers in the RFCs are quite long (90 minutes for default routers, and 7 days until an address becomes deprecated - 30 days to become invalid.) I don't remember exactly how we picked those values, but I have vague recollections that we didn't want the IPv6 addresses to accidentally disappear just because the router that advertises the prefix disappears for a few days. So I think the intent when 2461/62 was written was to err on the side of stability of the addresses. Your assertion that the specifications should be interpreted as discarding everything on a 'link down' event doesn't match that presumed desire for stability. > 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... I can recommend an Open Source OS and IPv6 stack that doesn't have that problem ;-) > 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? It might make sense. But I don't see how defining these things more carefully, and making the above recommendations, would have any impact on how we specify the behavior of the DNA. We can't rely on timely 'link down' events for DNA, hence it makes sense to only rely on 'link up' events, which is what CPL and the DNA solution do. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 20:40:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4TSv-0005o7-Jw for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 20:40:57 -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 UAA11775 for ; Wed, 1 Feb 2006 20:39:07 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYHRHZAYDIAXBAD2@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 12:39:15 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 519F680004; Thu, 02 Feb 2006 12:38:48 +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 07BF83C003; Thu, 02 Feb 2006 12:38:48 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k121cIU13240 for dna-list; Thu, 02 Feb 2006 12:38:18 +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 k121cHu13236 for ; Thu, 02 Feb 2006 12:38:17 +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 <01LYHRH0IYO8AXBAD2@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 12:38:02 +1100 Received: by localhost (Postfix, from userid 510) id 7F27780003; Thu, 02 Feb 2006 12:38:02 +1100 (EST) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id F2CED3C006 for ; Thu, 02 Feb 2006 12:38:00 +1100 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k121WrwK014629; Thu, 02 Feb 2006 03:32:53 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 02 Feb 2006 03:37:56 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 01 Feb 2006 19:37:53 -0600 Date: Wed, 01 Feb 2006 17:37:50 -0800 From: Mohan.Parthasarathy@nokia.com Subject: RE: [DNA] Model: how to treat "link down" events In-reply-to: <43E152C6.407@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: erik.nordmark@sun.com, narten@us.ibm.com Cc: dna@eng.monash.edu.au Message-id: <8A76136424391244A5CF0165337085370128084B@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: [DNA] Model: how to treat "link down" events Thread-Index: AcYnkPahBt3h6L8WSC2NFLZ8b8eujwABzGUw Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-OriginalArrivalTime: 02 Feb 2006 01:37:53.0555 (UTC) FILETIME=[490A9E30:01C62799] Content-Transfer-Encoding: 7BIT Erik, Is the following scenario possible ? 1) Host receives a link down event. Does not do anything. 2) Host attaches to the new link. Link UP event happens slightly late or the event has not propagated completely through the system. Meanwhile you are able to send and receive packets. This is not good because you are not in the optimistic state yet and you are on the new link. -mohan > >Thomas Narten wrote: >> 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. > >This discussion might be interesting, but I'm not sure it is >critical or even relevant to DNS, since we've designed DNA to >only operate using 'link up' event notifications i.e., there >is no dependency on any 'link down' event notifications. > >> 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. > >FWIW I take exception to this interpretation. There is nothing in >2461/62 that leads me to believe this was the intent. > >In fact, the default timers in the RFCs are quite long (90 >minutes for default routers, and 7 days until an address >becomes deprecated - 30 days to become invalid.) I don't >remember exactly how we picked those values, but I have vague >recollections that we didn't want the IPv6 addresses to >accidentally disappear just because the router that advertises >the prefix disappears for a few days. So I think the intent >when 2461/62 was written was to err on the side of stability >of the addresses. >Your assertion that the specifications should be interpreted >as discarding everything on a 'link down' event doesn't match >that presumed desire for stability. > >> 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... > >I can recommend an Open Source OS and IPv6 stack that doesn't >have that problem ;-) > >> 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? > >It might make sense. But I don't see how defining these things >more carefully, and making the above recommendations, would >have any impact on how we specify the behavior of the DNA. > >We can't rely on timely 'link down' events for DNA, hence it >makes sense to only rely on 'link up' events, which is what >CPL and the DNA solution do. > > Erik > > From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 20:43:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4TV0-0006yf-0k for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 20:43:02 -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 UAA11941 for ; Wed, 1 Feb 2006 20:41:16 -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 <01LYHRKL9OIAAXBADX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 12:41:11 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5EAC0AB542; Thu, 02 Feb 2006 12:40:55 +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 0E25C4FB1B; Thu, 02 Feb 2006 12:40:55 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k121epE13319 for dna-list; Thu, 02 Feb 2006 12:40:51 +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 k121epu13315 for ; Thu, 02 Feb 2006 12:40:51 +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 <01LYHRKDG48A9AVJ9M@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 12:40:45 +1100 Received: by localhost (Postfix, from userid 510) id 01C5FAB60D; Thu, 02 Feb 2006 12:40:44 +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 moe.its.monash.edu.au (Postfix) with ESMTP id AD6E24FB06; Thu, 02 Feb 2006 12:40:42 +1100 (EST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k121eeu8018324; Wed, 01 Feb 2006 20:40:40 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k121h1R9156772; Wed, 01 Feb 2006 18:43:01 -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 k121edLO015798; Wed, 01 Feb 2006 18:40:39 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-145-247.mts.ibm.com [9.49.145.247]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k121eaBm015714; Wed, 01 Feb 2006 18:40:38 -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 k121e4MG009522; Wed, 01 Feb 2006 20:40:05 -0500 Date: Wed, 01 Feb 2006 20:40:04 -0500 From: Thomas Narten Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: Message from Greg Daley "of Wed, 01 Feb 2006 17:29:00 EST." <97275096d6ec.96d6ec972750@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Syam Madanapalli , JinHyeock Choi , dna@eng.monash.edu.au Message-id: <200602020140.k121e4MG009522@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 Hi Greg. > > BTW, I think it is useful to divide the problem space up three ways: > > > > 1) host recommendations for interacting with non-upgraded routers > > (i.e., those implementing 2461/2462) > > > > 2) hosts/routers that can BOTH be upgraded with DNA extensions (the > > protocol3 document) > > > > 3) changes to routers that would benefit unmodified hosts. (also > > contained in protocol3). I view this third category as "fixes" to > > 2461/2462 that all routers should do and as small improvements on > > 2461/2462. > > > > while it may be OK to tackle cases 2&3 in the same document, I think > > it would be good to make it more clear that case 3 is something we > > want all routers to implement, and not just "if they want to support > > DNA". > I think that we have these broken up into 4 documents > rather than 3, with draft-ietf-dna-hosts and draft-ietf-dna-cpl > taking role 1). Is there a particular reason to have two documents rather than one? Indeed, now I'm confused, because it appears I need to read two documents to understand what hosts are supposed to do to handle case 1. I hope the plan isn't to have two RFCs on this topic... Can someone summarize the main differences between these two documents? > Role 2 is provided by a successor document to draft-pentland-dna- > protocol3 (can we confirm that the name is draft-ietf-dna-protocol > ?) OK. Could the authors please indicate what their plans are for reissuing this document and what changes it will contain? (I've read protocol3, but if another version is coming soone, I should probably wait before commenting.) > Role 3) is provided by draft-ietf-dna-routers I'll have to go read this one. But I thought I saw things in the protocol3 document that would correspond to role 3. > > > In most cases if the RA contains all the prefixes, the receipt > > of first > > > RA is sufficient to check for link change. > > > > Right. And since I expect this case to be common, its not at all > clear > > to me that we need to make the DNA algorith more complicated to deal > > with cases that are not expected to happen much in practice. > Well, I guess we're not trying to be restrictive (the routers' > document discusses the issues though). Well, one approach would be to make it clear that this part is optional to implement. But I certainly assumed it was a required part of the spec as I read it. Thomas From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 22:04:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4UlW-00013H-6k for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 22:04:12 -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 WAA17129 for ; Wed, 1 Feb 2006 22:02:30 -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 <01LYHQVPEEY09AVFHF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 12:21:07 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9444680005; Thu, 02 Feb 2006 12:20:51 +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 304523C00C; Thu, 02 Feb 2006 12:20:51 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k121KWU13025 for dna-list; Thu, 02 Feb 2006 12:20:32 +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 k121KVu13021 for ; Thu, 02 Feb 2006 12:20:31 +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 <01LYHQUYQO8E9AVH2C@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 12:20:16 +1100 Received: by localhost (Postfix, from userid 510) id DE1B8AB544; Thu, 02 Feb 2006 12:20:15 +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 1A9014FB38 for ; Thu, 02 Feb 2006 12:20:09 +1100 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k121K7OW017040 for ; Wed, 01 Feb 2006 20:20:07 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k121K6w5214342 for ; Wed, 01 Feb 2006 20:20:07 -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 k121K6R1014081 for ; Wed, 01 Feb 2006 20:20:06 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-145-247.mts.ibm.com [9.49.145.247]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k121K3UE013896; Wed, 01 Feb 2006 20:20:05 -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 k121JMCk008895; Wed, 01 Feb 2006 20:19:28 -0500 Date: Wed, 01 Feb 2006 20:19:22 -0500 From: Thomas Narten Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: Message from Erik Nordmark "of Wed, 01 Feb 2006 16:31:02 PST." <43E152C6.407@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: dna@eng.monash.edu.au Message-id: <200602020119.k121JMCk008895@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 Erik Nordmark writes: > This discussion might be interesting, but I'm not sure it is critical or > even relevant to DNS, since we've designed DNA to only operate using > 'link up' event notifications i.e., there is no dependency on any 'link > down' event notifications. Right. I just started thinking about it as I was trying to understand what information is associated with an interface when one gets a 'link up' (i.e., there are some unstated assumptions being made in the DNA drafts I think, and I'm trying to flesh them out). It wasn't immediately obvious that (by default) any information would be associated with an interface. > > 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. > FWIW I take exception to this interpretation. There is nothing in > 2461/62 that leads me to believe this was the intent. Fair enough. I'm definitely not saying that I think this is what should be doing. > In fact, the default timers in the RFCs are quite long (90 minutes > for default routers, and 7 days until an address becomes deprecated > - 30 days to become invalid.) I don't remember exactly how we > picked those values, but I have vague recollections that we didn't > want the IPv6 addresses to accidentally disappear just because the > router that advertises the prefix disappears for a few days. Ah.. but a router going away (with an apparently still working link) strikes me as different than a link that goes down -- and for which we get an explicit indication from the LL that the link has gone down. Note: maybe ten years ago when we were doing the spec twisted pair ethernet was a lot less ubiquitous and the notion that one got 'link down' indications from the interface was a lot less common. Wireless was still a dream... :-) > So I think the intent when 2461/62 was written was to err on the > side of stability of the addresses. Your assertion that the > specifications should be interpreted as discarding everything on a > 'link down' event doesn't match that presumed desire for stability. I don't mean to assert that. I do think that we (the community as a whole) didn't think about this part in a lot of detail. > It might make sense. But I don't see how defining these things more > carefully, and making the above recommendations, would have any impact > on how we specify the behavior of the DNA. What I'm trying to get at is: what assumption can be made about the configuration information that is already associated with an interface (i.e., from 2461/2426) at the time a 'link up' event takes place? I guess the obvious model is that whatever IP configuraiton information was associated with the interface before the link up (subject to any lifetime considerations) is assumed to still be associated with the interface. But think about this just from a 2461/2462 perspective (i.e., before we started thinking about DNA). What would happen in practice in a pre-DNA world? Suppose an RA is received on an interface, but it indicates a new prefix that one has never heard of, and it doesn't include any prefixes currently associated with the interface. Shouldn't the old information be thrown away (since we might be at a new link). It needs to be discarded at some point, not because it has expired, but because it doesn't apply to the current link anymore. some of that informaitn will stay around for a very long time if one only looked at Lifetimes. [I don't recall any of this being discussed in 2461/2462.] It seems to me that some assumptions have to be made in order to define what it is that DNA is supposed to do, or, what state it assumes as it gets invoked. > We can't rely on timely 'link down' events for DNA, hence it makes > sense to only rely on 'link up' events, which is what CPL and the > DNA solution do. Agreed that we can't _rely_ on them. But there are presumably cases where they will occur. How should they be handled? Just note them , but more-or-less silently ignore them? Thomas From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 01 23:23:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4W0H-0007FC-T8 for dna-archive@megatron.ietf.org; Wed, 01 Feb 2006 23:23:34 -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 XAA23307 for ; Wed, 1 Feb 2006 23:21:42 -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 <01LYHX6TWZZK9AVDQ8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 15:21:45 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7F8B080007; Thu, 02 Feb 2006 15:21:37 +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 31E5F3C00C; Thu, 02 Feb 2006 15:21:37 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k124BVl15278 for dna-list; Thu, 02 Feb 2006 15:11:31 +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 k124BVu15274 for ; Thu, 02 Feb 2006 15:11:31 +1100 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 <01LYHWU8B69W9AVGHH@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 15:11:28 +1100 Received: by localhost (Postfix, from userid 510) id 5616F80002; Thu, 02 Feb 2006 15:11:28 +1100 (EST) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id AB3523C004 for ; Thu, 02 Feb 2006 15:11:26 +1100 (EST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1248OTS007058; Thu, 02 Feb 2006 06:08:24 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 02 Feb 2006 06:11:05 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 01 Feb 2006 22:11:02 -0600 Date: Wed, 01 Feb 2006 20:11:01 -0800 From: Michael.G.Williams@nokia.com Subject: RE: [DNA] Model: how to treat "link down" events In-reply-to: <43E152C6.407@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: erik.nordmark@sun.com, narten@us.ibm.com Cc: dna@eng.monash.edu.au Message-id: <8A76136424391244A5CF0165337085370128088D@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: [DNA] Model: how to treat "link down" events Thread-Index: AcYnkPahBt3h6L8WSC2NFLZ8b8eujwAA0azA Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-OriginalArrivalTime: 02 Feb 2006 04:11:02.0656 (UTC) FILETIME=[AE2C2800:01C627AE] Content-Transfer-Encoding: 7BIT The very last statement: >We can't rely on timely 'link down' events for DNA, hence it makes sense to only rely on 'link up' >events, which is what CPL and the DNA solution do. > > Erik If timely link down events were available (say from IEEE 802.21), would that help things? Best Regards, Michael -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of ext Erik Nordmark Sent: Wednesday, February 01, 2006 4:31 PM To: Thomas Narten Cc: dna@eng.monash.edu.au Subject: Re: [DNA] Model: how to treat "link down" events Thomas Narten wrote: > 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. This discussion might be interesting, but I'm not sure it is critical or even relevant to DNS, since we've designed DNA to only operate using 'link up' event notifications i.e., there is no dependency on any 'link down' event notifications. > 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. FWIW I take exception to this interpretation. There is nothing in 2461/62 that leads me to believe this was the intent. In fact, the default timers in the RFCs are quite long (90 minutes for default routers, and 7 days until an address becomes deprecated - 30 days to become invalid.) I don't remember exactly how we picked those values, but I have vague recollections that we didn't want the IPv6 addresses to accidentally disappear just because the router that advertises the prefix disappears for a few days. So I think the intent when 2461/62 was written was to err on the side of stability of the addresses. Your assertion that the specifications should be interpreted as discarding everything on a 'link down' event doesn't match that presumed desire for stability. > 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... I can recommend an Open Source OS and IPv6 stack that doesn't have that problem ;-) > 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? It might make sense. But I don't see how defining these things more carefully, and making the above recommendations, would have any impact on how we specify the behavior of the DNA. We can't rely on timely 'link down' events for DNA, hence it makes sense to only rely on 'link up' events, which is what CPL and the DNA solution do. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 04:47:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4b4F-0008Sr-Bu for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 04:47: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 EAA15312 for ; Thu, 2 Feb 2006 04:46:06 -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 <01LYI8IOTD749C7DL6@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 20:45:48 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B848CAB542; Thu, 02 Feb 2006 20:45:45 +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 646164FB06; Thu, 02 Feb 2006 20:45:45 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k129Xso19276 for dna-list; Thu, 02 Feb 2006 20:33:54 +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 k129Xiu19272 for ; Thu, 02 Feb 2006 20:33:44 +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 <01LYI83LACTU9AVAFF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 20:33:35 +1100 Received: by localhost (Postfix, from userid 510) id 89388AB544; Thu, 02 Feb 2006 20:33:35 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.202]) by curly.its.monash.edu.au (Postfix) with ESMTP id 470204FB2B for ; Thu, 02 Feb 2006 20:33:26 +1100 (EST) Received: by uproxy.gmail.com with SMTP id y2so146139uge for ; Thu, 02 Feb 2006 01:33:24 -0800 (PST) Received: by 10.66.244.10 with SMTP id r10mr202265ugh; Thu, 02 Feb 2006 01:33:24 -0800 (PST) Received: by 10.66.234.6 with HTTP; Thu, 02 Feb 2006 01:33:24 -0800 (PST) Date: Thu, 02 Feb 2006 18:33:24 +0900 From: JinHyeock Choi Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <200602011423.k11ENemC018379@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <92e919fb0602020133u328444c0t5d351073e55f3715@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q+wELD9c4R61T4X/fRQFvMSZ0+ptL17uPvSBGOlfTqk53/jOBSLSKtCPxXCBcf2p+gTrw8B7//gI9LxvifEanshKCQuL2FYz77OPIYFwtaAkseo3/MfP0FpSWWexTVsKeARO5Zu1KIo+Q13l75XA8VV2UuONLAcbrHuHuIylXNU= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <92e919fb0602010146o69e53a96r1471875b12f6f39a@mail.gmail.com> <200602011423.k11ENemC018379@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Dear Thomas > > 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. > > > This processing might result in finding a prefix in common between a > > Candidate Link object and the CCL, in which case the host knows > > whether and to which link it has moved. But should the MAX_RA_WAIT > > seconds expire without any common prefix, then it will conclude that > > it has moved to a new link and inform the rest of the host of the > > movement (Section 4.6.) > > Could you clarify for me how the above relates to normal 2461/2462 > processing? I.e., I would assume that the new prefix should be > configured on the link immediately. Is this the case? The new prefix is immediately assumed to be assigned on the currently attached link (which is obvious). Main issue is what we will do with the existing prefix list. In case the host remains at the same link, the new prefix is added to the existing prefix list. In case of a link change, the host makes a new prefix list with the new prefix. > Also, I'm not sure it's worth the complexity of waiting another 4 > seconds to gather additional RAs before declaring a move. > > Or maybe I don't understand what it means to "declare a move" and what > impact that has on the addresses configured on the interface. This > goes back to my message yesterday asking what processing we are > assuming happens upon a "link down" event. When a host declare a move, it should discard current IP configuration information such as IP address. Declaring a move implies not only the host's existing link is down but also the host is attached to a different link. So on the currently attached link, the host can't use its existing configuration information and needs new one. The host should configure a new IP address and re-establish its TCP connections (assuming no MIPv6). > Given that as far as we know, most RAs include complete information, > why go to so much trouble to handle the case where this is not the > case, and where the cached information is "incomplete" (which also is > probably not the normal case), etc. > > I agree that having a Complete Prefix List would be good, in the sense > that upon receipt of an RA, one is more likely to make a correct > determination about whether one has rejoined an existing link. > > However, the current document formalizes this too much, including > algorithms that are used to (in some sense) "declare" when one has a > complete list as opposed to maybe not having a complete list. I'm just > not convinced (yet) that this complexity has sufficient benefit in > practice. Usually a host will keep the Complete Prefix List and check for link change with just one RA. Most complexity is from maintaining Complete Prefix List to make DNA more precise/ stable. > > We present this as the most conservative approach and doesn't > > recommend it. Even without the Complete Prefix List, it will take 4 > > secs to finish DNA according to our recommendation. > > So, it takes 4 seconds to complete DNA? This is the worst case, an upper bound. In general DNA will be completed upon the receipt of the first RA. > I thought the whole point was > for DNA to complete quickly. Recall, using normal 2461/2462 in _MOST_ > cases, a single RS will trigger the transmission of RAs from _all_ > routers, and this will complete within .5 seconds. Thus, having DNA > operate for 4 seconds seems to miss the bigger picture. I agree that DNA is to complete quickly but think it also is to decide correctly. We aimed both Speed and Precision (sounds like a NIKE ad. :-)) Usually Speed and Precision is in a kind of trade off, the quicker you decide, the less precise the decision. We try to strike a healthy balance between them. To increase the speed, we may make the policy that the host makes a decision upon receiving the first RA (even without the Complete Prefix List). But that will decrease the precision and may result in falsely declaring a move. When a host declare a move, it should discard its IP address and tear down TCP connections. Hence we recommend a different policy for the host to wait up till 4 secs (this is upper bound) to enhance the precision. It may worthwhile to wait a few additional seconds instead of instantly jumping to the conclusion and tearing down all TCP connections. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 04:48:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4b4G-0008T9-MZ for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 04:48:00 -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 EAA15317 for ; Thu, 2 Feb 2006 04:46:10 -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 <01LYI8IIX5MO9AVAFP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 20:45:41 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C9669AB542; Thu, 02 Feb 2006 20:45:37 +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 609804FB30; Thu, 02 Feb 2006 20:45:37 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k129dRr19361 for dna-list; Thu, 02 Feb 2006 20:39:27 +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 k129dRu19357 for ; Thu, 02 Feb 2006 20:39:27 +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 <01LYI8AJ8OA0AXBD8D@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 20:39:11 +1100 Received: by localhost (Postfix, from userid 510) id 64A6F80002; Thu, 02 Feb 2006 20:39:11 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.203]) by larry.its.monash.edu.au (Postfix) with ESMTP id 59F6A3C009 for ; Thu, 02 Feb 2006 20:39:01 +1100 (EST) Received: by uproxy.gmail.com with SMTP id y2so148420uge for ; Thu, 02 Feb 2006 01:38:59 -0800 (PST) Received: by 10.66.255.13 with SMTP id c13mr212218ugi; Thu, 02 Feb 2006 01:38:59 -0800 (PST) Received: by 10.66.234.6 with HTTP; Thu, 02 Feb 2006 01:38:59 -0800 (PST) Date: Thu, 02 Feb 2006 18:38:59 +0900 From: JinHyeock Choi Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <43E10EC4.8090706@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Thomas Narten , dna@eng.monash.edu.au Message-id: <92e919fb0602020138p23cdc68cy5a85170310eecac3@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IaqCKvuVh5QqW0G5dLVi/ADKa+NjAPLgAMj0QZJqN8bOtfg104QiNUd2WB6Ywd725XTDrOlvZ4RMF3xFTsoBFHNghPIcjMMegH9u7lTno9QDM0pDNjZHzx5AGKQgE85Bro4J8zzqJQa+sAqa/yOGElEphpq3JRXVk9MP3gxx5v0= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200601311449.k0VEnjjL005887@cichlid.raleigh.ibm.com> <43E10EC4.8090706@sun.com> Content-Transfer-Encoding: 7BIT Dear Erik > (But blowing away all the TCP connections > just because the 802.11 AP becomes unreachable for a few seconds might > be too aggressive.) Nobody seems to be in favor of immediately blowing TCP away. > FWIW section 4.6 in draft-ietf-dna-cpl does specify what is required to > be discarded. > But it is silent about any implications on ULP traffic. > From the perspective of the document, it might make sense to add the > same language as we have for invalid addresses in RFC 2462 (which is > that the host should not send any packets using such addresses as source). > > I agree that the ULP implications have be argued either way, and the > optimal behavior is application dependent. agree. Different applicaions with different requirements, such as 'file transfer' and 'VoIP', may need to behave differently. > *If* the host might move back to the old link and the application can't > easily recover, then the best thing for TCP to do would be to be > patient, and keep on retransmitting. (And the IP layer might prevent > those packets from going out with the invalid source address until the > host moves back to the same link.) > > But *if* the application can quickly and easily recover by creating a > new TCP connection, the best strategy would be to immediately reset the > TCP connection so that the application can recreate another one. 'IP layer' may have difficulty determining which type of application is running currently. I guess the decision (whether to keep tying or not) would better to be left to application. > >> 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)? > > As stated above, I find no text in 2461/2462 arguing either end of the > scale (or the middle) for how a host should behave when a link goes down. > > I think there is a fundamental tradeoff between being quick to react and > keep the host's IPv6 addresses stable. > CPL as well as the DNA solution protocol do go through some extra work > to come up with a reasonable tradeoff *at the IP layer* between the two, > and this is why we see things like on a lossy link CPL might not be able > to conclude a host has moved until after 12 seconds worst case. (But the > DNA solution can always do it in one RS/RA roundtrip time.) > > By doing this, DNA leaves the tradeoff between quick and stable to the > ULPs to cope with. And we seem to agree that there are some hard > tradeoffs for TCP and the applications in that space. agree. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 04:51:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4b7r-000203-VF for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 04:51:40 -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 EAA15591 for ; Thu, 2 Feb 2006 04:50:01 -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 <01LYI8MREJGU9AVD03@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 20:49:05 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C5151AB604; Thu, 02 Feb 2006 20:49:02 +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 75E534FB18; Thu, 02 Feb 2006 20:49:02 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k129mx219565 for dna-list; Thu, 02 Feb 2006 20:48:59 +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 k129mxu19561 for ; Thu, 02 Feb 2006 20:48:59 +1100 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 <01LYI8MDF8R09AVAFP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 20:48:44 +1100 Received: by localhost (Postfix, from userid 510) id 1056B80002; Thu, 02 Feb 2006 20:48:43 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.197]) by larry.its.monash.edu.au (Postfix) with ESMTP id 040D93C011 for ; Thu, 02 Feb 2006 20:48:35 +1100 (EST) Received: by uproxy.gmail.com with SMTP id y2so152287uge for ; Thu, 02 Feb 2006 01:48:35 -0800 (PST) Received: by 10.67.26.15 with SMTP id d15mr208985ugj; Thu, 02 Feb 2006 01:48:33 -0800 (PST) Received: by 10.66.234.6 with HTTP; Thu, 02 Feb 2006 01:48:33 -0800 (PST) Date: Thu, 02 Feb 2006 18:48:33 +0900 From: JinHyeock Choi Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <8A76136424391244A5CF0165337085370128088D@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Michael.G.Williams@nokia.com" Cc: erik.nordmark@sun.com, narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <92e919fb0602020148r8d5eb5bge3d6039138023c0d@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RNkyGRBdvRX2LNogbRqDs+wsaFA+JFQ50QmUVhHpG8lhDYBZTrEBmjp8VHgXCyu7K27wpVbiEt1RyMaSe60ZEZYPGn/11mpAH5+PIfrbEtJvlaIbqPgKLYEZUUmsgPLS2C9tWqXYSaxeKZ2aDnsL4ffZc3NWeuamzVV9hTNtw0o= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <43E152C6.407@sun.com> <8A76136424391244A5CF0165337085370128088D@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Dear Michael > If timely link down events were available (say from IEEE 802.21), would > that help things? Not so much, in my opinion. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 04:51:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4b7t-00022g-IU for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 04:51:41 -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 EAA15595 for ; Thu, 2 Feb 2006 04:50:02 -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 <01LYI8MX6PDY9C71CH@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 20:49:18 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 79FA4AB631; Thu, 02 Feb 2006 20:49:10 +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 2B5454FB26; Thu, 02 Feb 2006 20:49:10 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k129lre19542 for dna-list; Thu, 02 Feb 2006 20:47: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 k129lru19538 for ; Thu, 02 Feb 2006 20:47:53 +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 <01LYI8L047X4AXBD9B@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 20:47:37 +1100 Received: by localhost (Postfix, from userid 510) id CA934AB58C; Thu, 02 Feb 2006 20:47:37 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.198]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7F1074FB11 for ; Thu, 02 Feb 2006 20:47:35 +1100 (EST) Received: by uproxy.gmail.com with SMTP id y2so151617uge for ; Thu, 02 Feb 2006 01:47:35 -0800 (PST) Received: by 10.66.225.15 with SMTP id x15mr218304ugg; Thu, 02 Feb 2006 01:47:35 -0800 (PST) Received: by 10.66.234.6 with HTTP; Thu, 02 Feb 2006 01:47:35 -0800 (PST) Date: Thu, 02 Feb 2006 18:47:35 +0900 From: JinHyeock Choi Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <8A76136424391244A5CF0165337085370128084B@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Mohan.Parthasarathy@nokia.com" Cc: erik.nordmark@sun.com, narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <92e919fb0602020147td9214aagc302560c4e835ca7@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GAyflOWfeNxqygh4tDI9OPB64Z1PK8DXAQqjszjhQCT9zWicvLT8NPRg4QX7SuPum8Jve6owRSMbdNCL3+tlwHG4XFZgKLD0vQmoaNv6xpr7o9k3P11iOM2Z35hhGqLSut2DU1No2tQB9Wd87S2A579YzFtGBo/VPGjLIvbNhAM= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <43E152C6.407@sun.com> <8A76136424391244A5CF0165337085370128084B@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Dear Mohan > Is the following scenario possible ? > > 1) Host receives a link down event. Does not do anything. > 2) Host attaches to the new link. Link UP event happens > slightly late or the event has not propagated completely > through the system. Meanwhile you are able to send and > receive packets. I have difficulty understanding above. How can the host send/ receive packets when it is attached to a new link in which it has no IP configuration information such as IP address? Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 04:51:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4b7v-00025M-98 for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 04:51:43 -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 EAA15600 for ; Thu, 2 Feb 2006 04:50:04 -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 <01LYI8MSBRAQ9C6R9Q@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 20:49:11 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8078480003; Thu, 02 Feb 2006 20:49:03 +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 2E9893C011; Thu, 02 Feb 2006 20:49:03 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k129lFk19523 for dna-list; Thu, 02 Feb 2006 20:47:15 +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 k129lEu19519 for ; Thu, 02 Feb 2006 20:47:14 +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 <01LYI8KCTY5U9AVAFP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 20:47:06 +1100 Received: by localhost (Postfix, from userid 510) id 835AAAB58C; Thu, 02 Feb 2006 20:47:06 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.198]) by moe.its.monash.edu.au (Postfix) with ESMTP id 180294FB11 for ; Thu, 02 Feb 2006 20:47:04 +1100 (EST) Received: by uproxy.gmail.com with SMTP id y2so151617uge for ; Thu, 02 Feb 2006 01:47:04 -0800 (PST) Received: by 10.66.221.19 with SMTP id t19mr210079ugg; Thu, 02 Feb 2006 01:47:04 -0800 (PST) Received: by 10.66.234.6 with HTTP; Thu, 02 Feb 2006 01:47:03 -0800 (PST) Date: Thu, 02 Feb 2006 18:47:03 +0900 From: JinHyeock Choi Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au Message-id: <92e919fb0602020147u22ce896q3f1ef169e9965766@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EAbNenO9qJ3QoT5ObXD31JAGxZ/WgACSOLkZwLDvHkLg/7D+CyDz1E+3QS5TJX4/e5FoLP1RFYjIiMAG+w67yUxqtd3kV2hh7C6Fgje3U8b5VIlGzveFog/NLVx+lPk/6qVbNBXhARK1sFHttiBJ3RUCVmXIS4bPGyT/lURGarQ= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <02fa01c626d1$83414130$6dc6dba8@daniellaptop> Content-Transfer-Encoding: 7BIT Dear Bernard > I'd argue that tearing down TCP connections based on LINK DOWN is a bad idea > on any media. I have pulled my Ethernet cable out of the switch port, only > to connect it on another port a few seconds later. Why can't the TCP/IP > implementation be resilient to that? It's really just another type of route > flap. Allow me an hair splitting argument. :-) In the above example, I assume that, after a few secs later, the etheret cable is connected to the same link. In case it is connected to a different link, I think TCP/IP connections should be torn down and re-established. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 04:55:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4bBn-0003ze-7H for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 04:55:43 -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 EAA15909 for ; Thu, 2 Feb 2006 04:53:56 -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 <01LYI8N3GN2YAXBDA8@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 20:49:37 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C56B1AB60E; Thu, 02 Feb 2006 20:49:18 +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 72F5B4FB1B; Thu, 02 Feb 2006 20:49:18 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k129mTN19556 for dna-list; Thu, 02 Feb 2006 20:48:29 +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 k129mSu19552 for ; Thu, 02 Feb 2006 20:48:28 +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 <01LYI8M0W1Q0AW2FG8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 20:48:27 +1100 Received: by localhost (Postfix, from userid 510) id 3A1C280002; Thu, 02 Feb 2006 20:48:27 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.197]) by larry.its.monash.edu.au (Postfix) with ESMTP id BC2D63C006 for ; Thu, 02 Feb 2006 20:48:20 +1100 (EST) Received: by uproxy.gmail.com with SMTP id y2so152287uge for ; Thu, 02 Feb 2006 01:48:18 -0800 (PST) Received: by 10.67.31.9 with SMTP id i9mr207182ugj; Thu, 02 Feb 2006 01:48:17 -0800 (PST) Received: by 10.66.234.6 with HTTP; Thu, 02 Feb 2006 01:48:17 -0800 (PST) Date: Thu, 02 Feb 2006 18:48:17 +0900 From: JinHyeock Choi Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <200602020119.k121JMCk008895@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: Erik Nordmark , dna@eng.monash.edu.au Message-id: <92e919fb0602020148q38ca7cb4m9ee55f00f16fa8d7@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EbTBYRNH/Ml0P7dgB6IlQjl56otD/c0H01wZsT8nNUEDbSnwBogrStuSBR9V43l6uVlR+CZhWaSzyq0B0ifjEfG9TXKBJHJdHnQBz9W8WswXSdS8LkLdZrdq8tMJ12iMj25Ff6kxUyvVEBePd1YMD0OBeBvbinj0bTJyWrWzhSs= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <43E152C6.407@sun.com> <200602020119.k121JMCk008895@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas > Note: maybe ten years ago when we were doing the spec twisted > pair ethernet was a lot less ubiquitous and the notion that one got > 'link down' indications from the interface was a lot less > common. Wireless was still a dream... :-) Not anymore, I am happy to say. :-) > > It might make sense. But I don't see how defining these things more > > carefully, and making the above recommendations, would have any impact > > on how we specify the behavior of the DNA. > > What I'm trying to get at is: what assumption can be made about the > configuration information that is already associated with an interface > (i.e., from 2461/2426) at the time a 'link up' event takes place? > > I guess the obvious model is that whatever IP configuraiton > information was associated with the interface before the link up > (subject to any lifetime considerations) is assumed to still be > associated with the interface. Agree. However the host would better keep from using the information (such as sending a packet with the existing IP address as a source address) until DNA procedure determines that it really remains at the same link. > But think about this just from a 2461/2462 perspective (i.e., before > we started thinking about DNA). What would happen in practice in a > pre-DNA world? Suppose an RA is received on an interface, but it > indicates a new prefix that one has never heard of, and it doesn't > include any prefixes currently associated with the > interface. Shouldn't the old information be thrown away (since we > might be at a new link). This is the question we tried to answer with CPL. When the host is sure that it knows all the prefixes on the link (i.e. having the Complete Prefix List), it can throw away the old information because a new prefix implies a new link. If it is not so sure, it would better take some time before make a decision to throw away. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 04:55:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4bBp-0003zo-NA for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 04:55:45 -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 EAA15913 for ; Thu, 2 Feb 2006 04:53:58 -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 <01LYI8MYVI6QAXBDA6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 20:49:57 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 97D8FAB547; Thu, 02 Feb 2006 20:49:12 +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 1CEFB4FB2A; Thu, 02 Feb 2006 20:49:11 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k129kr219512 for dna-list; Thu, 02 Feb 2006 20:46:53 +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 k129kqu19508 for ; Thu, 02 Feb 2006 20:46:52 +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 <01LYI8JYC87C9AVAFP@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 20:46:47 +1100 Received: by localhost (Postfix, from userid 510) id EE0DDAB604; Thu, 02 Feb 2006 20:46:46 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.198]) by moe.its.monash.edu.au (Postfix) with ESMTP id DA94D4FB0D for ; Thu, 02 Feb 2006 20:46:36 +1100 (EST) Received: by uproxy.gmail.com with SMTP id y2so151617uge for ; Thu, 02 Feb 2006 01:46:33 -0800 (PST) Received: by 10.66.250.13 with SMTP id x13mr212053ugh; Thu, 02 Feb 2006 01:46:33 -0800 (PST) Received: by 10.66.234.6 with HTTP; Thu, 02 Feb 2006 01:46:33 -0800 (PST) Date: Thu, 02 Feb 2006 18:46:33 +0900 From: JinHyeock Choi Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <200601311638.k0VGcxbZ007692@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <92e919fb0602020146v1f50a4bfsfb88161250279605@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XVmZJkBWauXcnlFBtpTUdrs+GM2I7XdfntVJvGSZdJ1isrng8mTMmboFbUhFwL+T3a5JFYIfDEsGVzH71g7SHk8wSIPe7Ex+gCmezoDp32QhDoFd3ZRValSN7+1CdIT4I8OtHS1SNCHGB6i2djaisOY+sQ3KU+aZKwL89paT6Gw= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200601311638.k0VGcxbZ007692@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Dear Thomas I approach this in view point of how to manage IP configuration information (such as IP address) upon link down event. In short, I think that In case only link down event happens (without subsequent link up event), it's ok for a host to keep assigning the cached config information to the interface. Whereas in case link up event follows link down event, the host needs to perform DNA to check for link change. If a link change has happened, the host should discard the cached config information. If not, it can keep using the existing information. Kindly see the inline comments. > 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... I guess we'd better treat this problem in relationship with link up event. First link down event occurs. - Upon this event, I see few harm if a host keeps the existing config information in anticipation of link recovery till the lifetime expires. (Link-layer connection is broken, so communication is not possible anyway.) Second link up event occurs. - At this stage, the host can't be sure it still remains at the same link or not. So it starts DNA procedure. - It can still maintain the existing config information but keeps from using it (such as using the existing IP address as a source address). Third DNA completes - At this stage, the host can determine what to do with its existing config information, to discard or to keep using. * The only problem may be the case that a host is detached from a link for quite a long while, then reattach itself to the same link. Because, during the host's absence from the link, none protected the host's IP address (w.r.t. DAD), the host can't be sure that it's IP address is still unique. It may need to perform DAD once more. * Also I had a small experiment. I took the ethernet jack from my laptop and put it again some time later. It kept using the same IP address. :-) > 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. I think the above applies when there is no subsequent link up event. But, for example, if a host is re-attached to a new link within (say) 2 mins (and recognizes a link change), I guess hard error needs to 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. 'IP address' may be treated differently according to the length of detachment time. For example, we may make a rule as below. When a host is detached from a link less than 2 mins and reattaches itself to the same link, it can immediately use its IP address without DAD. On the other hand, if a host is detached from a link more than 2 mins, it should perform DAD before using its IP address even when it reattaches itself to the same link. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 06:21:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4cX5-0002uJ-7r for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 06:21:55 -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 GAA23145 for ; Thu, 2 Feb 2006 06:19:59 -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 <01LYIBSONELS9C7RDR@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 02 Feb 2006 22:20:31 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0FF2EAB546; Thu, 02 Feb 2006 22:20:06 +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 A4C4F4FB0B; Thu, 02 Feb 2006 22:20:05 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k12BJ7920872 for dna-list; Thu, 02 Feb 2006 22:19:07 +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 k12BIpu20866 for ; Thu, 02 Feb 2006 22:18:51 +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 <01LYIBQZY3O0AW2FY6@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 02 Feb 2006 22:18:49 +1100 Received: by localhost (Postfix, from userid 510) id 36A6CAB58C; Thu, 02 Feb 2006 22:18:45 +1100 (EST) Received: from [192.168.1.100] (cust1648.vic01.dataco.com.au [202.63.56.112]) (user brett) (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 69C8F4FB03; Thu, 02 Feb 2006 22:18:43 +1100 (EST) Date: Thu, 02 Feb 2006 22:18:47 +1100 From: Brett Pentland Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <200602020140.k121e4MG009522@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au Approved: monash-smtp-auth To: Thomas Narten Cc: Greg Daley , Syam Madanapalli , JinHyeock Choi , dna@eng.monash.edu.au, James Kempf , Sathya Narayanan , Erik Nordmark Message-id: <43E1EA97.5070904@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200602020140.k121e4MG009522@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT > OK. Could the authors please indicate what their plans are for > reissuing this document and what changes it will contain? (I've read > protocol3, but if another version is coming soone, I should probably > wait before commenting.) I've been trying to incorporate the feedback that we've had so far. It's in the process of being checked to see if the changes I've made are consistent, but you're welcome to see where it's at right now. See http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00.txt And a diff from protocol3 can be seen at: http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00-from-draft-pentland-dna-protocol3-00.diff.html There's a few issues that have come up while making the edits: - Should the explicit linkid always be in the LPO or can it be a flag in a PIO (the latter is in the draft)? - What order do the hosts treat the indications (land mark option, prefixes, linkid in the draft at present) - Given that we now have an explicit linkid, should we get rid of all of the flags in the landmark option - the no flag is not really needed and since taking that out would leave only one, we can probably get rid of that as well - LO in RA = yes (at present the flags are still there) Regards, Brett. PS. I'm still not clear on procedure: since draft-pentland-dna-protocol3-00.txt is what the WG accepted, does that have to become draft-ietf-dna-protocol-00.txt as is, or can the edited version become the -00 if there are no objections to the edits? From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 11:49:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4hea-0002cL-R8 for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 11:49:55 -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 LAA19833 for ; Thu, 2 Feb 2006 11:48:05 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYIN702LG2AW2H1E@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 03:46:34 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 98D9680004; Fri, 03 Feb 2006 03:46:13 +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 54A803C005; Fri, 03 Feb 2006 03:46:13 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k12GbLB24930 for dna-list; Fri, 03 Feb 2006 03:37:21 +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 k12Gaiu24900 for ; Fri, 03 Feb 2006 03:36: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 <01LYIMV0NNJ49C7URR@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 03:36:34 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EB031AB58C; Fri, 03 Feb 2006 03:36:33 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id C68454FB06; Fri, 03 Feb 2006 03:36:33 +1100 (EST) Received: from [150.169.1.178] by mail-store-2.its.monash.edu.au (mshttpd) ; Thu, 02 Feb 2006 11:36:33 -0500 Date: Thu, 02 Feb 2006 11:36:33 -0500 From: Greg Daley Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Thomas Narten , Syam Madanapalli , JinHyeock Choi , dna@eng.monash.edu.au, James Kempf , Sathya Narayanan , Erik Nordmark , suresh.krishnan@ericsson.com Message-id: <9c4d379c5b80.9c5b809c4d37@monash.edu.au> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Brett, The first part (technical) is personal opinion. I'll be tackling the procedural issues with explicit "hat" notification. ----- Original Message ----- From: Brett Pentland Date: Thursday, February 2, 2006 6:18 am Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt > > OK. Could the authors please indicate what their plans are for > > reissuing this document and what changes it will contain? (I've read > > protocol3, but if another version is coming soone, I should probably > > wait before commenting.) > > I've been trying to incorporate the feedback that we've had so > far. It's > in the process of being checked to see if the changes I've made are > consistent, but you're welcome to see where it's at right now. See > > http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol- pre00.txt > > And a diff from protocol3 can be seen at: > > http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00- > from-draft-pentland-dna-protocol3-00.diff.html > > There's a few issues that have come up while making the edits: > > - Should the explicit linkid always be in the LPO or can it be a > flag in a PIO (the latter is in the draft)? Personally, I prefer having as this means there's no need to include an LPO if all routers advertise the same prefix (which is also, naturally the prefix linkid) Of course this means the host needs to check each of the LPO and PIO options for the flag, but it needed to parse the options anyway. > - What order do the hosts treat the indications (land mark option, > prefixes, linkid in the draft at present) I think that we should note that there could be conflicts between these indications, either in a transition associated with router arrival or departure, or as an error condition. If that's the case, we should recommend a safe course of action: I'd suggest to act as if change has occurred (if there's sufficient trust of the RA). Does that make sense? > - Given that we now have an explicit linkid, should we get rid of > all of the flags in the landmark option - the no flag is not really > needed and since taking that out would leave only one, we can > probably get rid of that as well - LO in RA = yes (at present the > flags are still there) I agree (so long as the prefix matches that from the LO in the RS), but others may wish to state their position. > Regards, > Brett. > > PS. I'm still not clear on procedure: > since draft-pentland-dna-protocol3-00.txt is what the WG accepted, > doesthat have to become draft-ietf-dna-protocol-00.txt as is, or > can the > edited version become the -00 if there are no objections to the edits? I think that the current version is (draft-pentland-dna-protocol3-00) is accepted, and at the same time you're accepted as the editor. As the editor, you can start to make reasonable changes in accordance with the WG's opinion, from the time you receive that role. draft-ietf-dna-protocol-00 doesn't have to be a carbon copy of the accepted document, so long as the changes are in line with what the WG's direction is. So if you've already got some minor changes (like in the diff) that's fine. For the three issues you raised, please note and track them, and incorporate their solutions into -01. Does that make sense? If others need to discuss this please e-mail Suresh and I (on or off-list). Greg. I'm in New Jersey now, and may start using my new work e-mail address (Panasonic) for list postings. From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 13:53:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jaW-0004c6-PM for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 13:53:48 -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 NAA28892 for ; Thu, 2 Feb 2006 13:52:05 -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 <01LYIRK0VPMO9AVDZS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 05:51:20 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 38899AB544; Fri, 03 Feb 2006 05:51:15 +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 D35084FB30; Fri, 03 Feb 2006 05:51:14 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k12Icae26705 for dna-list; Fri, 03 Feb 2006 05:38:36 +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 k12Icau26701 for ; Fri, 03 Feb 2006 05:38:36 +1100 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 <01LYIR4AYQUA9AVHQO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 05:38:35 +1100 Received: by localhost (Postfix, from userid 510) id 3FE4F80002; Fri, 03 Feb 2006 05:38:35 +1100 (EST) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id D46003C00E for ; Fri, 03 Feb 2006 05:38:11 +1100 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k12IaQRB015436; Thu, 02 Feb 2006 20:38:07 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 02 Feb 2006 20:37:14 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 02 Feb 2006 12:37:12 -0600 Date: Thu, 02 Feb 2006 10:37:11 -0800 From: Mohan.Parthasarathy@nokia.com Subject: RE: [DNA] Model: how to treat "link down" events In-reply-to: <43E152C6.407@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: erik.nordmark@sun.com, narten@us.ibm.com Cc: dna@eng.monash.edu.au Message-id: <8A76136424391244A5CF01653370853701280A78@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: [DNA] Model: how to treat "link down" events Thread-Index: AcYnkPahBt3h6L8WSC2NFLZ8b8eujwAlY7pQ Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-OriginalArrivalTime: 02 Feb 2006 18:37:12.0654 (UTC) FILETIME=[AEB486E0:01C62827] Content-Transfer-Encoding: 7BIT > >> 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. > >FWIW I take exception to this interpretation. There is nothing in >2461/62 that leads me to believe this was the intent. > I agree with this. But i found this in 2462bis. A node forms a link-local address whenever an interface becomes enabled. An interface may become enabled after any of the following events: - The interface attaches to a link for the first time. This includes the case where the attached link is dynamically changed due to a change of the access point of wireless networks. What does it mean to form a new link-local address when you switch Access Points ? Does it mean throw away the old link-local address ? Only the link-local address ? I don't remember the discussion that lead to the above text. It sure does not say "throw away the old info". -mohan From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 13:55:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4jcJ-0005Bz-3m for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 13:55:39 -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 NAA29018 for ; Thu, 2 Feb 2006 13:54:01 -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 <01LYIRNW1A88AXBGCR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 05:54:40 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6897EAB604; Fri, 03 Feb 2006 05:54:22 +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 F36334FBD6; Fri, 03 Feb 2006 05:54:21 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k12Iqq826915 for dna-list; Fri, 03 Feb 2006 05:52:52 +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 k12Iqpu26911 for ; Fri, 03 Feb 2006 05:52:51 +1100 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 <01LYIRLXNBM49AVDZS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 05:52:48 +1100 Received: by localhost (Postfix, from userid 510) id 14AC380002; Fri, 03 Feb 2006 05:52:48 +1100 (EST) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 1297B3C011 for ; Fri, 03 Feb 2006 05:52:42 +1100 (EST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k12Ip1MN024782; Thu, 02 Feb 2006 20:51:09 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 02 Feb 2006 20:50:40 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 02 Feb 2006 12:50:38 -0600 Date: Thu, 02 Feb 2006 10:50:37 -0800 From: Mohan.Parthasarathy@nokia.com Subject: RE: [DNA] Model: how to treat "link down" events In-reply-to: <92e919fb0602020147td9214aagc302560c4e835ca7@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: jinchoe@gmail.com Cc: erik.nordmark@sun.com, narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <8A76136424391244A5CF01653370853701280A8C@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: [DNA] Model: how to treat "link down" events Thread-Index: AcYn3cly/0s7mDYaTl6/JpGDVOwgewASeorw Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-OriginalArrivalTime: 02 Feb 2006 18:50:38.0635 (UTC) FILETIME=[8F1B77B0:01C62829] Content-Transfer-Encoding: 7BIT > >> Is the following scenario possible ? >> >> 1) Host receives a link down event. Does not do anything. >> 2) Host attaches to the new link. Link UP event happens >> slightly late or the event has not propagated completely >> through the system. Meanwhile you are able to send and >> receive packets. > >I have difficulty understanding above. How can the host send/ >receive packets when it is attached to a new link in which it >has no IP configuration information such as IP address? > When a host attaches to the new link, as per the solution document, the host sends a RS with TSLLAO option to determine whether it has changed links or not. The source address of the RS is a link-local address which was previously in preferred state but now in optimistic state. If it knows that it moved to a new link, it discards old information and starts configuring new addresses from the RA. In the above scenario, as the host has not seen the Link UP trigger yet, it does not send the RS, does not set the addresses to Optimistic and just sitting there thinking it is old link. If another node attached to the same link with the same link-local address, both the nodes will respond to the NS and override flag will not be cleared in both of the NAs. Eventually right things will happen, when the RS goes out, but in a small window, there can be this problem. This is not a opti-DAD problem, because you send NA with override flag cleared when you are in optimistic mode. It looked to me that if you go to optimistic on seeing Link Down (i understand that it is not reliable etc..), then this problem (assuming it is one) may not happen. -mohan >Thanks for your kind consideration. > >Best Regards > >JinHyeock > From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 19:47:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4p6c-0002iG-Sx for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 19:47:23 -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 TAA05221 for ; Thu, 2 Feb 2006 19:45:28 -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 <01LYJ3XOX5HY9AVHGZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 11:45:55 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B54880002; Fri, 03 Feb 2006 11:45:52 +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 2C0343C017; Fri, 03 Feb 2006 11:45:52 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k130hKO31361 for dna-list; Fri, 03 Feb 2006 11:43:20 +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 k130hKu31357 for ; Fri, 03 Feb 2006 11:43:20 +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 <01LYJ3UJ6744AXBI4F@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 11:43:20 +1100 Received: by localhost (Postfix, from userid 510) id B99A0AB604; Fri, 03 Feb 2006 11:43:19 +1100 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7D4D14FB1B for ; Fri, 03 Feb 2006 11:43:18 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k130hFQj019292; Thu, 02 Feb 2006 17:43:16 -0700 (MST) 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 k130hEPR699761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 02 Feb 2006 16:43:15 -0800 (PST) Date: Thu, 02 Feb 2006 16:42:50 -0800 From: Erik Nordmark Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <43E152C6.407@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Thomas Narten , dna@eng.monash.edu.au Message-id: <43E2A70A.3020701@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: <200601311638.k0VGcxbZ007692@cichlid.raleigh.ibm.com> <43E152C6.407@sun.com> Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: > Thomas Narten wrote: >> 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. > > This discussion might be interesting, but I'm not sure it is critical or > even relevant to DNS, since we've designed DNA to only operate using Oops. s/DNS/DNA/ Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 20:37:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ptZ-0003Hj-QI for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 20:37:54 -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 UAA09033 for ; Thu, 2 Feb 2006 20:36:07 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYJ5GG52P6AW2FCU@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 12:29:57 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2B94A80004; Fri, 03 Feb 2006 12:29:14 +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 ACA313C005; Fri, 03 Feb 2006 12:29:13 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k131Src32019 for dna-list; Fri, 03 Feb 2006 12:28: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 k131Squ32013 for ; Fri, 03 Feb 2006 12:28:52 +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 <01LYJ5FONUQW9AVN17@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 12:28:37 +1100 Received: by localhost (Postfix, from userid 510) id 7855CAB58C; Fri, 03 Feb 2006 12:28:37 +1100 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5A5864FB26 for ; Fri, 03 Feb 2006 12:28:36 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.108.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k131SYdK025455; Thu, 02 Feb 2006 17:28:34 -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 k131SWrE712820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 02 Feb 2006 17:28:34 -0800 (PST) Date: Thu, 02 Feb 2006 17:28:09 -0800 From: Erik Nordmark Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <8A76136424391244A5CF01653370853701280A78@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Mohan.Parthasarathy@nokia.com Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43E2B1A9.2070705@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: <8A76136424391244A5CF01653370853701280A78@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Mohan.Parthasarathy@nokia.com wrote: > I agree with this. But i found this in 2462bis. > > A node forms a link-local address whenever an interface becomes > enabled. An interface may become enabled after any of the following > events: > > - The interface attaches to a link for the first time. This > includes the case where the attached link is dynamically changed > due to a change of the access point of wireless networks. > > What does it mean to form a new link-local address when you switch > Access Points ? Does it mean throw away the old link-local address ? > Only the link-local address ? I don't remember the discussion that lead > to the above text. It sure does not say "throw away the old info". It doesn't make much sense, since the link-local address (for most IPv6-over-foo specifications) is formed from some hardware IEEE address, thus forming it again would result in generating the same link local address. There is a legitimate question of when a host should redo (optimistic) DAD, but that is something which makes sense specifying in the DNA document(s) and not in 2462bis. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 20:37:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ptY-0003HR-OM for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 20:37:54 -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 UAA09032 for ; Thu, 2 Feb 2006 20:36:06 -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 <01LYJ56J4QTKAXBIAL@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 12:22:19 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 82D01AB556; Fri, 03 Feb 2006 12:21:14 +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 DC1CB4FB71; Fri, 03 Feb 2006 12:21:13 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k131L2s31914 for dna-list; Fri, 03 Feb 2006 12:21:02 +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 k131L1u31910 for ; Fri, 03 Feb 2006 12:21:01 +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 <01LYJ55L0T0OAXBIAM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 12:20:29 +1100 Received: by localhost (Postfix, from userid 510) id CD805AB542; Fri, 03 Feb 2006 12:20:28 +1100 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7C7BB4FB83 for ; Fri, 03 Feb 2006 12:18:02 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k131I14u009116; Thu, 02 Feb 2006 17:18:01 -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 k131Hxhe709520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 02 Feb 2006 17:18:01 -0800 (PST) Date: Thu, 02 Feb 2006 17:17:36 -0800 From: Erik Nordmark Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <8A76136424391244A5CF0165337085370128088D@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Michael.G.Williams@nokia.com Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43E2AF30.8010503@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: <8A76136424391244A5CF0165337085370128088D@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Michael.G.Williams@nokia.com wrote: > > The very last statement: > >> We can't rely on timely 'link down' events for DNA, hence it makes > sense to only rely on 'link up' >> events, which is what CPL and the DNA solution do. >> >> Erik > > If timely link down events were available (say from IEEE 802.21), would > that help things? I don't think they would help with DNA, since DNA on a single-homed host can't do much useful from knowing that the network disappeared. The upper layers, like application protocols, could stop waiting for the network to respond, but perhaps they should be patient and wait for it to come back. For multihomed hosts, in particular those having protocols like MOBIKE or SHIM6, getting a timely link down event helps to have it quickly switch to using an alternate network interface. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 20:43:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4pyd-0005pb-Tf for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 20:43:08 -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 UAA09328 for ; Thu, 2 Feb 2006 20:41:21 -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 <01LYJ5VV69Z29AVLV2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 12:41:48 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1A36AAB58D; Fri, 03 Feb 2006 12:41:40 +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 C3A384FB45; Fri, 03 Feb 2006 12:41:39 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k131fMR32228 for dna-list; Fri, 03 Feb 2006 12:41:22 +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 k131fLu32224 for ; Fri, 03 Feb 2006 12:41:21 +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 <01LYJ5V542CIAW2IZ0@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 12:41:05 +1100 Received: by localhost (Postfix, from userid 510) id 25364AB63B; Fri, 03 Feb 2006 12:41:05 +1100 (EST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by moe.its.monash.edu.au (Postfix) with ESMTP id 8A3904FB46 for ; Fri, 03 Feb 2006 12:41:03 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.106.31]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k131f18u023375; Thu, 02 Feb 2006 18:41:01 -0700 (MST) 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 k131exTw716494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 02 Feb 2006 17:41:00 -0800 (PST) Date: Thu, 02 Feb 2006 17:40:36 -0800 From: Erik Nordmark Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <200602011423.k11ENemC018379@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <43E2B494.8070606@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: <200602011423.k11ENemC018379@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > rereading section 4.5: Receiving valid Router Advertisements, > > I'm (generally) fine with the first part of this section. I.e., it > says that when a host receives the first RA (after a link up event): > > 1) if it contains a prefix in the CCL, assume no link change. > > 2) if it contains a prefix in retained Candidate Link Object, assume > host has moved back to that link. > > The interesting case is where one receives an RA containing only > prefixes that one has not seen before. It is this case that makes use > of the "complete" state. I.e., if the CCL is complete, one assumes > that learning a new prefix means an immediate move. But if the CCL is > not complete, one doesn't assume one has moved (yet). Specifically: > > [...] > > Could you clarify for me how the above relates to normal 2461/2462 > processing? I.e., I would assume that the new prefix should be > configured on the link immediately. Is this the case? We tried to make it clear that the host needs to separately track the prefixes it received before the link up and those that were received after, so that no matter what it does on the reception on the RA it can do the right thing should it later determine that it indeed moved to a different link. Thus an implementation could immediately add the prefix to the current set of prefixes. But then should it determine that it did move to a different link it needs to remove that prefix from the old candidate link object, and only use that prefix in the new candidate link object. Alternatively, an implementation could defer doing anything with the new prefix until DNA has completed. Then, if the host didn't move to a new link, it would add the prefix to the current list of prefixes. And if it did move to a different link it would know to only use the new prefix as the initial prefix list for that link. > Also, I'm not sure it's worth the complexity of waiting another 4 > seconds to gather additional RAs before declaring a move. Yes, but this is an unfortunate side effect of the generality of how prefixes can be advertised in RFC 2461/62. We know who to blame for that generality ;-) > Or maybe I don't understand what it means to "declare a move" and what > impact that has on the addresses configured on the interface. This > goes back to my message yesterday asking what processing we are > assuming happens upon a "link down" event. > > Given that as far as we know, most RAs include complete information, > why go to so much trouble to handle the case where this is not the > case, and where the cached information is "incomplete" (which also is > probably not the normal case), etc. FWIW this observation was what lead to one of the early proposals by JinHyeock for how to make DNA better - just including a "this RA is complete" bit in the Router Advertisement. > I agree that having a Complete Prefix List would be good, in the sense > that upon receipt of an RA, one is more likely to make a correct > determination about whether one has rejoined an existing link. > > However, the current document formalizes this too much, including > algorithms that are used to (in some sense) "declare" when one has a > complete list as opposed to maybe not having a complete list. I'm just > not convinced (yet) that this complexity has sufficient benefit in > practice. The notion is really more probabilistic than "know for sure" vs. "don't know yet". But in terms of the resulting behavior, there is a point where the host behaves as if it knows all the prefixes for a link, hence the "declare" aspect seemed to help when describing the behavior. If it doesn't help, we can certainly revisit the description. > So, it takes 4 seconds to complete DNA? I thought the whole point was > for DNA to complete quickly. Recall, using normal 2461/2462 in _MOST_ > cases, a single RS will trigger the transmission of RAs from _all_ > routers, and this will complete within .5 seconds. Thus, having DNA > operate for 4 seconds seems to miss the bigger picture. If we want reasonably robust and fast DNA, we do need some changes in the routers behavior. If we had a time machine and could go back and mandate in RFC 2461/62 that the list of prefixes each router advertises on the link MUST be identical, and that all prefixes for the link MUST fit in a single 1280 byte RA, then we could assume that every RA is complete. But given that 2461/62 doesn't mandate that, we sort of have to deal with what's might be out there. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 21:02:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4qGn-0001f8-BU for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 21:02: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 VAA10531 for ; Thu, 2 Feb 2006 21:00:06 -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 <01LYJ6GTUON8AXBIOT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 12:59:04 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4A2FCAB610; Fri, 03 Feb 2006 12:57: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 C98F24FBAB; Fri, 03 Feb 2006 12:57:46 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k131uZR32454 for dna-list; Fri, 03 Feb 2006 12:56:35 +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 k131uZu32450 for ; Fri, 03 Feb 2006 12:56:35 +1100 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 <01LYJ6F6LKM09C72I3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 12:56:28 +1100 Received: by localhost (Postfix, from userid 510) id D255B80002; Fri, 03 Feb 2006 12:56:27 +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 larry.its.monash.edu.au (Postfix) with ESMTP id 9E2E23C009 for ; Fri, 03 Feb 2006 12:56:26 +1100 (EST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k131uKWB014464; Fri, 03 Feb 2006 03:56:23 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 03 Feb 2006 03:56:20 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 02 Feb 2006 19:56:18 -0600 Date: Thu, 02 Feb 2006 17:56:16 -0800 From: Mohan.Parthasarathy@nokia.com Subject: RE: [DNA] Model: how to treat "link down" events In-reply-to: <43E2AE89.40805@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: erik.nordmark@sun.com Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <8A76136424391244A5CF01653370853701280D5C@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: [DNA] Model: how to treat "link down" events Thread-Index: AcYoX2jC5EfpQAgkQcSuOAfd59oEKAAAfPAA Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-OriginalArrivalTime: 03 Feb 2006 01:56:18.0762 (UTC) FILETIME=[063592A0:01C62865] Content-Transfer-Encoding: 7BIT >> Erik, >> >> Is the following scenario possible ? >> >> 1) Host receives a link down event. Does not do anything. >> 2) Host attaches to the new link. Link UP event happens >> slightly late or the event has not propagated completely >> through the system. Meanwhile you are able to send and >> receive packets. This is not good because you are not >> in the optimistic state yet and you are on the new link. > >We can't come up with any reliable DNA procedure in such a >case. One would more or less end up ignoring the 'link up' >event and just rely on the content of the RAs as suggested in >5 in CPL; but as stated that approach isn't robust; if a host >moves too often it can conclude that the union of prefixes >from multiple links are in fact the prefixes assigned to a single link. > >And the two authors of CPL and Thomas agree that we can drop >that section. > >So for a reliably DNA we do have to assume that the link up >event notifications are delivered in order relative to packets >arriving from the network interface. > The above case may not be an abnormal case. The "Link UP" event needs to be processed even though it has been generated by the lower layer. This may take some time. It is not atomic in the sense that when the event happens, no packets are allowed till the event is processed. Do you think that this case is a pathological case ? >Note that draft-pentland-dna-protocol* can do slightly (as in >epsilon) better than CPL, since the DNA procedure can tie the >received RA to the RS one way or another. But this doesn't >help tell whether the prefixes received in periodic, >unsolicited RAs belong to one link or another when there is no >'link up' event notification. > But see my other mail. My concern is what happens before the RS is sent and you are not receiving any RAs but some neighbor solicitations on the new link. -mohan > Erik > From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 21:04:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4qJ6-00028n-71 for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 21:04:16 -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 VAA10697 for ; Thu, 2 Feb 2006 21:02:29 -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 <01LYJ6NQJI589C6YDS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 13:03:30 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CA0B5AB542; Fri, 03 Feb 2006 13:03:20 +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 54FA04FB17; Fri, 03 Feb 2006 13:03:20 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k13233F32589 for dna-list; Fri, 03 Feb 2006 13:03:03 +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 k13232u32585 for ; Fri, 03 Feb 2006 13:03:02 +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 <01LYJ6N0X4KU9C6YDS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 13:02:47 +1100 Received: by localhost (Postfix, from userid 510) id 2F27DAB60D; Fri, 03 Feb 2006 13:02:47 +1100 (EST) Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by moe.its.monash.edu.au (Postfix) with ESMTP id 71A244FB07 for ; Fri, 03 Feb 2006 13:02:45 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.56.36]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k1322hxZ002453; Thu, 02 Feb 2006 18:02:43 -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 k1322gMB724167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 02 Feb 2006 18:02:43 -0800 (PST) Date: Thu, 02 Feb 2006 18:02:19 -0800 From: Erik Nordmark Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <200602020119.k121JMCk008895@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <43E2B9AB.8030006@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: <200602020119.k121JMCk008895@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > Right. I just started thinking about it as I was trying to understand > what information is associated with an interface when one gets a 'link > up' (i.e., there are some unstated assumptions being made in the DNA > drafts I think, and I'm trying to flesh them out). It wasn't > immediately obvious that (by default) any information would be > associated with an interface. OK. Since you've read it with a fresh pair of eyes you can help us make those assumptions explicit. > Ah.. but a router going away (with an apparently still working link) > strikes me as different than a link that goes down -- and for which we > get an explicit indication from the LL that the link has gone > down. Note: maybe ten years ago when we were doing the spec twisted > pair ethernet was a lot less ubiquitous and the notion that one got > 'link down' indications from the interface was a lot less > common. Wireless was still a dream... :-) I think we worried more about routers going away (perhaps they were flakier back then). But with wireless loosing the hosts attachment to the link (which isn't really "the link" going down) is a lot more common when you're at the edge of the coverage area or there is too much interference. > I don't mean to assert that. I do think that we (the community as a > whole) didn't think about this part in a lot of detail. I agree that the community didn't think that much about it, even if we had some reason that we picked 7/30 days for the default preferred and valid lifetimes. > What I'm trying to get at is: what assumption can be made about the > configuration information that is already associated with an interface > (i.e., from 2461/2426) at the time a 'link up' event takes place? > > I guess the obvious model is that whatever IP configuraiton > information was associated with the interface before the link up > (subject to any lifetime considerations) is assumed to still be > associated with the interface. Yes. > But think about this just from a 2461/2462 perspective (i.e., before > we started thinking about DNA). What would happen in practice in a > pre-DNA world? Suppose an RA is received on an interface, but it > indicates a new prefix that one has never heard of, and it doesn't > include any prefixes currently associated with the > interface. Shouldn't the old information be thrown away (since we > might be at a new link). It needs to be discarded at some point, not > because it has expired, but because it doesn't apply to the current > link anymore. some of that informaitn will stay around for a very long > time if one only looked at Lifetimes. [I don't recall any of this > being discussed in 2461/2462.] But here is where the flexibility of 2461/62 comes to bit us. The RFCs don't require that the routers on the link advertise the same set of prefixes, and they don't even require that a single router put all its prefixes in a single RA. (The latter part of the flexibility is necessary should a router have more prefixes to advertise than fits in a single 1280 byte RA.) Thus a RA might appear with a previously unknown prefix even though we are still attached to the same link. It might not be very common in the IPv6 deployment we have today, because I suspect there are relatively few prefixes for each link and that all the routers advertise the same prefixes. (But in the context of Nemo folks have discussed having different routers advertise different prefixes, which actually doesn't make much sense to me.) If we require a 'link up' event (and delivered in order with received packets as Mohan pointed out), then in what case could this generality bite us when the host didn't move to a new link: 1. Host receives link-up event. Sends a RS. 2. The first RA it receives is one that has a prefix that it hasn't seen in a RA on the link before. The probability of this RA being an unsolicited, periodic RA is quite small, since the solicited responses will all arrive within at worst 3.5 seconds. (.5 second random delay, plus if there are lots of hosts sending RSes, then the rate limit of at most one multicast RA every 3 seconds will kick in). Given that the default period RA timer is 30 minutes its unlikely that it will fire within that 3.5 second period. So most likely the host will receive a solicited RA. And most likely that RA will include prefixes that it has heard before. But the Internet is a complex, and as a result a flaky place. The wireless physics makes things less than perfect. Do we really want to add more flakiness by assuming that the first RA is always a complete one? We do need a change to the router behavior in any case to avoid waiting for .5 to 3.5 seconds for a RA. Can't we make CPL not introduce new sources of flakiness and have the DNA solution (like the ones we have on the table) also make sure the host can always tell for sure from a single RA whether it has moved or not? >> We can't rely on timely 'link down' events for DNA, hence it makes >> sense to only rely on 'link up' events, which is what CPL and the >> DNA solution do. > > Agreed that we can't _rely_ on them. But there are presumably cases > where they will occur. How should they be handled? Just note them , > but more-or-less silently ignore them? If we require reliable and ordered (with respect to received packets) 'link up' event notifications, then DNA doesn't need to look at 'link down' since they don't carry any useful information that helps us tell whether a future 'link up' will imply moving to a different link or staying at a different link. But protocols like MOBIKE and SHIM6 want to pay attention to a 'link down' event. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 21:08:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4qN5-00036M-QT for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 21:08:23 -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 VAA10977 for ; Thu, 2 Feb 2006 21:06: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 <01LYJ6PBIPK09AVI4V@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 13:04:43 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D8CCCAB610; Fri, 03 Feb 2006 13:04:37 +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 E97A24FBBA; Fri, 03 Feb 2006 13:04:36 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1324Tn32639 for dna-list; Fri, 03 Feb 2006 13:04:29 +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 k1324Tu32635 for ; Fri, 03 Feb 2006 13:04:29 +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 <01LYJ6OUJAGO9C7MOI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 13:04:15 +1100 Received: by localhost (Postfix, from userid 510) id 451C1AB544; Fri, 03 Feb 2006 13:04:14 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.205]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7541B4FB35 for ; Fri, 03 Feb 2006 13:03:50 +1100 (EST) Received: by uproxy.gmail.com with SMTP id m2so74369ugc for ; Thu, 02 Feb 2006 18:03:48 -0800 (PST) Received: by 10.66.164.4 with SMTP id m4mr700394uge; Thu, 02 Feb 2006 18:03:48 -0800 (PST) Received: by 10.66.234.6 with HTTP; Thu, 02 Feb 2006 18:03:48 -0800 (PST) Date: Fri, 03 Feb 2006 11:03:48 +0900 From: JinHyeock Choi Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <8A76136424391244A5CF01653370853701280A8C@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Mohan.Parthasarathy@nokia.com" Cc: erik.nordmark@sun.com, narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <92e919fb0602021803i42741b7bvb8c511674dae711@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n7gW1civ5DCgLUGoVlAoK8YwIIUvMB40V99t+jOeySarnAVvfN09KZAnrrsHpzWW9aw0rkgVNCMk6ucZ8hqOA2jLoSwsXqdkFMlP/J+PG9Tx0TtDZAlNLsQGJtE87JI72Orof2EuHfLCUanpzWciOrS4tO/ujLRyGdeJgaHumKM= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <92e919fb0602020147td9214aagc302560c4e835ca7@mail.gmail.com> <8A76136424391244A5CF01653370853701280A8C@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Dear Mohan Thanks for your kind clarification which made me see the light. :-) > When a host attaches to the new link, as per the solution > document, the host sends a RS with TSLLAO option to determine > whether it has changed links or not. The source address of the > RS is a link-local address which was previously in preferred > state but now in optimistic state. If it knows that it moved > to a new link, it discards old information and starts > configuring new addresses from the RA. In the above scenario, > as the host has not seen the Link UP trigger yet, it does > not send the RS, does not set the addresses to Optimistic > and just sitting there thinking it is old link. If another > node attached to the same link with the same link-local > address, both the nodes will respond to the NS and override > flag will not be cleared in both of the NAs. > Eventually right things will happen, when the RS goes out, > but in a small window, there can be this problem. This is > not a opti-DAD problem, because you send NA with override > flag cleared when you are in optimistic mode. > > It looked to me that if you go to optimistic on seeing > Link Down (i understand that it is not reliable etc..), then > this problem (assuming it is one) may not happen. Now I understand, thanks. :-) I think that even after seeing Link Down even, a host can maintain the current IP configuration information. But the host would better keep from using it (it switches to a kind of optimistic mode) until DNA procedure affirms that the host really is attached to the same link. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 21:30:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4qi1-0001Oy-Hm for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 21:30:02 -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 VAA12094 for ; Thu, 2 Feb 2006 21:28:23 -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 <01LYJ7IH756W9C7LTF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 13:29:01 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1D355AB547; Fri, 03 Feb 2006 13:28:07 +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 BE2054FB06; Fri, 03 Feb 2006 13:28:06 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k132RtU00524 for dna-list; Fri, 03 Feb 2006 13:27:55 +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 k132Rsu00520 for ; Fri, 03 Feb 2006 13:27:55 +1100 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 <01LYJ7I33P849AV9GV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 13:27:50 +1100 Received: by localhost (Postfix, from userid 510) id A858780011; Fri, 03 Feb 2006 13:27:49 +1100 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3396B3C00E for ; Fri, 03 Feb 2006 13:27:48 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k132Rl4u010472; Thu, 02 Feb 2006 18:27:47 -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 k132RjGq731501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 02 Feb 2006 18:27:46 -0800 (PST) Date: Thu, 02 Feb 2006 18:27:22 -0800 From: Erik Nordmark Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <8A76136424391244A5CF01653370853701280D5C@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Mohan.Parthasarathy@nokia.com Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43E2BF8A.2080504@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: <8A76136424391244A5CF01653370853701280D5C@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT > The above case may not be an abnormal case. The "Link UP" event > needs to be processed even though it has been generated by > the lower layer. This may take some time. It is not atomic in > the sense that when the event happens, no packets are allowed > till the event is processed. Do you think that this case is > a pathological case ? My simple model assumes the whole IP layer (including Neighbor Discovery and DNA) is a single event-driven loop, i.e. the link up event and receives NS packets would be processed in the order the device driver passes them up. If the implementation separates things, e.g., handling NS in the kernel and the 'link up' events in a daemon, then it needs to take care to preserve the ordering in this case. I don't think using 'link down' helps here, because we have the common case of AP handover, where the change from using one AP to another is more or less instantaneous. Even if we mandate a 'link down' in that case, it would be immediately be followed by a 'link up', thus a split implementation would still need to handle the ordering issue. I suspect it's not that hard to have a split implementation do the right thing. The 'link up' event can be used by the kernel to immediately set the optimistic DAD state, and then pass the event to the daemon that does DNA/RS/RA. That daemon will later tell the kernel when to turn off the optimistic state. But it sure is worth-while to list this as an implementation consideration, in addition to making a clear statement about the ordering/atomic behavior of the host as a whole for this issue. Do we put that in CPL or in draft-pentland? They both need the same thing. Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 02 21:42:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4qu7-0005RJ-BK for dna-archive@megatron.ietf.org; Thu, 02 Feb 2006 21:42:31 -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 VAA12791 for ; Thu, 2 Feb 2006 21:40:47 -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 <01LYJ50B5GAS9C7RZT@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 03 Feb 2006 12:16:18 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A16D1AB681; Fri, 03 Feb 2006 12:16:13 +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 C57764FBC1; Fri, 03 Feb 2006 12:16:12 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k131FXP31832 for dna-list; Fri, 03 Feb 2006 12:15:33 +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 k131FWu31828 for ; Fri, 03 Feb 2006 12:15:32 +1100 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 <01LYJ4Z6Y0DQ9AV9ZJ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 03 Feb 2006 12:15:19 +1100 Received: by localhost (Postfix, from userid 510) id BF7DA80003; Fri, 03 Feb 2006 12:15:19 +1100 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7EBE73C007 for ; Fri, 03 Feb 2006 12:15:18 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.104.45]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k131FE4u007702; Thu, 02 Feb 2006 17:15:14 -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 k131FD71708630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 02 Feb 2006 17:15:14 -0800 (PST) Date: Thu, 02 Feb 2006 17:14:49 -0800 From: Erik Nordmark Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <8A76136424391244A5CF0165337085370128084B@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Mohan.Parthasarathy@nokia.com Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43E2AE89.40805@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: <8A76136424391244A5CF0165337085370128084B@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Mohan.Parthasarathy@nokia.com wrote: > > Erik, > > Is the following scenario possible ? > > 1) Host receives a link down event. Does not do anything. > 2) Host attaches to the new link. Link UP event happens > slightly late or the event has not propagated completely > through the system. Meanwhile you are able to send and > receive packets. This is not good because you are not > in the optimistic state yet and you are on the new link. We can't come up with any reliable DNA procedure in such a case. One would more or less end up ignoring the 'link up' event and just rely on the content of the RAs as suggested in 5 in CPL; but as stated that approach isn't robust; if a host moves too often it can conclude that the union of prefixes from multiple links are in fact the prefixes assigned to a single link. And the two authors of CPL and Thomas agree that we can drop that section. So for a reliably DNA we do have to assume that the link up event notifications are delivered in order relative to packets arriving from the network interface. Note that draft-pentland-dna-protocol* can do slightly (as in epsilon) better than CPL, since the DNA procedure can tie the received RA to the RS one way or another. But this doesn't help tell whether the prefixes received in periodic, unsolicited RAs belong to one link or another when there is no 'link up' event notification. Erik From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 03 12:42:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54xR-0005bG-F3 for dna-archive@megatron.ietf.org; Fri, 03 Feb 2006 12:42:55 -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 MAA23358 for ; Fri, 3 Feb 2006 12:41:03 -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 <01LYK3EBIYCSAW2MCO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Feb 2006 04:41:11 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EDEF9AB58C; Sat, 04 Feb 2006 04:41:02 +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 A574B4FB26; Sat, 04 Feb 2006 04:41:02 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k13Hd3A12027 for dna-list; Sat, 04 Feb 2006 04:39:03 +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 k13Hd3u12023 for ; Sat, 04 Feb 2006 04:39:03 +1100 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 <01LYK3BSC9BG9C7BGO@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Feb 2006 04:39:00 +1100 Received: by localhost (Postfix, from userid 510) id 8F92080002; Sat, 04 Feb 2006 04:39:00 +1100 (EST) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 215733C005 for ; Sat, 04 Feb 2006 04:38:58 +1100 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k13HcnHL022059; Fri, 03 Feb 2006 19:38:52 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 03 Feb 2006 19:38:53 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 03 Feb 2006 11:38:48 -0600 Date: Fri, 03 Feb 2006 09:38:45 -0800 From: Mohan.Parthasarathy@nokia.com Subject: RE: [DNA] Model: how to treat "link down" events In-reply-to: <43E2BF8A.2080504@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: erik.nordmark@sun.com Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <8A76136424391244A5CF01653370853701280F1D@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: [DNA] Model: how to treat "link down" events Thread-Index: AcYoaX44rtWePsKrTO6lDtIBPvI8KgAfmX4w Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-OriginalArrivalTime: 03 Feb 2006 17:38:48.0197 (UTC) FILETIME=[B04C9350:01C628E8] Content-Transfer-Encoding: 7BIT > >> The above case may not be an abnormal case. The "Link UP" >event needs >> to be processed even though it has been generated by the >lower layer. >> This may take some time. It is not atomic in the sense that when the >> event happens, no packets are allowed till the event is >processed. Do >> you think that this case is a pathological case ? > >My simple model assumes the whole IP layer (including Neighbor >Discovery and DNA) is a single event-driven loop, i.e. the >link up event and receives NS packets would be processed in >the order the device driver passes them up. > >If the implementation separates things, e.g., handling NS in >the kernel and the 'link up' events in a daemon, then it needs >to take care to preserve the ordering in this case. > >I don't think using 'link down' helps here, because we have >the common case of AP handover, where the change from using >one AP to another is more or less instantaneous. Even if we >mandate a 'link down' in that case, it would be immediately be >followed by a 'link up', thus a split implementation would >still need to handle the ordering issue. > Yes, the ordering issue is just not between the control events but with respect to the packets received. I agree that setting optimistic on receiving Link down will not work because even that is not atomic. >I suspect it's not that hard to have a split implementation do >the right thing. The 'link up' event can be used by the kernel >to immediately set the optimistic DAD state, and then pass the >event to the daemon that does DNA/RS/RA. That daemon will >later tell the kernel when to turn off the optimistic state. > I agree that this is the only way it can work for maintaining the ordering. >But it sure is worth-while to list this as an implementation >consideration, in addition to making a clear statement about >the ordering/atomic behavior of the host as a whole for this issue. > Yes. Depending on the OS implementations, this is a very important issue to consider. >Do we put that in CPL or in draft-pentland? They both need the >same thing. > Agreed. thanks mohan > Erik > From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 03 14:15:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F56Or-0001In-06 for dna-archive@megatron.ietf.org; Fri, 03 Feb 2006 14:15:17 -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 OAA00550 for ; Fri, 3 Feb 2006 14:13:38 -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 <01LYK6N3Z5UG9AT6F1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Feb 2006 06:13:42 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8F737AB604; Sat, 04 Feb 2006 06:13:38 +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 199754FB49; Sat, 04 Feb 2006 06:13:38 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k13JCoi13198 for dna-list; Sat, 04 Feb 2006 06:12:50 +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 k13JCnu13194 for ; Sat, 04 Feb 2006 06:12:49 +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 <01LYK6LZQ4P29AVEM8@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Feb 2006 06:12:45 +1100 Received: by localhost (Postfix, from userid 510) id 49999AB604; Sat, 04 Feb 2006 06:12:42 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id D7CA54FB02 for ; Sat, 04 Feb 2006 06:12:40 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k13JCSXm020322; Fri, 03 Feb 2006 14:12:28 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 6E7B83C8175; Fri, 03 Feb 2006 14:12:07 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id 570F83C8173; Fri, 03 Feb 2006 14:12:07 -0500 (EST) Date: Fri, 03 Feb 2006 14:12:27 -0500 From: Greg Daley Subject: Re: [DNA] Model: how to treat "link down" events In-reply-to: <43E2BF8A.2080504@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Erik Nordmark Cc: Mohan.Parthasarathy@nokia.com, narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43E3AB1B.9090904@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:86.18414 C:19 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <8A76136424391244A5CF01653370853701280D5C@mvebe101.NOE.Nokia.com> <43E2BF8A.2080504@sun.com> Content-Transfer-Encoding: 7BIT Hi Erik, Erik Nordmark wrote: [cut] > > I suspect it's not that hard to have a split implementation do the right > thing. The 'link up' event can be used by the kernel to immediately set > the optimistic DAD state, and then pass the event to the daemon that > does DNA/RS/RA. That daemon will later tell the kernel when to turn off > the optimistic state. > > But it sure is worth-while to list this as an implementation > consideration, in addition to making a clear statement about the > ordering/atomic behavior of the host as a whole for this issue. > > Do we put that in CPL or in draft-pentland? They both need the > same thing. I think that the draft-ietf-dna-hosts already mentions some considerations about DAD optimistic behaviour. Perhaps it should go there. Thomas' question about whether CPL and Hosts are really separate still remains, although I think at an earlier time, the WG consensus was to keep the drafts separate. If they're separate, we may wish to send them paired to the IESG like SEND and CGA (RFC3971 and RFC3972). This could make some sense, as CGA is mechanism and SEND a system, like CPL is a mechanism, and DNA is a system. Opinions are welcome on this issue. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 03 17:58:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59t9-0001c9-7k for dna-archive@megatron.ietf.org; Fri, 03 Feb 2006 17:58:53 -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 RAA24412 for ; Fri, 3 Feb 2006 17:56:59 -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 <01LYKEG2TI5G9AVLOM@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 04 Feb 2006 09:57:08 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7E8F480005; Sat, 04 Feb 2006 09:57:02 +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 26E043C007; Sat, 04 Feb 2006 09:57:02 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k13Mu5c15915 for dna-list; Sat, 04 Feb 2006 09:56:05 +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 k13Mu3u15911 for ; Sat, 04 Feb 2006 09:56:03 +1100 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 <01LYKEEK74BY9AVM2W@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 04 Feb 2006 09:55:49 +1100 Received: by localhost (Postfix, from userid 510) id 2D69B80002; Sat, 04 Feb 2006 09:55:49 +1100 (EST) Received: from [192.168.1.100] (cust1648.vic01.dataco.com.au [202.63.56.112]) (user brett) (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 E6DCA3C00F; Sat, 04 Feb 2006 09:55:47 +1100 (EST) Date: Sat, 04 Feb 2006 09:56:04 +1100 From: Brett Pentland Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <9c4d379c5b80.9c5b809c4d37@monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au Approved: monash-smtp-auth To: Greg Daley Cc: Thomas Narten , Syam Madanapalli , JinHyeock Choi , dna@eng.monash.edu.au, James Kempf , Sathya Narayanan , Erik Nordmark , suresh.krishnan@ericsson.com Message-id: <43E3DF84.5080701@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <9c4d379c5b80.9c5b809c4d37@monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Greg, >> - Should the explicit linkid always be in the LPO or can it be a >> flag in a PIO (the latter is in the draft)? > > Personally, I prefer having as this means there's no need to include > an LPO if all routers advertise the same prefix (which is also, > naturally the prefix linkid) > Of course this means the host needs to check each of the LPO and > PIO options for the flag, but it needed to parse the options anyway. I agree. >> - What order do the hosts treat the indications (land mark option, >> prefixes, linkid in the draft at present) > > I think that we should note that there could be conflicts between > these indications, either in a transition associated with > router arrival or departure, or as an error condition. > > If that's the case, we should recommend a safe course of action: > I'd suggest to act as if change has occurred (if there's sufficient > trust of the RA). > > Does that make sense? Yes. There's a much bigger penalty for failing to detect link change than for mistakenly assuming change and reconfiguring (which fairly quickly recovers the old configuration). >> - Given that we now have an explicit linkid, should we get rid of >> all of the flags in the landmark option - the no flag is not really >> needed and since taking that out would leave only one, we can >> probably get rid of that as well - LO in RA = yes (at present the >> flags are still there) > > I agree (so long as the prefix matches that from the LO in the RS), > but others may wish to state their position. You agree that the flags should go? Good luck with the new job. Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 06 21:23:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6IW5-0008BM-FF for dna-archive@megatron.ietf.org; Mon, 06 Feb 2006 21:23:43 -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 VAA06511 for ; Mon, 6 Feb 2006 21:21:49 -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 <01LYOSHHB618AYK8ON@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 07 Feb 2006 13:22:45 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 35C2BAB546; Tue, 07 Feb 2006 13:22:12 +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 E80F74FB30; Tue, 07 Feb 2006 13:22:11 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k172F6U11198 for dna-list; Tue, 07 Feb 2006 13:15:06 +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 k172F5u11194 for ; Tue, 07 Feb 2006 13:15:05 +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 <01LYOS8F1LHU9C7S83@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 07 Feb 2006 13:14:54 +1100 Received: by localhost (Postfix, from userid 510) id DA36FAB608; Tue, 07 Feb 2006 13:14:53 +1100 (EST) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) (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 3A8FC4FB0D for ; Tue, 07 Feb 2006 13:14:51 +1100 (EST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k172EcTM031255; Tue, 07 Feb 2006 04:14:40 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 07 Feb 2006 04:14:41 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 06 Feb 2006 20:14:39 -0600 Date: Mon, 06 Feb 2006 18:14:37 -0800 From: Mohan.Parthasarathy@nokia.com Subject: RE: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <43DE9538.4030300@sun.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: erik.nordmark@sun.com, narten@us.ibm.com Cc: dna@eng.monash.edu.au Message-id: <8A76136424391244A5CF016533708537012C1BF8@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: [DNA] draft-ietf-dna-cpl-02.txt Thread-Index: AcYl7pgzliIAd3fcQrCUDt+x6tW7KAFnWlNg Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-OriginalArrivalTime: 07 Feb 2006 02:14:39.0429 (UTC) FILETIME=[3FE90750:01C62B8C] Content-Transfer-Encoding: 7BIT Erik, >> 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? > Can we keep this in the Appendix instead of deleting it ? At least i found it interesting :-) -mohan > Erik > From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 07 12:28:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6WdN-0000nf-MF for dna-archive@megatron.ietf.org; Tue, 07 Feb 2006 12:28:13 -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 MAA14293 for ; Tue, 7 Feb 2006 12:26:17 -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 <01LYPO1LLRDAAYKCA9@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 08 Feb 2006 04:25:51 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8F6B7AB58C; Wed, 08 Feb 2006 04:25:39 +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 37D794FB03; Wed, 08 Feb 2006 04:25:39 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k17HNXC22412 for dna-list; Wed, 08 Feb 2006 04:23:33 +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 k17HNXu22408 for ; Wed, 08 Feb 2006 04:23:33 +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 <01LYPNXVT1CKAW36IN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 08 Feb 2006 04:23:27 +1100 Received: by localhost (Postfix, from userid 510) id CBBD7AB58C; Wed, 08 Feb 2006 04:23:26 +1100 (EST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) (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 9E68F4FB03 for ; Wed, 08 Feb 2006 04:23:25 +1100 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k17HNMhr012494 for ; Tue, 07 Feb 2006 12:23:22 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k17HNM9P193856 for ; Tue, 07 Feb 2006 12:23:22 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k17HNMQ8024524 for ; Tue, 07 Feb 2006 12:23:22 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-146-84.mts.ibm.com [9.49.146.84]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k17HNKs7024408; Tue, 07 Feb 2006 12:23:21 -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 k17HNII5008668; Tue, 07 Feb 2006 12:23:19 -0500 Date: Tue, 07 Feb 2006 12:23:18 -0500 From: Thomas Narten Subject: [DNA] dna-cpl vs. dna-hosts In-reply-to: Message from Greg Daley "of Fri, 03 Feb 2006 14:12:27 EST." <43E3AB1B.9090904@research.panasonic.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: dna@eng.monash.edu.au Message-id: <200602071723.k17HNII5008668@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 > Thomas' question about whether CPL and Hosts are really > separate still remains, although I think at an earlier > time, the WG consensus was to keep the drafts separate. Why? And what is the benefit of keeping them separate? I just read through the dna-hosts document, and I can't quite figure out what its trying to do (relative to cpl). On the one hand, it (at a high-level) describes some issues with DNA, etc., without making specific recommendations. On the other hand, in some areas, it includes some fairly specific SHOULD/MAY type terminology and makes recommendations about adding random delays and such. I.e, much more like a spec. I strongly believe that we do not want two different documents on the standards track making recommmendations on what a host should do for DNA (to work with unmodified routers). All recommendations should be in one document, and the recommendatoin we want hosts to implement should be clear. As it stands now, there is some overlap beween the two documents, and there is some stuff covered in hosts that (if it needs covering) should probably be moved to cpl. So if there is some reasoning for why we need two documents (and how the content of those two documents complements, but does not overlap with each other), I'd like to hear it. Thomas From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 07 14:56:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6YxN-00020s-10 for dna-archive@megatron.ietf.org; Tue, 07 Feb 2006 14:56:59 -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 OAA25033 for ; Tue, 7 Feb 2006 14:55:06 -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 <01LYPTA2POYW9AVLPN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 08 Feb 2006 06:56:05 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E819B80002; Wed, 08 Feb 2006 06:56:02 +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 9789C3C003; Wed, 08 Feb 2006 06:56:02 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k17Jt5Y24274 for dna-list; Wed, 08 Feb 2006 06:55:05 +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 k17Jt4u24270 for ; Wed, 08 Feb 2006 06:55:04 +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 <01LYPT8R21CIAW374M@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 08 Feb 2006 06:54:59 +1100 Received: by localhost (Postfix, from userid 510) id EEF0780002; Wed, 08 Feb 2006 06:54:58 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 898B83C00B for ; Wed, 08 Feb 2006 06:54:57 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k17JsulC022132; Tue, 07 Feb 2006 14:54:56 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 3B1413C81EE; Tue, 07 Feb 2006 14:54:32 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id 1E9AB3C81DB; Tue, 07 Feb 2006 14:54:32 -0500 (EST) Date: Tue, 07 Feb 2006 14:54:53 -0500 From: Greg Daley Subject: Re: [DNA] dna-cpl vs. dna-hosts In-reply-to: <200602071723.k17HNII5008668@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <43E8FB0D.2030105@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:60.51324 C:8 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <200602071723.k17HNII5008668@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Dear Thomas, Thomas Narten wrote: >> Thomas' question about whether CPL and Hosts are really >> separate still remains, although I think at an earlier >> time, the WG consensus was to keep the drafts separate. > > Why? And what is the benefit of keeping them separate? Personally, I've no objection to combining them, although there was an intention at the time (as I recall, -hosts and -routers were combined at the time, and there was even more text in them). We need to check that it's a good match if there's to be merger (this is what we're doing now). We'd want to see what the WG says, so I encourage people to show an opinion. > I just read through the dna-hosts document, and I can't quite figure > out what its trying to do (relative to cpl). On the one hand, it (at a > high-level) describes some issues with DNA, etc., without making > specific recommendations. On the other hand, in some areas, it > includes some fairly specific SHOULD/MAY type terminology and makes > recommendations about adding random delays and such. I.e, much more > like a spec. Hosts does include a lot of the background and motivation which was omitted from CPL, for example information pertaining to points 4) and 5) mentioned in your review of the document. Where existing recommendations were superceded by the CPL algorithm, the hosts document was reorganized to refer to the algorithm, without duplicating it (except for a stub in section 4.2.2 of -hosts) > I strongly believe that we do not want two different documents on the > standards track making recommmendations on what a host should do for > DNA (to work with unmodified routers). All recommendations should be > in one document, and the recommendatoin we want hosts to implement > should be clear. I think the important thing is clarity. > As it stands now, there is some overlap beween the two documents, and > there is some stuff covered in hosts that (if it needs covering) > should probably be moved to cpl. Or the other way around, depending on whether you see CPL as the core, or a component in the description... I'll have a look through both documents, and see how much redundancy and waffle there is (within the documents and between them). I'll try to post a per paragraph analysis overnight. > So if there is some reasoning for why we need two documents (and how > the content of those two documents complements, but does not overlap > with each other), I'd like to hear it. Indeed. At least we can cut down redundant information. If the documents are co-dependent, then it may be OK to combine them. Others' opinions are earnestly sought. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 08 05:19:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6mQN-0007gx-4Y for dna-archive@megatron.ietf.org; Wed, 08 Feb 2006 05:19:47 -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 FAA07354 for ; Wed, 8 Feb 2006 05:18:03 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYQNE8BDDSAW3AED@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 08 Feb 2006 21:18:40 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8C14D80005; Wed, 08 Feb 2006 21:18:23 +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 4A2B13C003; Wed, 08 Feb 2006 21:18:23 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k18AH4E00985 for dna-list; Wed, 08 Feb 2006 21:17:04 +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 k18AH3u00981 for ; Wed, 08 Feb 2006 21:17:03 +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 <01LYQNCJRGJ89AVMI3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 08 Feb 2006 21:17:02 +1100 Received: by localhost (Postfix, from userid 510) id 5540CAB544; Wed, 08 Feb 2006 21:17:02 +1100 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) (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 5D6614FB2B for ; Wed, 08 Feb 2006 21:16:58 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k18AGstv017820; Wed, 08 Feb 2006 11:16:54 +0100 Received: from l2.rennes.enst-bretagne.fr (l2.rennes.enst-bretagne.fr [192.44.77.4]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k18AGqXg017808; Wed, 08 Feb 2006 11:16:52 +0100 Received: from [192.44.77.137] (nik [192.44.77.137]) (authenticated bits=0) by l2.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k18AGpwT006213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 08 Feb 2006 11:16:51 +0100 Date: Wed, 08 Feb 2006 11:22:17 +0100 From: Nicolas Montavont Subject: Re: [DNA] comments on draft-ietf-dna-routers-01.txt In-reply-to: <8A76136424391244A5CF01653370853701201D43@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Mohan.Parthasarathy@nokia.com Cc: dna@eng.monash.edu.au Message-id: <43E9C659.3090201@enst-bretagne.fr> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Virus-Scanned: amavisd-new at enst-bretagne.fr References: <8A76136424391244A5CF01653370853701201D43@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Dear Mohan, Thank you very much for you review. The modified version of the draft can be found at http://jules.nautilus6.org/~montavont/draft-ietf-dna-routers-01.txt I have some questions, please see below (I removed the comments in this response for which we modified the draft) Mohan.Parthasarathy@nokia.com wrote: >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 >--------- > ... >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. > The fact that routers on a link respond with either unicast or multicast RA to RS does not change the number of RAs that are sent on the link, if there are multiple routers. So I don't see why this is a dis-advantage of using unicast RA. Am I missing 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 ? > This is to introduce a context where routers advertising valid and preferred lifetimes is usefull. It is particularly needed when hosts are highly mobile and frequently change IPv6 links. It allows for the hosts to keep up-to-date information. > >-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.. > This is to reduce the bandwidth consumed by RA. Reducing the frequency of one router is enough for rapid link detection. Do you think we need to add an explanation? > >- 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 removed some sentences. Please check if it is fine now. > >- I see little value for the Appendix A. > Do you think we should ask the WG to remove this appendix? Thanks again for your review. Nicolas From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 08 13:36:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6uAh-0000v7-D6 for dna-archive@megatron.ietf.org; Wed, 08 Feb 2006 13:36:07 -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 NAA19735 for ; Wed, 8 Feb 2006 13:34:24 -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 <01LYR4PJ6DYEAYKKEI@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 09 Feb 2006 05:34:18 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6CC18AB544; Thu, 09 Feb 2006 05:33:52 +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 EE7124FB1B; Thu, 09 Feb 2006 05:33:50 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k18IRbv06394 for dna-list; Thu, 09 Feb 2006 05:27:37 +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 k18IRbu06390 for ; Thu, 09 Feb 2006 05:27:37 +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 <01LYR4HKK8LQ9C7Z1X@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 09 Feb 2006 05:27:27 +1100 Received: by localhost (Postfix, from userid 510) id 9A9B8AB542; Thu, 09 Feb 2006 05:27:27 +1100 (EST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by curly.its.monash.edu.au (Postfix) with ESMTP id 5CF5D4FB1B for ; Thu, 09 Feb 2006 05:27:26 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.108.31]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k18IROSD008538; Wed, 08 Feb 2006 11:27:24 -0700 (MST) 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 k18IRM25859003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 08 Feb 2006 10:27:24 -0800 (PST) Date: Wed, 08 Feb 2006 10:26:51 -0800 From: Erik Nordmark Subject: Re: [DNA] draft-ietf-dna-cpl-02.txt In-reply-to: <8A76136424391244A5CF016533708537012C1BF8@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Mohan.Parthasarathy@nokia.com Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43EA37EB.7080101@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: <8A76136424391244A5CF016533708537012C1BF8@mvebe101.NOE.Nokia.com> Content-Transfer-Encoding: 7BIT Mohan.Parthasarathy@nokia.com wrote: > Erik, > >>> 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? >> > Can we keep this in the Appendix instead of deleting it ? > At least i found it interesting :-) Perhaps we'll end up with more appendicies than meat in the document, in which case I guess we could have a separate "DNA design considerations" document containing that type background information. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 08 13:36:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6uAz-0000xX-GH for dna-archive@megatron.ietf.org; Wed, 08 Feb 2006 13:36:25 -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 NAA19754 for ; Wed, 8 Feb 2006 13:34:35 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYR4RON7Y2AYKMSM@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 09 Feb 2006 05:35:45 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B3C6A80003; Thu, 09 Feb 2006 05:35:36 +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 5C2C93C00A; Thu, 09 Feb 2006 05:35:36 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k18IZWC06511 for dna-list; Thu, 09 Feb 2006 05:35:32 +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 k18IZVu06507 for ; Thu, 09 Feb 2006 05:35:31 +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 <01LYR4R9O5Y49AUY7R@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 09 Feb 2006 05:35:16 +1100 Received: by localhost (Postfix, from userid 510) id AF3E8AB542; Thu, 09 Feb 2006 05:35:16 +1100 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by curly.its.monash.edu.au (Postfix) with ESMTP id AABA74FB08 for ; Thu, 09 Feb 2006 05:35:15 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k18IZDQj011509; Wed, 08 Feb 2006 11:35:13 -0700 (MST) 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 k18IZ8Ll860992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 08 Feb 2006 10:35:13 -0800 (PST) Date: Wed, 08 Feb 2006 10:34:37 -0800 From: Erik Nordmark Subject: Re: [DNA] dna-cpl vs. dna-hosts In-reply-to: <200602071723.k17HNII5008668@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: Greg Daley , dna@eng.monash.edu.au Message-id: <43EA39BD.5030504@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: <200602071723.k17HNII5008668@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: >> Thomas' question about whether CPL and Hosts are really >> separate still remains, although I think at an earlier >> time, the WG consensus was to keep the drafts separate. > > Why? And what is the benefit of keeping them separate? Perhaps the WG viewed it as the path of least resistance when dealing with multiple already existing documents? Another path of low resistance is to concatenate the two documents, but I don't think that makes things any more clear for the reader. > I just read through the dna-hosts document, and I can't quite figure > out what its trying to do (relative to cpl). On the one hand, it (at a > high-level) describes some issues with DNA, etc., without making > specific recommendations. On the other hand, in some areas, it > includes some fairly specific SHOULD/MAY type terminology and makes > recommendations about adding random delays and such. I.e, much more > like a spec. > > I strongly believe that we do not want two different documents on the > standards track making recommmendations on what a host should do for > DNA (to work with unmodified routers). All recommendations should be > in one document, and the recommendatoin we want hosts to implement > should be clear. Did you find background material in DNA hosts that would fit into a "design considerations" type document? We have at least two things in the CPL document which could be moved to such a document (the probability calculations, and section 5 that you asked we remove and that Mohan wants to keep as interesting reading). FWIW Once we have a path forward for these two documents, I think there is a corresponding issue with the "unmodified router" and "modified router" documents (CPL/hosts draft vs. DNA protocol draft) in that - there is some things that are common (when/how to do MLD, DAD, and the description of the 'link up' event) - a host implementor would find it easier if both were described in the same place. But a router implementor only cares about a subset of what is in the DNA protocol draft. Erik From dna-owner@webcamserver.eng.monash.edu.au Wed Feb 08 16:39:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6x1o-0002Q8-2j for dna-archive@megatron.ietf.org; Wed, 08 Feb 2006 16:39:08 -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 QAA05659 for ; Wed, 8 Feb 2006 16:37:23 -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 <01LYRAZ3K40Y9AVQTI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 09 Feb 2006 08:33:27 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 29B58AB544; Thu, 09 Feb 2006 08:33:23 +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 A8FF04FB30; Thu, 09 Feb 2006 08:33:22 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k18LVwi08367 for dna-list; Thu, 09 Feb 2006 08:31:58 +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 k18LVvu08363 for ; Thu, 09 Feb 2006 08:31:57 +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 <01LYRAX05FSKAYKNMC@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 09 Feb 2006 08:31:42 +1100 Received: by localhost (Postfix, from userid 510) id 10C3880003; Thu, 09 Feb 2006 08:31:42 +1100 (EST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) (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 C4C053C009 for ; Thu, 09 Feb 2006 08:31:39 +1100 (EST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k18LVaLN029978 for ; Wed, 08 Feb 2006 16:31:36 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k18LVagU205562 for ; Wed, 08 Feb 2006 16:31:36 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k18LVaAa008069 for ; Wed, 08 Feb 2006 16:31:36 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-203-123.mts.ibm.com [9.65.203.123]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k18LVZT0008006 for ; Wed, 08 Feb 2006 16:31:35 -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 k18LVYZM012621 for ; Wed, 08 Feb 2006 16:31:35 -0500 Date: Wed, 08 Feb 2006 16:31:34 -0500 From: Thomas Narten Subject: [DNA] High-level overview of DNA, take 2 Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <200602082131.k18LVYZM012621@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 Here's a much longer attempt at describing the DNA landscape at a high-level. My goals in writing this down include to be sure I understand the current thinking in the WG, and to have it in text form so that others can (hopefully) come up to speed more quickly. It may also be useful to have some or all of this text appear in the documents being worked on, to make them easier to understand. Finally, I hope this allows us to break the problem space down better in a way that allows us to talk about components individually and more constructively. At the end, I have a number of questions. 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 comes up for the first time, a host relies on RAs to provide the needed configuration information. At the time 2461/2462 were written, little thought was given to the details of how to process a "link down" event (when one is available), or how to handle a "link up" event for an interface that was previously up, perhaps only a few seconds ago. With the increased proliferation of wireless networks, it is now common to receive "link up" indications that may (or may not) indicate that a configuration change has occurred at the IP layer (i.e., one has moved from one link to another). DNA is the process of (quickly) determining whether one is attached to a previously visited link, in order to minimize service disruptions upon attaching to a link. DNA requires that a host keep track of the links to which it has recently attached. For each known link, information about that link, such as default router addresses, prefix information, MTU, Lifetimes, etc. are kept in what are called Link Instances (aka Candidate Link Objects in dna-cpl). Link Instances are identified by the set of on-link global prefixes that have been advertised on that link, as no prefix may be assigned to different links simultaneously. At any given time, one LI is considered the Current LI, and the parameters associated with the CLI are what are actually configured on the link as defined in 2461/2462. When a "link up" event is detected, a host will need to determine what IP configuration parameters should be used. A simple (but naive) approach would be to discard all associated information and initiate the normal startup procedure as described in 2461/2462. However, this has the downside of causing upper-layer protocols using the (just discarded) addresses to possibly receive "hard errors" and terminate connections using those addresses. In the common case where a link goes away momentarily and then comes back up connected to the same link (with the same associated config information) this is obviously undesirable. DNA takes the approach that upon reciept of a "link up" event, the most-recently used configuration information should continue to be used, and that DNA should be initiated to (quickly) determine whether one is attached to a new link, or one to which one has been previously attached. In the simple case, DNA will quickly determine whether one has reattached to the current link or to another known link. Specifically, it will do so by sending a single RS and receiving a single RA, one containing a prefix that it has seen before, thereby identifying the link. In such cases, DNA can declare its work done, and any new prefixes in the received RA are added to the CLI. In some scenarios, however, things are more complex. Specifically, DNA may receive an RA that contains only prefixes it has never seen before. When this happens, it may not be sure whether the prefixes correspond to a new link (i.e., one not visited before), or a previously-visited link, but for which it has not yet seen all the advertised prefixes. While it might be simplest to assume that receipt of such an RA indicated attachment to a new link, that can lead to (incorrectly) invalidating other configuration information for that link. To handle this case, DNA takes extra steps. First, it distinguishes between "complete" and "incomplete" LIs. Complete LIs are those for which there is a high probability of having recieved all prefixes being advertised on that link. Incomplete LIs are those for which insufficient time has elapsed to conclude with reasonable certainty that it is likely that all advertised prefixes have been seen. When DNA receives an RA advertising (only) unknown prefixes, and the CLI is not "complete", DNA waits for additional RAs before deciding whether the link is new or not. The DNA procedure is tightly coupled with the use of 2461/2462, since DNA uses the same messages. There are two variants of DNA. In the first variant, hosts interact with routers that have implemented 2461/2462, but have not implemented any DNA extensions. One of the key limitations in this case is that RAs are not required to include all prefixes, so reciept of an RA from a router is not sufficient to learn all the prefixes that (or other) routers might be advertising. The DNA approach for handling this case has been described above. In the second variant, both hosts and routers can be upgraded with DNA extensions. The proposed DNA extensions in this case include: a) routers are permitted to respond more quickly to received RSs, by having all routers on the link keep track of each other, and then stagger their responses so that if there are N routers present, one router responds during interval Time/N, the next during 2*Time/N, etc. [pentland-protocol3] b) allow hosts to include a prefix in the RS that the router echos back in the RA, if the prefix is still valid on the link. That way the host can learn immediately if it is reconnecting to a previously visited link. [landmark option in pentland-protocol3] c) have RAs include a "complete" bit, that routers set to indicate that the RA includes all the known RAs it is configured to advertise (plus the Learned Prefix Option described in d). This allows a host to quickly learn if any prefixes are being omitted from a particular RA. d) Definition of a Learned Prefix option that routers use to proxy prefixes that they do not themselves advertise, but that they have observed other routers advertising. Hosts do not use those prefixes to autoconfigure addresses; they do use them to learn (in a single RA) all prefixes believed to be in use on that link. With this information, the host can definitively determine whether it is connecting to a new link or revisiting an old one. Some key questions for DNA. 1) when reusing "old" config, do we need to do anything special? E.g., change state of ND entries to STALE? Put addresses in Optimistic state? Take into account how much time has elapsed since we were last attached (or just assume this happens as part of normal ND timers?) What harm can occur from continuing to use the same information? how does this compare with the harm of delaying the configuration of an interface until one is more certain? 2) Upon "link up", does DNA need to delay sending an RS per the 2461/2462 rule? Are there ways to relax this that are consistent with the original concerns that led to the existing wording in 2461/2462? 3) Upon "link up", what messages can host send that would help it to quickly determine if on same link? Is it just an RS? what about unicast? what about an NS (e.g., perhaps including a Landmark option)? Are there other messages that can be sent that could help? Like NS queries unicast to known routers? Note: on some links, like wireless ethernet, multicast is (relatively) "expensive". Would it be better to just send a few immediate unicast NS (or RS) messages to the routers we know about? and send a multicast RS only if the unicast fails? Or do both in parallel? 4) When one gets an RA containing prefixes that one has not seen before, is the algorithm in CPA sufficient or ideal? Are there other probes one could send? E.g., upon indication that a new prefix is available, send additional probes quickly to try and flush out things more quickly? Or, should the host keep additional info in LIs, e.g., keeping track of which router advertised what prefixes, so that it can distingish "prefix from previously unknown router" vs. "new prefix from router we've received RAs from before"? 5) When DNA determines that one is no longer connected to the same link as before, one swaps configs. Care must be taken to apply information learned from RAs received since last "link up" get applied to correct LI. 6) if DNA determines that was has reconnected to the same link, what else needs to be done? Rerun DAD? Do nothing? Does the answer depend on how long it has been since one was previously connected to that link? 7) Is there ever a time when one should discard still-valid prefix information on a link? That is, suppose a bogus router shows up and sends out an RA with prefix information with a long Lifetime. This information may stay associated with a link for weeks, because no router ever advertises the prefix with a Lifetime of 0. Pre-DNA, that info would presumably get discarded more quickly because one doesn't keep old LI information around. But with DNA, we may find this happens and causes problems. For robustness, it seems like it might be desirable to discard prefix information in the _absence_ of RAs containing that prefix, in the case where other RAs continue to be received with other prefix information. I.e., if one knows that one has missed (say) N RAs, time out the info if one is receiving other info from other routers. (note: the situation is further aggrevated by having routers cache RAs learned from other routers.) Thomas From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 09 00:32:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F74PR-0000US-Fg for dna-archive@megatron.ietf.org; Thu, 09 Feb 2006 00:32:03 -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 AAA16848 for ; Thu, 9 Feb 2006 00:30:07 -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 <01LYRRLPON9Y9AVNHN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 09 Feb 2006 16:29:49 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0DA2880004; Thu, 09 Feb 2006 16:29:45 +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 B0A683C007; Thu, 09 Feb 2006 16:29:44 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k195SlK13742 for dna-list; Thu, 09 Feb 2006 16:28:47 +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 k195Sku13738 for ; Thu, 09 Feb 2006 16:28:46 +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 <01LYRRK6CFLAAZT01G@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 09 Feb 2006 16:28:30 +1100 Received: by localhost (Postfix, from userid 510) id B1B6A80005; Thu, 09 Feb 2006 16:28:30 +1100 (EST) Received: from hotmail.com (bay106-f17.bay106.hotmail.com [65.54.161.27]) by larry.its.monash.edu.au (Postfix) with ESMTP id E561D3C00A for ; Thu, 09 Feb 2006 16:28:29 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 08 Feb 2006 21:28:28 -0800 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 09 Feb 2006 05:28:28 +0000 (GMT) Date: Wed, 08 Feb 2006 21:28:28 -0800 From: Bernard Aboba Subject: RE: [DNA] High-level overview of DNA, take 2 In-reply-to: <200602082131.k18LVYZM012621@cichlid.raleigh.ibm.com> X-Originating-IP: [131.107.0.87] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 09 Feb 2006 05:28:28.0586 (UTC) FILETIME=[A84110A0:01C62D39] Content-Transfer-Encoding: 7BIT \> Are there other messages that can be sent that could help? Like NS > queries unicast to known routers? This is what DNAv4 does (via unicast ARP), because this enables a determination of whether the host has connected to a previously encountered router, without ambiguity. > Note: on some links, like wireless ethernet, multicast is > (relatively) "expensive". Would it be better to just send a few > immediate unicast NS (or RS) messages to the routers we know about? > and send a multicast RS only if the unicast fails? Or do both in > parallel? DNAv4 does both DHCP and DNA in parallel. DNAv4 is handled solely via unicast ARP, because on some links multicast not only is sent to many more hosts, but also is sent at much lower rate. For example, with IEEE 802.11n, it would be possible to send *a hundred* unicast packets at 100 Mbps at the same cost in expended slots as one multicast packet at 1 Mbps. This means that in practice a single multicast RS will cost more than sending unicast RS or NS messages to all previous routers. From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 09 08:33:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Bve-0004LV-7Z for dna-archive@megatron.ietf.org; Thu, 09 Feb 2006 08:33:52 -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 IAA21395 for ; Thu, 9 Feb 2006 08:31:54 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYS8HG47SMAZT37J@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 10 Feb 2006 00:32:55 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EE79480005; Fri, 10 Feb 2006 00:32:40 +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 A59A13C008; Fri, 10 Feb 2006 00:32:40 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k19DVLE18735 for dna-list; Fri, 10 Feb 2006 00:31:21 +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 k19DVLu18731 for ; Fri, 10 Feb 2006 00:31: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 <01LYS8FK25VEAZT377@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 10 Feb 2006 00:31:09 +1100 Received: by localhost (Postfix, from userid 510) id A2AC9AB544; Fri, 10 Feb 2006 00:31:09 +1100 (EST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) (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 41A054FB35 for ; Fri, 10 Feb 2006 00:31:08 +1100 (EST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k19DV5Xx030908 for ; Thu, 09 Feb 2006 08:31:05 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k19DV53n194040 for ; Thu, 09 Feb 2006 08:31:06 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k19DV5Oc021303 for ; Thu, 09 Feb 2006 08:31:05 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-203-123.mts.ibm.com [9.65.203.123]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k19DV54Z021233; Thu, 09 Feb 2006 08:31:05 -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 k19DV0fH027627; Thu, 09 Feb 2006 08:31:00 -0500 Date: Thu, 09 Feb 2006 08:31:00 -0500 From: Thomas Narten Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: Message from Bernard Aboba "of Wed, 08 Feb 2006 21:28:28 PST." Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: dna@eng.monash.edu.au Message-id: <200602091331.k19DV0fH027627@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 > \> Are there other messages that can be sent that could help? Like NS > > queries unicast to known routers? > This is what DNAv4 does (via unicast ARP), because this enables a > determination of whether the host has connected to a previously encountered > router, without ambiguity. Indeed, the DNAv4 approach is what led me to ask that question. DNAv4 uses ARP. Shouldn't we think about using an NS? It's unicast, and already includes the "R" bit, so we know whether the node is a default router or not. Perhaps it make sense to add some options that benefit DNA. (The same options could be used in RSs too, if that makes sense.) One issue that seems to be carrying a lot of weight on the DNAv6 side is that with RS/RAs, one (only) learns the router's link-local and link-layer addresses. But these two together are insufficient to uniquely identify a link, since both can be used on different links at the same time. Why not allow inclusion of a landmark option in an NS/NA? One benefit of an NS is that we presumably don't have to delay sending one, and the responder doesn't delay in responding. So this can be very fast. Another thought I have. When one gets a "link up" event, one wants to know if one is reattaching to a previously known link. The pentland-protocol3 draft assumes that the best way do do that is by including all prefixes in RAs. However, this has the disadvantage that routers have to listen to other RAs and (effectively) do a proxy advertisement for prefixes it itself is not advertising. I have some fairly strong qualms about that approach... On the other hand, a lower overhead mechanism would be to be able to ask "are you the same router on link Foo that I was talking to previously?" If the answer is yes, one can conclude that one is on the same link as earlier. One way to do this might be to define a new option, called (say) the Link/Interface Identifier option, that serves as a sort of globally unique identifer for an interface on a specific link. The router could generate the identifier by (say) hashing its link-local address, internal serial number, internal interface identifier, and time of reboot. The idea is that even if a router used the same LL address (and link-layer address) on multiple interfaces, the Link/Interface Identifier would be different on the different interfaces. One benefit of an approach like this is that a router can generate the identifier using only local information, without coordinating with other routers. A host could then (say) send an NS, and ask the responder to include that Link/Interface Identifier option. > > Note: on some links, like wireless ethernet, multicast is > > (relatively) "expensive". Would it be better to just send a few > > immediate unicast NS (or RS) messages to the routers we know about? > > and send a multicast RS only if the unicast fails? Or do both in > > parallel? > DNAv4 does both DHCP and DNA in parallel. DNAv4 is handled solely via > unicast ARP, because on some links multicast not only is sent to many more > hosts, but also is sent at much lower rate. For example, with IEEE > 802.11n, it would be possible to send *a hundred* unicast packets at 100 > Mbps at the same cost in expended slots as one multicast packet at 1 Mbps. > This means that in practice a single multicast RS will cost more than > sending unicast RS or NS messages to all previous routers. I'm also a bit worried that one time DNA will get used a lot is at, say, IETFs where the network is barely functioning. That seems like the wrong time to have a bunch of nodes invoke DNA at the same time and all send out multicast RSs... Thomas From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 09 09:42:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7D0Z-0005mF-Tt for dna-archive@megatron.ietf.org; Thu, 09 Feb 2006 09:42:58 -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 JAA26937 for ; Thu, 9 Feb 2006 09:41:04 -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 <01LYSAWCY81M9AVRV2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 10 Feb 2006 01:42:00 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 573F5AB543; Fri, 10 Feb 2006 01:41:58 +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 10CBE4FB17; Fri, 10 Feb 2006 01:41:58 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k19EfCB19564 for dna-list; Fri, 10 Feb 2006 01:41:12 +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 k19EfBu19560 for ; Fri, 10 Feb 2006 01:41:11 +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 <01LYSAV9MUQYAZT3G2@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 10 Feb 2006 01:41:05 +1100 Received: by localhost (Postfix, from userid 510) id 97E8480002; Fri, 10 Feb 2006 01:41:05 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 41B573C003 for ; Fri, 10 Feb 2006 01:41:04 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k19Ef2cP013612; Thu, 09 Feb 2006 09:41:02 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 8BA753C81FE; Wed, 08 Feb 2006 09:40:54 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id 71ECB3C81F7; Wed, 08 Feb 2006 09:40:54 -0500 (EST) Date: Thu, 09 Feb 2006 09:40:58 -0500 From: Greg Daley Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43EB547A.1080806@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:85.16255 C:21 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: > \> Are there other messages that can be sent that could help? Like NS >> queries unicast to known routers? > > This is what DNAv4 does (via unicast ARP), because this enables a > determination of whether the host has connected to a previously > encountered router, without ambiguity. > >> Note: on some links, like wireless ethernet, multicast is >> (relatively) "expensive". Would it be better to just send a few >> immediate unicast NS (or RS) messages to the routers we know about? >> and send a multicast RS only if the unicast fails? Or do both in >> parallel? > > DNAv4 does both DHCP and DNA in parallel. DNAv4 is handled solely via > unicast ARP, because on some links multicast not only is sent to many > more hosts, but also is sent at much lower rate. For example, with > IEEE 802.11n, it would be possible to send *a hundred* unicast packets > at 100 Mbps at the same cost in expended slots as one multicast packet > at 1 Mbps. This means that in practice a single multicast RS will cost > more than sending unicast RS or NS messages to all previous routers. Actually, if the switches monitor multicast groups, the packet will be sent toward the AP as unicast with the toDS bit set, and won't be retransmitted over the wireless LAN. The wireless transmission therefore can operate at a higher rate available to 802.11n. Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 09 10:59:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7ECy-0007nQ-DO for dna-archive@megatron.ietf.org; Thu, 09 Feb 2006 10:59:48 -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 KAA04208 for ; Thu, 9 Feb 2006 10:57:56 -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 <01LYSDDWELZQAW3HBN@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 10 Feb 2006 02:53:35 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B3780AB58D; Fri, 10 Feb 2006 02:53:22 +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 5E1134FB26; Fri, 10 Feb 2006 02:53:22 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k19Fqhd20318 for dna-list; Fri, 10 Feb 2006 02:52:43 +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 k19Fqhu20314 for ; Fri, 10 Feb 2006 02:52:43 +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 <01LYSDCQL1Z0AZT3NR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 10 Feb 2006 02:52:26 +1100 Received: by localhost (Postfix, from userid 510) id AC0ACAB58C; Fri, 10 Feb 2006 02:52:26 +1100 (EST) Received: from hotmail.com (bay106-f4.bay106.hotmail.com [65.54.161.14]) by moe.its.monash.edu.au (Postfix) with ESMTP id EACFF4FB11 for ; Fri, 10 Feb 2006 02:52:25 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 09 Feb 2006 07:52:24 -0800 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 09 Feb 2006 15:52:24 +0000 (GMT) Date: Thu, 09 Feb 2006 07:52:24 -0800 From: Bernard Aboba Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: <200602091331.k19DV0fH027627@cichlid.raleigh.ibm.com> X-Originating-IP: [67.182.139.247] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: narten@us.ibm.com Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 09 Feb 2006 15:52:24.0557 (UTC) FILETIME=[D1D4E9D0:01C62D90] Content-Transfer-Encoding: 7BIT >DNAv4 uses ARP. Shouldn't we think about using an NS? Personally, I think it makes sense. In fact, I believe that DNAv4 implementers are already considering this, if they haven't implemented it already. >One issue that seems to be carrying a lot of weight on the DNAv6 side >is that with RS/RAs, one (only) learns the router's link-local and >link-layer addresses. But these two together are insufficient to >uniquely identify a link, since both can be used on different links at >the same time. Right. DNAv4 does not use link-local addresses, so this problem does not arise. >Why not allow inclusion of a landmark option in an NS/NA? One benefit >of an NS is that we presumably don't have to delay sending one, and >the responder doesn't delay in responding. So this can be very fast. Right. Not only can the packets be sent without delay, but sending them via unicast also reduces delays due to frame loss on links such as 802.11 which do not retransmit multicast packets (from STA to AP) at the link layer. >However, this has the disadvantage that routers have to listen to >other RAs and (effectively) do a proxy advertisement for prefixes it >itself is not advertising. I have some fairly strong qualms about that >approach... Yes, I also have reservations about it. >On the other hand, a lower overhead mechanism would be to be able to >ask "are you the same router on link Foo that I was talking to >previously?" If the answer is yes, one can conclude that one is on the >same link as earlier. Yup. >I'm also a bit worried that one time DNA will get used a lot is at, >say, IETFs where the network is barely functioning. That seems like >the wrong time to have a bunch of nodes invoke DNA at the same time >and all send out multicast RSs... Yes. As part of the DNAv4 work, we did an analysis and discovered that sending multicast packets was *much* more likely to result in a network meltdown than using unicast. This was not only because of the multicasting, but also because of the link layer interactions, such as much lower rates, lack of link layer retransmission, etc. In fact, the effects are so strong that sending multiple unicast frames in parallel is more efficient than a single multicast. From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 09 10:59:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7ED3-0007o4-SE for dna-archive@megatron.ietf.org; Thu, 09 Feb 2006 10:59:53 -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 KAA04210 for ; Thu, 9 Feb 2006 10:57:58 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYSDDQ466IAZT3NR@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 10 Feb 2006 02:53:35 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 46E5580003; Fri, 10 Feb 2006 02:53:14 +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 E51C73C004; Fri, 10 Feb 2006 02:53:13 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k19FqII20310 for dna-list; Fri, 10 Feb 2006 02:52:18 +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 k19FqHu20306 for ; Fri, 10 Feb 2006 02:52:17 +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 <01LYSDCE6OH8AW3EJB@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 10 Feb 2006 02:52:10 +1100 Received: by localhost (Postfix, from userid 510) id 0887180002; Fri, 10 Feb 2006 02:52:09 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 9555D3C007 for ; Fri, 10 Feb 2006 02:52:07 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k19Fpu4X027436; Thu, 09 Feb 2006 10:51:56 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 670DF3C8207; Wed, 08 Feb 2006 10:51:48 -0500 (EST) Received: from [150.169.1.100] (unknown [150.169.1.100]) by redwood.research.panasonic.com (Postfix) with ESMTP id 21DF73C8206; Wed, 08 Feb 2006 10:51:48 -0500 (EST) Date: Thu, 09 Feb 2006 10:51:52 -0500 From: Greg Daley Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: <200602082131.k18LVYZM012621@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <43EB6518.2070300@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:8 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <200602082131.k18LVYZM012621@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Hi Thomas, I like your description. I'll go down to the questions section and see if there's something I can add. Thomas Narten wrote: > Here's a much longer attempt at describing the DNA landscape at a > high-level. My goals in writing this down include to be sure I > understand the current thinking in the WG, and to have it in text form > so that others can (hopefully) come up to speed more quickly. It may > also be useful to have some or all of this text appear in the > documents being worked on, to make them easier to understand. Finally, > I hope this allows us to break the problem space down better in a way > that allows us to talk about components individually and more > constructively. > > At the end, I have a number of questions. > > > 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 comes up for the first time, a host relies on RAs to provide the > needed configuration information. At the time 2461/2462 were written, > little thought was given to the details of how to process a "link > down" event (when one is available), or how to handle a "link up" > event for an interface that was previously up, perhaps only a few > seconds ago. With the increased proliferation of wireless networks, it > is now common to receive "link up" indications that may (or may not) > indicate that a configuration change has occurred at the IP layer > (i.e., one has moved from one link to another). DNA is the process of > (quickly) determining whether one is attached to a previously visited > link, in order to minimize service disruptions upon attaching to a > link. > > DNA requires that a host keep track of the links to which it has > recently attached. For each known link, information about that link, > such as default router addresses, prefix information, MTU, Lifetimes, > etc. are kept in what are called Link Instances (aka Candidate Link > Objects in dna-cpl). Link Instances are identified by the set of > on-link global prefixes that have been advertised on that link, as no > prefix may be assigned to different links simultaneously. At any given > time, one LI is considered the Current LI, and the parameters > associated with the CLI are what are actually configured on the link > as defined in 2461/2462. > > When a "link up" event is detected, a host will need to determine what > IP configuration parameters should be used. A simple (but naive) > approach would be to discard all associated information and initiate > the normal startup procedure as described in 2461/2462. However, this > has the downside of causing upper-layer protocols using the (just > discarded) addresses to possibly receive "hard errors" and terminate > connections using those addresses. In the common case where a link > goes away momentarily and then comes back up connected to the same > link (with the same associated config information) this is obviously > undesirable. > > DNA takes the approach that upon reciept of a "link up" event, the > most-recently used configuration information should continue to be > used, and that DNA should be initiated to (quickly) determine whether > one is attached to a new link, or one to which one has been previously > attached. In the simple case, DNA will quickly determine whether one > has reattached to the current link or to another known link. > Specifically, it will do so by sending a single RS and receiving a > single RA, one containing a prefix that it has seen before, thereby > identifying the link. In such cases, DNA can declare its work done, > and any new prefixes in the received RA are added to the CLI. > > In some scenarios, however, things are more complex. Specifically, DNA > may receive an RA that contains only prefixes it has never seen > before. When this happens, it may not be sure whether the prefixes > correspond to a new link (i.e., one not visited before), or a > previously-visited link, but for which it has not yet seen all the > advertised prefixes. While it might be simplest to assume that receipt > of such an RA indicated attachment to a new link, that can lead to > (incorrectly) invalidating other configuration information for that > link. To handle this case, DNA takes extra steps. First, it > distinguishes between "complete" and "incomplete" LIs. Complete LIs > are those for which there is a high probability of having recieved all > prefixes being advertised on that link. Incomplete LIs are those for > which insufficient time has elapsed to conclude with reasonable > certainty that it is likely that all advertised prefixes have been > seen. > > When DNA receives an RA advertising (only) unknown prefixes, and the > CLI is not "complete", DNA waits for additional RAs before deciding > whether the link is new or not. > > The DNA procedure is tightly coupled with the use of 2461/2462, since > DNA uses the same messages. > > There are two variants of DNA. In the first variant, hosts interact > with routers that have implemented 2461/2462, but have not implemented > any DNA extensions. One of the key limitations in this case is that > RAs are not required to include all prefixes, so reciept of an RA from > a router is not sufficient to learn all the prefixes that (or other) > routers might be advertising. The DNA approach for handling this case > has been described above. In the second variant, both hosts and > routers can be upgraded with DNA extensions. The proposed DNA > extensions in this case include: > > a) routers are permitted to respond more quickly to received RSs, by > having all routers on the link keep track of each other, and then > stagger their responses so that if there are N routers present, one > router responds during interval Time/N, the next during 2*Time/N, > etc. [pentland-protocol3] > > b) allow hosts to include a prefix in the RS that the router echos > back in the RA, if the prefix is still valid on the link. That way > the host can learn immediately if it is reconnecting to a > previously visited link. [landmark option in pentland-protocol3] > > c) have RAs include a "complete" bit, that routers set to indicate > that the RA includes all the known RAs it is configured to > advertise (plus the Learned Prefix Option described in d). This > allows a host to quickly learn if any prefixes are being omitted > from a particular RA. > > d) Definition of a Learned Prefix option that routers use to proxy > prefixes that they do not themselves advertise, but that they have > observed other routers advertising. Hosts do not use those prefixes > to autoconfigure addresses; they do use them to learn (in a single > RA) all prefixes believed to be in use on that link. With this > information, the host can definitively determine whether it is > connecting to a new link or revisiting an old one. > > > Some key questions for DNA. > > 1) when reusing "old" config, do we need to do anything special? E.g., > change state of ND entries to STALE? Put addresses in Optimistic > state? Take into account how much time has elapsed since we were > last attached (or just assume this happens as part of normal ND > timers?) I don't think you should change the ND cache state unless the 2461 timers indicate you should (Except if you're no longer on a link). It's an exposure of about 30 seconds (+DELAY+PROBE). With regard to addresses, even if you return to the same link, any period of absence is one where you may have missed a DAD NS (albeit with low probability). If you arrive back within a second, you would probably see the NA O=1 to all nodes from the node which started DAD while you were away. Placing the addresses in Optimistic state makes sense here, but it may not be necessary to send an NS (opinions welcome). If you've been away for an entire second, the host may arrive back after DAD has completed on a peer node. A full optimistic DAD would be required. > What harm can occur from continuing to use the same information? > how does this compare with the harm of delaying the configuration > of an interface until one is more certain? RT Voice transfer is out of the picture if you cannot configure the interface quickly (few 10s of ms). If the time to configure the addresses is greater than approx 1/2 RTT, TCP timeout is likely to occur. Depending on how using the same information occurs, return in under a second is unlikely to damage anyone who isn't doing optimistic DAD themselves (There are warnings in opti-dad about potential for failure). If the host doesn't watch for NAs, then it may be unaware of the competing nodes . > 2) Upon "link up", does DNA need to delay sending an RS per the > 2461/2462 rule? Are there ways to relax this that are consistent > with the original concerns that led to the existing wording in > 2461/2462? There's new text in RFC2461bis, saying that if the link-layer indicates you may have moved, it is possible to send an RS immediately, if the link-layer is likely to serialize devices coming onto the medium. draft-ietf-dna-hosts provides guidance on what to do with hints, especially from link-layer and indicates when it is not possible to immediately solicit (S 5.5). > 3) Upon "link up", what messages can host send that would help it to > quickly determine if on same link? Is it just an RS? what about > unicast? what about an NS (e.g., perhaps including a Landmark > option)? > > Are there other messages that can be sent that could help? Like NS > queries unicast to known routers? > > Note: on some links, like wireless ethernet, multicast is > (relatively) "expensive". Would it be better to just send a few > immediate unicast NS (or RS) messages to the routers we know about? > and send a multicast RS only if the unicast fails? Or do both in > parallel? Please note that the main problem in DNA is when the host has moved. When the host has not moved, we don't really need to do much. Therefore the additional packet to check "are we here?" to a known destination doesn't help us achieve rapid change detection in the important case. When a host has moved, it is not possible to identify a unicast destination for a querying packet a-priori. This is why we've used multicast. Perhaps there is a way for all links to have the same (MAC) unicast destination for a serving router, which would avoid the issue of the multicast RS leaking back onto a wireless LAN. There are other ways of dealing with this issue today though (e.g. group filtering). Ideas like special destinations have been discussed previously off-list, but have the issue that they require modification to routers. RS/RA has the advantage that it is always there, and if people wish to improve its performance in scheduling or efficiency, it is possible to upgrade it (or potentially the network it is on??). > 4) When one gets an RA containing prefixes that one has not seen > before, is the algorithm in CPA sufficient or ideal? Are there > other probes one could send? E.g., upon indication that a new prefix > is available, send additional probes quickly to try and flush out > things more quickly? Or, should the host keep additional info in > LIs, e.g., keeping track of which router advertised what prefixes, > so that it can distingish "prefix from previously unknown router" > vs. "new prefix from router we've received RAs from before"? I think the distinction you make about added prefixes is interesting, but without a PIO (perhaps with the Router Address (R) flag set) in common it's really too difficult to identify if this is really the same router because the addressing is link-local -- I mean you can guess, but it may be a different link. As the router address flag isn't in wide use, this isn't so easy, unless there was a common prefix between the RAs -- in which case CPL works anyway. > 5) When DNA determines that one is no longer connected to the same > link as before, one swaps configs. Care must be taken to apply > information learned from RAs received since last "link up" get > applied to correct LI. Yes. This is relatively easily done (in the implementation) by moving aside the LI when the link-indication is received, and testing received packets until either: the expiry of the New LI build (if the existing LI was not complete). amalgamation of the LIs, due to a common prefix or replacement due to disjoint prefixes (if the existing LI was complete) > 6) if DNA determines that was has reconnected to the same link, what > else needs to be done? Rerun DAD? Do nothing? Does the answer > depend on how long it has been since one was previously connected > to that link? As we discussed above, my guess is that immediate (<1s?) return has some potential danger (low probability) due to duplicate addresses. I don't think additional packets are warranted though. Longer disconnections should have a complete DAD, whether original or optimistic. Group joins and ND cache state should be governed by existing timers, AFAICS. > 7) Is there ever a time when one should discard still-valid prefix > information on a link? That is, suppose a bogus router shows up and > sends out an RA with prefix information with a long Lifetime. This > information may stay associated with a link for weeks, because no > router ever advertises the prefix with a Lifetime of 0. Pre-DNA, > that info would presumably get discarded more quickly because one > doesn't keep old LI information around. But with DNA, we may find > this happens and causes problems. For robustness, it seems like it > might be desirable to discard prefix information in the _absence_ > of RAs containing that prefix, in the case where other RAs continue > to be received with other prefix information. I.e., if one knows > that one has missed (say) N RAs, time out the info if one is > receiving other info from other routers. (note: the situation is > further aggrevated by having routers cache RAs learned from other > routers.) Well, I don't think it's really that useful to keep cached information for a long time after you have departed a link. In draft-ietf-dna-hosts Section 4.1, a maximum cache time is described which tackles out of date information such as this, and may be used to limit the effective lifetime of stored information. This doesn't actually reduce the valid lifetime of the prefix, though, but may age out the router state quickly. Perhaps we should have a look at this further if you think it's moving in the right direction. In that case it may be necessary to attempt to tie the RA to the PIO as in (Q3), although this would be to compare within the same link and not between links for the purpose of link-determination. I hope this helps. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 09:51:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8f3C-0007N6-4k for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 09:51:40 -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 JAA26515 for ; Mon, 13 Feb 2006 09:49:51 -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 <01LYXWDNPKR89C98YC@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 01:50:49 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EC61AAB58D; Tue, 14 Feb 2006 01:50:46 +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 9BB084FB57; Tue, 14 Feb 2006 01:50:46 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DEkum17195 for dna-list; Tue, 14 Feb 2006 01:46:56 +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 k1DEktu17191 for ; Tue, 14 Feb 2006 01:46:55 +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 <01LYXW8OG5F69C98K2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 01:46:46 +1100 Received: by localhost (Postfix, from userid 510) id 46175AB58D; Tue, 14 Feb 2006 01:46:46 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.193]) by moe.its.monash.edu.au (Postfix) with ESMTP id D4A4D4FB26 for ; Tue, 14 Feb 2006 01:46:43 +1100 (EST) Received: by uproxy.gmail.com with SMTP id m3so648887uge for ; Mon, 13 Feb 2006 06:46:40 -0800 (PST) Received: by 10.66.186.4 with SMTP id j4mr1155668ugf; Mon, 13 Feb 2006 06:46:40 -0800 (PST) Received: by 10.67.24.3 with HTTP; Mon, 13 Feb 2006 06:46:40 -0800 (PST) Date: Mon, 13 Feb 2006 23:46:40 +0900 From: JinHyeock Choi Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: <200602082131.k18LVYZM012621@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <92e919fb0602130646v4f7ac3c2jee852ed2a06c3f78@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FpSphSCKugiWqW8DVKLa71RmMDGZI4qHdvNU5O/i+A5xVj3TdrhijuCxNFshC5co3X0pcBsuLfa1I7KSh63J2JUMnbPenVpzorbSAgZy3zlYcPmxYjhnntV7BGVcuZa8Jr6X7XJMHH8jSBSpwPdZGcsyY/HEVCoETOtVNMTwCBM= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200602082131.k18LVYZM012621@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Dear Thomas Thanks for a clear and neat summary. Except a few minor points, I am of the same opinion. Also I think that we'd better write down a bird's eye view on DNA in some place. > DNA takes the approach that upon reciept of a "link up" event, the > most-recently used configuration information should continue to be > used, and that DNA should be initiated to (quickly) determine whether > one is attached to a new link, or one to which one has been previously > attached. I'd like to make a clarification. IMO, upon "link up" event, though a host can keep the existing configuration information, it should not use the information until DNA procedure confirms that the host remains at the same link. For example, a host can retain its current IP address but should not send a packet with the address as a source address till DNA comletes. We'd better make this clear and explcitly write it down. > Some key questions for DNA. > > 1) when reusing "old" config, do we need to do anything special? E.g., > change state of ND entries to STALE? Put addresses in Optimistic > state? Take into account how much time has elapsed since we were > last attached (or just assume this happens as part of normal ND > timers?) > > What harm can occur from continuing to use the same information? > how does this compare with the harm of delaying the configuration > of an interface until one is more certain? It may cause address conflict if a host continues to use the existing 'IP address' without DAD. While the host is away from the link, it's possible that another node happens to configure the host's IP address, because there was nobody to defend the address. Also during the absence, a router/prefix may be removed from the link with the RA/PIO with explicit indicaiton. Since the host didn't receive the explict indication such as PIO with lifetime=0, it may falsely assume that router/ prefix is still there. > 2) Upon "link up", does DNA need to delay sending an RS per the > 2461/2462 rule? Are there ways to relax this that are consistent > with the original concerns that led to the existing wording in > 2461/2462? I think 2461bis allows an immideate RS for mobile nodes. > 3) Upon "link up", what messages can host send that would help it to > quickly determine if on same link? Is it just an RS? what about > unicast? what about an NS (e.g., perhaps including a Landmark > option)? > > Are there other messages that can be sent that could help? Like NS > queries unicast to known routers? > > Note: on some links, like wireless ethernet, multicast is > (relatively) "expensive". Would it be better to just send a few > immediate unicast NS (or RS) messages to the routers we know about? > and send a multicast RS only if the unicast fails? Or do both in > parallel? With RS/ RA, I think DNA performs better in case of actual link change. In case a host moves to a new link, it needs an RA for new configuration anyway, so it seems reasonable to send RS in anticipation of a link change. Also if you use unicast meessage to known destinations, no reply will come when you have moved to a new link. This will result in delay since you can't but rely on timeout to detect a link change. For your concern about multicast, I am happy to say that you may use FRD (draft-ietf-dna-frd-01) to remove multicast packets entirely from the air. :-) In brief, AP keeps a suitable RA and forward it to the host upon a new attachment. > 6) if DNA determines that was has reconnected to the same link, what > else needs to be done? Rerun DAD? Do nothing? Does the answer > depend on how long it has been since one was previously connected > to that link? Right now, DAD seems to be the main problem but we may need to think this more. > 7) Is there ever a time when one should discard still-valid prefix > information on a link? That is, suppose a bogus router shows up and > sends out an RA with prefix information with a long Lifetime. This > information may stay associated with a link for weeks, because no > router ever advertises the prefix with a Lifetime of 0. Pre-DNA, > that info would presumably get discarded more quickly because one > doesn't keep old LI information around. But with DNA, we may find > this happens and causes problems. For robustness, it seems like it > might be desirable to discard prefix information in the _absence_ > of RAs containing that prefix, in the case where other RAs continue > to be received with other prefix information. I.e., if one knows > that one has missed (say) N RAs, time out the info if one is > receiving other info from other routers. (note: the situation is > further aggrevated by having routers cache RAs learned from other > routers.) This also needs more thoughts. Within Design Team, there were some arguments over the dormant node awakening case. If a prefix is removed while a node is dormant, upon awakening, the node mistakenly assume the prefix is valid until it's lifetime, which may be quite long, expires. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 09:59:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fBA-0000hF-5H for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 09:59:52 -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 JAA27460 for ; Mon, 13 Feb 2006 09:58:06 -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 <01LYXWMZTHPC9C96LW@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 01:58:20 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9D03BAB60E; Tue, 14 Feb 2006 01:58:18 +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 320BC4FBAC; Tue, 14 Feb 2006 01:58:18 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DEwBE17339 for dna-list; Tue, 14 Feb 2006 01:58:11 +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 k1DEwAu17335 for ; Tue, 14 Feb 2006 01:58:10 +1100 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 <01LYXWMIK92Q9AW3IW@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 01:57:55 +1100 Received: by localhost (Postfix, from userid 510) id 86C2680002; Tue, 14 Feb 2006 01:57:55 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.193]) by larry.its.monash.edu.au (Postfix) with ESMTP id AAA9C3C007 for ; Tue, 14 Feb 2006 01:57:53 +1100 (EST) Received: by uproxy.gmail.com with SMTP id c2so33964ugf for ; Mon, 13 Feb 2006 06:57:50 -0800 (PST) Received: by 10.66.243.20 with SMTP id q20mr1160534ugh; Mon, 13 Feb 2006 06:57:50 -0800 (PST) Received: by 10.67.24.3 with HTTP; Mon, 13 Feb 2006 06:57:49 -0800 (PST) Date: Mon, 13 Feb 2006 23:57:49 +0900 From: JinHyeock Choi Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: <43EB6518.2070300@research.panasonic.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Thomas Narten , dna@eng.monash.edu.au Message-id: <92e919fb0602130657m3b9bc03bnd830891d973347dd@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F5gQgXq6CmyR9MzZjEzuRAaRKsxP2gQocbd+I3hZelixccc8ZsMI9Q3taRTOcWWbk02Oc0Wiue1fnyw0EGoZjoucmZS81rvtNgHptpipRMo2L4mLJ9ZqMUujEP7hMm6IMzYAOo2iJEZXK1FTnyLoTcRTkDQYd8N1RryXlO/fFDQ= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200602082131.k18LVYZM012621@cichlid.raleigh.ibm.com> <43EB6518.2070300@research.panasonic.com> Content-Transfer-Encoding: 7BIT Dear Greg > I don't think you should change the ND cache state unless the 2461 > timers indicate you should (Except if you're no longer on a link). > It's an exposure of about 30 seconds (+DELAY+PROBE). > > With regard to addresses, even if you return to the same link, any > period of absence is one where you may have missed a DAD NS > (albeit with low probability). > > If you arrive back within a second, you would probably see the > NA O=1 to all nodes from the node which started DAD while you were > away. Placing the addresses in Optimistic state makes sense here, > but it may not be necessary to send an NS (opinions welcome). > > If you've been away for an entire second, the host may arrive back > after DAD has completed on a peer node. A full optimistic DAD would > be required. It make sense to differentiate host's behavior according to the time of absence. The longer a host is absent, the more care it should take. BTW how a host can measure its time of detachment? Shall this require a precise link-down event notification? > > 3) Upon "link up", what messages can host send that would help it to > > quickly determine if on same link? Is it just an RS? what about > > unicast? what about an NS (e.g., perhaps including a Landmark > > option)? > > > > Are there other messages that can be sent that could help? Like NS > > queries unicast to known routers? > > > > Note: on some links, like wireless ethernet, multicast is > > (relatively) "expensive". Would it be better to just send a few > > immediate unicast NS (or RS) messages to the routers we know about? > > and send a multicast RS only if the unicast fails? Or do both in > > parallel? > > Please note that the main problem in DNA is when the host has moved. > When the host has not moved, we don't really need to do much. > > Therefore the additional packet to check "are we here?" to a known > destination doesn't help us achieve rapid change detection in the > important case. > > When a host has moved, it is not possible to identify a unicast > destination for a querying packet a-priori. agree. > This is why we've used multicast. Perhaps there is a way for all > links to have the same (MAC) unicast destination for a serving router, > which would avoid the issue of the multicast RS leaking back onto a > wireless LAN. There are other ways of dealing with this issue > today though (e.g. group filtering). > > Ideas like special destinations have been discussed previously off-list, > but have the issue that they require modification to routers. > > RS/RA has the advantage that it is always there, and if people > wish to improve its performance in scheduling or efficiency, > it is possible to upgrade it (or potentially the network it is on??). Kindly be aware that we can avoid multicast in the air with FRD. :-) Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 10:07:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fId-0004lZ-62 for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:07:35 -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 KAA28313 for ; Mon, 13 Feb 2006 10:05:49 -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 <01LYXWWMAL4U9C8XSY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 02:06:06 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 370AFAB544; Tue, 14 Feb 2006 02:06:04 +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 DF4E24FB02; Tue, 14 Feb 2006 02:06:03 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DF5tX17425 for dna-list; Tue, 14 Feb 2006 02:05:55 +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 k1DF5tu17421 for ; Tue, 14 Feb 2006 02:05:55 +1100 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 <01LYXWW4NTKU9C8XSY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 02:05:40 +1100 Received: by localhost (Postfix, from userid 510) id 9E50980002; Tue, 14 Feb 2006 02:05:40 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 473F63C014 for ; Tue, 14 Feb 2006 02:05:39 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k1DF5bt2011237; Mon, 13 Feb 2006 10:05:37 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id CB2283C8163; Mon, 13 Feb 2006 10:05:09 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id 762B93C8161; Mon, 13 Feb 2006 10:05:09 -0500 (EST) Date: Mon, 13 Feb 2006 10:05:35 -0500 From: Greg Daley Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: <92e919fb0602130657m3b9bc03bnd830891d973347dd@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Thomas Narten , dna@eng.monash.edu.au Message-id: <43F0A03F.1020208@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:14 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <200602082131.k18LVYZM012621@cichlid.raleigh.ibm.com> <43EB6518.2070300@research.panasonic.com> <92e919fb0602130657m3b9bc03bnd830891d973347dd@mail.gmail.com> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: [cut] >> >> If you arrive back within a second, you would probably see the >> NA O=1 to all nodes from the node which started DAD while you were >> away. Placing the addresses in Optimistic state makes sense here, >> but it may not be necessary to send an NS (opinions welcome). >> >> If you've been away for an entire second, the host may arrive back >> after DAD has completed on a peer node. A full optimistic DAD would >> be required. > > It make sense to differentiate host's behavior according to the time > of absence. The longer a host is absent, the more care it should take. > BTW how a host can measure its time of detachment? Shall this require > a precise link-down event notification? I'd guess that link-down indications could be used to allow for more selective behaviour, if there's knowledge of detachment time. [cut] >> This is why we've used multicast. Perhaps there is a way for all >> links to have the same (MAC) unicast destination for a serving router, >> which would avoid the issue of the multicast RS leaking back onto a >> wireless LAN. There are other ways of dealing with this issue >> today though (e.g. group filtering). >> >> Ideas like special destinations have been discussed previously off-list, >> but have the issue that they require modification to routers. >> >> RS/RA has the advantage that it is always there, and if people >> wish to improve its performance in scheduling or efficiency, >> it is possible to upgrade it (or potentially the network it is on??). > > Kindly be aware that we can avoid multicast in the air with FRD. :-) Indeed. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 10:08:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fJQ-0005EN-UO for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:08:25 -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 KAA28458 for ; Mon, 13 Feb 2006 10:06:39 -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 <01LYXWXU0QMM9AVTNI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 02:07:05 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ED960AB608; Tue, 14 Feb 2006 02:07:02 +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 9B4714FB49; Tue, 14 Feb 2006 02:07:02 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DF6wU17456 for dna-list; Tue, 14 Feb 2006 02:06:58 +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 k1DF6wu17452 for ; Tue, 14 Feb 2006 02:06:58 +1100 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 <01LYXWXKJUD29C8XSY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 02:06:50 +1100 Received: by localhost (Postfix, from userid 510) id 5B8C380002; Tue, 14 Feb 2006 02:06:50 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.197]) by larry.its.monash.edu.au (Postfix) with ESMTP id C00DF3C00E for ; Tue, 14 Feb 2006 02:06:48 +1100 (EST) Received: by uproxy.gmail.com with SMTP id j3so749368ugf for ; Mon, 13 Feb 2006 07:06:45 -0800 (PST) Received: by 10.67.30.9 with SMTP id h9mr1179070ugj; Mon, 13 Feb 2006 07:06:45 -0800 (PST) Received: by 10.67.24.3 with HTTP; Mon, 13 Feb 2006 07:06:45 -0800 (PST) Date: Tue, 14 Feb 2006 00:06:45 +0900 From: JinHyeock Choi Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <92e919fb0602130706m51ba4e5dke15f9dee23c069ff@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oDXsB1SJoQwqBzfBwdMB1rAk+rcGLxgI1lIslqENaRtduvF1YedXA4lAd/BcjjC7iRV9Lda+ypRtoYrcQz/5+LnRq9uxkVN7DQ0zgiPq92jyunUfVFvVHOaJ5iKZTYR9z1hGSf4yUj/HudpqpHNC3qdQ/JQ4HaES5r/3Hq7BQRc= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200602091331.k19DV0fH027627@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Dear Bernard > >Why not allow inclusion of a landmark option in an NS/NA? One benefit > >of an NS is that we presumably don't have to delay sending one, and > >the responder doesn't delay in responding. So this can be very fast. > > Right. Not only can the packets be sent without delay, but sending them via > unicast also reduces delays due to frame loss on links such as 802.11 which > do not retransmit multicast packets (from STA to AP) at the link layer. In case a host remains at the same link, the response can be fast without trouble. However, in case a host moves to a new link, nobody will respond and I can see no way for the host to realize a link change except time expiry. That would take some time. Am I missing something? Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 10:11:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fME-0006Ar-1A for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:11: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 KAA28689 for ; Mon, 13 Feb 2006 10:09:32 -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 <01LYXX1IDNCQ9AVISK@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 02:10:04 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CC3F4AB544; Tue, 14 Feb 2006 02:10:00 +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 635794FB02; Tue, 14 Feb 2006 02:10:00 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DF9ux17513 for dna-list; Tue, 14 Feb 2006 02:09:56 +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 k1DF9tu17509 for ; Tue, 14 Feb 2006 02:09:55 +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 <01LYXX19178KAW419A@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 02:09:48 +1100 Received: by localhost (Postfix, from userid 510) id 58EDFAB58D; Tue, 14 Feb 2006 02:09:48 +1100 (EST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) (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 9123F4FB0D for ; Tue, 14 Feb 2006 02:09:46 +1100 (EST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1DF9guN012464 for ; Mon, 13 Feb 2006 10:09:42 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1DFCC4D119036 for ; Mon, 13 Feb 2006 08:12:12 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k1DF9fpj020447 for ; Mon, 13 Feb 2006 08:09:41 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-220-250.mts.ibm.com [9.65.220.250]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k1DF9eLE020400; Mon, 13 Feb 2006 08:09:40 -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 k1DF9c6h006070; Mon, 13 Feb 2006 10:09:39 -0500 Date: Mon, 13 Feb 2006 10:09:38 -0500 From: Thomas Narten Subject: [DNA] retaining current IP configuration as DNA kicks in In-reply-to: Message from JinHyeock Choi "of Mon, 13 Feb 2006 23:46:40 +0900." <92e919fb0602130646v4f7ac3c2jee852ed2a06c3f78@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <200602131509.k1DF9c6h006070@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 JinHyeock Choi writes: > > DNA takes the approach that upon reciept of a "link up" event, the > > most-recently used configuration information should continue to be > > used, and that DNA should be initiated to (quickly) determine whether > > one is attached to a new link, or one to which one has been previously > > attached. > I'd like to make a clarification. IMO, upon "link up" event, > though a host can keep the existing configuration information, > it should not use the information until DNA procedure confirms > that the host remains at the same link. > For example, a host can retain its current IP address but should not send > a packet with the address as a source address till DNA comletes. Why? I've thought about this some, and the question I ask is "what breaks if a host does send such packets?" If that answer is "nothing", then no harm done. It may be that sending such packets is useless, but that's not a problem. If it actually causes things to break or bad things to happen, then yes, we should think about disallowing such behavior. But lets evaluate the cost/benefit explicitly. Thomas From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 10:17:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fSL-0000xK-Jo for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:17:37 -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 KAA29372 for ; Mon, 13 Feb 2006 10:15:51 -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 <01LYXX9XWPKKAW41A3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 02:16:57 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A121FAB58D; Tue, 14 Feb 2006 02:16:48 +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 625F24FB5B; Tue, 14 Feb 2006 02:16:48 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DFGhN17659 for dna-list; Tue, 14 Feb 2006 02:16:43 +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 k1DFGhu17655 for ; Tue, 14 Feb 2006 02:16:43 +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 <01LYXX9HLFKUAZU185@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 02:16:27 +1100 Received: by localhost (Postfix, from userid 510) id D951DAB58C; Tue, 14 Feb 2006 02:16:26 +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 moe.its.monash.edu.au (Postfix) with ESMTP id DA9084FB5A for ; Tue, 14 Feb 2006 02:16:25 +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 k1DFGNJm016723 for ; Mon, 13 Feb 2006 10:16:23 -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 k1DFEB9i228698 for ; Mon, 13 Feb 2006 08:14:11 -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 k1DFGMV7022096 for ; Mon, 13 Feb 2006 08:16:23 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-220-250.mts.ibm.com [9.65.220.250]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k1DFGLt8021991; Mon, 13 Feb 2006 08:16:22 -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 k1DFGKK9006254; Mon, 13 Feb 2006 10:16:21 -0500 Date: Mon, 13 Feb 2006 10:16:20 -0500 From: Thomas Narten Subject: [DNA] how much effort to deal with "unplanned renumbering" In-reply-to: Message from JinHyeock Choi "of Mon, 13 Feb 2006 23:46:40 +0900." <92e919fb0602130646v4f7ac3c2jee852ed2a06c3f78@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <200602131516.k1DFGKK9006254@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 JinHyeock Choi writes: > > Some key questions for DNA. > > > > 1) when reusing "old" config, do we need to do anything special? E.g., > > change state of ND entries to STALE? Put addresses in Optimistic > > state? Take into account how much time has elapsed since we were > > last attached (or just assume this happens as part of normal ND > > timers?) > > > > What harm can occur from continuing to use the same information? > > how does this compare with the harm of delaying the configuration > > of an interface until one is more certain? > > It may cause address conflict if a host continues to use the existing > 'IP address' without DAD. While the host is away from the link, it's > possible that another node happens to configure the host's IP address, > because there was nobody to defend the address. > Also during the absence, a router/prefix may be removed from the link > with the RA/PIO with explicit indicaiton. Since the host didn't > receive the explict indication such as PIO with lifetime=0, it may > falsely assume that router/ prefix is still there. I think we need to think hard about how much we are going to complicate DNA to deal with "broken renumbering attempts", which are not supposed to happen in the first place. The IPv6 protocols do not really support taking away a prefix prematurely, and when this happens, things aren't guarnteed to work. Thus, this is not advisable in general. So we should explicitely discuss to what degree DNA needs to support such events, especially if they are not expected to be common. Thomas From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 10:19:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fUR-0001Uc-9f for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:19:47 -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 KAA29601 for ; Mon, 13 Feb 2006 10:18:01 -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 <01LYXX4X910O9AVISK@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 02:12:49 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DC5CF80003; Tue, 14 Feb 2006 02:12:45 +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 99DF43C00E; Tue, 14 Feb 2006 02:12:45 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DFCgs17591 for dna-list; Tue, 14 Feb 2006 02:12:42 +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 k1DFCfu17585 for ; Tue, 14 Feb 2006 02:12:41 +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 <01LYXX4IPDCOAZU17E@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 02:12:26 +1100 Received: by localhost (Postfix, from userid 510) id 788AAAB58D; Tue, 14 Feb 2006 02:12:26 +1100 (EST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) (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 4BE084FB05 for ; Tue, 14 Feb 2006 02:12:25 +1100 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1DFCNIW001142 for ; Mon, 13 Feb 2006 10:12:23 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1DFAB9i265908 for ; Mon, 13 Feb 2006 08:10:11 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k1DFCMpR030739 for ; Mon, 13 Feb 2006 08:12:22 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-220-250.mts.ibm.com [9.65.220.250]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k1DFCL3u030682; Mon, 13 Feb 2006 08:12:22 -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 k1DFCL8w006081; Mon, 13 Feb 2006 10:12:21 -0500 Date: Mon, 13 Feb 2006 10:12:21 -0500 From: Thomas Narten Subject: [DNA] when to rerun DAD In-reply-to: Message from JinHyeock Choi "of Mon, 13 Feb 2006 23:46:40 +0900." <92e919fb0602130646v4f7ac3c2jee852ed2a06c3f78@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <200602131512.k1DFCL8w006081@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 JinHyeock Choi writes: > > Some key questions for DNA. > > > > 1) when reusing "old" config, do we need to do anything special? E.g., > > change state of ND entries to STALE? Put addresses in Optimistic > > state? Take into account how much time has elapsed since we were > > last attached (or just assume this happens as part of normal ND > > timers?) > > > > What harm can occur from continuing to use the same information? > > how does this compare with the harm of delaying the configuration > > of an interface until one is more certain? > It may cause address conflict if a host continues to use the existing > 'IP address' without DAD. While the host is away from the link, it's > possible that another node happens to configure the host's IP address, > because there was nobody to defend the address. IMO, we may want to think about having a separate discussion about "when to run DAD". The blanket "rerun DAD at all times there is some doubt" strikes me as overkill. For example, why rerun DAD if one has been disconnected only 10 seconds? or 30? Maybe we should if we've been disconnected for an hour (but then, do we need to bother with DNA?). Also, why rerun DAD if one has generated an address using the IEEE Identifier (and one has run DAD on it before)? That is, different types of addresses have different "probability of possible collision" risks in terms of other hosts attempting to use such addresses. Thomas From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 10:22:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fWx-0002v6-Re for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:22:23 -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 KAA29823 for ; Mon, 13 Feb 2006 10:20:37 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYXXEGM0RIAW41B2@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 02:20:42 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 382A780003; Tue, 14 Feb 2006 02:20:27 +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 D90603C005; Tue, 14 Feb 2006 02:20:26 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DFKD517740 for dna-list; Tue, 14 Feb 2006 02:20:13 +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 k1DFKCu17736 for ; Tue, 14 Feb 2006 02:20:12 +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 <01LYXXE0VURCAZU185@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 02:20:06 +1100 Received: by localhost (Postfix, from userid 510) id 2E60EAB543; Tue, 14 Feb 2006 02:20:06 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 29A774FB2F for ; Tue, 14 Feb 2006 02:20:04 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k1DFK3jQ014878; Mon, 13 Feb 2006 10:20:03 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id D73D93C8165; Mon, 13 Feb 2006 10:19:35 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id BF79D3C8163; Mon, 13 Feb 2006 10:19:35 -0500 (EST) Date: Mon, 13 Feb 2006 10:20:01 -0500 From: Greg Daley Subject: Re: [DNA] retaining current IP configuration as DNA kicks in In-reply-to: <200602131509.k1DF9c6h006070@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <43F0A3A1.7020104@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:62.30242 C:16 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <200602131509.k1DF9c6h006070@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Hi Thomas, Thomas Narten wrote: [cut] >> I'd like to make a clarification. IMO, upon "link up" event, >> though a host can keep the existing configuration information, >> it should not use the information until DNA procedure confirms >> that the host remains at the same link. > >> For example, a host can retain its current IP address but should not send >> a packet with the address as a source address till DNA comletes. > > Why? > > I've thought about this some, and the question I ask is "what breaks > if a host does send such packets?" If that answer is "nothing", then > no harm done. > > It may be that sending such packets is useless, but that's not a > problem. If it actually causes things to break or bad things to > happen, then yes, we should think about disallowing such behavior. But > lets evaluate the cost/benefit explicitly. I agree. This was actually one of the first topics on the mailing list a _long_ time ago. There's no need to specify that packets can't be sent until DNA completes, as globally addressed packets (except ND) can't interfere with packet streams when sent from another link. There may be problems for TCP if these packets are wasted, but I don't think that's necessarily DNA's direct responsibility at this stage (we don't even have the base protocol standardized). Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 10:23:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fY8-0003OV-Lm for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:23:36 -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 KAA29936 for ; Mon, 13 Feb 2006 10:21:50 -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 <01LYXXG2EASIAZU19Q@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 02:21:52 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DC262AB544; Tue, 14 Feb 2006 02:21:44 +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 926554FB2B; Tue, 14 Feb 2006 02:21:44 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DFLeF17776 for dna-list; Tue, 14 Feb 2006 02:21:40 +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 k1DFLdu17771 for ; Tue, 14 Feb 2006 02:21:39 +1100 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 <01LYXXFULYOW9C81FS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 02:21:34 +1100 Received: by localhost (Postfix, from userid 510) id 9819B80002; Tue, 14 Feb 2006 02:21:34 +1100 (EST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) (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 8B2253C009 for ; Tue, 14 Feb 2006 02:21:33 +1100 (EST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1DFLVeh027959 for ; Mon, 13 Feb 2006 10:21:31 -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 k1DFO24D141870 for ; Mon, 13 Feb 2006 08:24:02 -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 k1DFKVFj021659 for ; Mon, 13 Feb 2006 08:20:31 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-220-250.mts.ibm.com [9.65.220.250]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k1DFKUCC021584; Mon, 13 Feb 2006 08:20:30 -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 k1DFKTKi006272; Mon, 13 Feb 2006 10:20:29 -0500 Date: Mon, 13 Feb 2006 10:20:29 -0500 From: Thomas Narten Subject: [DNA] Alternatives to "just send RS" when DNA starts In-reply-to: Message from JinHyeock Choi "of Mon, 13 Feb 2006 23:46:40 +0900." <92e919fb0602130646v4f7ac3c2jee852ed2a06c3f78@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <200602131520.k1DFKTKi006272@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 JinHyeock Choi writes: > > 2) Upon "link up", does DNA need to delay sending an RS per the > > 2461/2462 rule? Are there ways to relax this that are consistent > > with the original concerns that led to the existing wording in > > 2461/2462? > I think 2461bis allows an immideate RS for mobile nodes. Can you cite text? And I hope they don't make an exception just for "mobile nodes". > > 3) Upon "link up", what messages can host send that would help it to > > quickly determine if on same link? Is it just an RS? what about > > unicast? what about an NS (e.g., perhaps including a Landmark > > option)? > > > > Are there other messages that can be sent that could help? Like NS > > queries unicast to known routers? > > > > Note: on some links, like wireless ethernet, multicast is > > (relatively) "expensive". Would it be better to just send a few > > immediate unicast NS (or RS) messages to the routers we know about? > > and send a multicast RS only if the unicast fails? Or do both in > > parallel? > With RS/ RA, I think DNA performs better in case of actual link change. > In case a host moves to a new link, it needs an RA for new > configuration anyway, so it seems reasonable to send RS in > anticipation of a link change. Also if you use unicast meessage to > known destinations, no reply will come when you have moved to a new > link. This will result in delay since you can't but rely on timeout to > detect a link change. But one can also imagine parallel approaches. E.g, for the default routers on the list, measure the actual observed RTTs during NS/NA exchanges. Then, for DNA, send out an NS, using that RTT as an estimate of how long you are willing to wait (and I'd expect this to be very short, like 10ms or less). If that doesn't work, then fall back to RS. One can imagine other optimizations. > For your concern about multicast, I am happy to say that you may use > FRD (draft-ietf-dna-frd-01) to remove multicast packets entirely from > the air. :-) In brief, AP keeps a suitable RA and forward it to the > host upon a new attachment. This is the IETF; we work at the IP layer. We don't know about link-layer specific things like "access points". (I'm actually fairly serious here.) Thomas From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 10:32:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fgH-0005ur-3u for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:32:01 -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 KAA00791 for ; Mon, 13 Feb 2006 10:30:15 -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 <01LYXXR58EWEAW41B6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 02:30:48 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B687FAB604; Tue, 14 Feb 2006 02:30:40 +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 7AC314FB05; Tue, 14 Feb 2006 02:30:40 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DFUYa17935 for dna-list; Tue, 14 Feb 2006 02:30:34 +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 k1DFUXu17930 for ; Tue, 14 Feb 2006 02:30:33 +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 <01LYXXQS4COE9ASOBD@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 02:30:23 +1100 Received: by localhost (Postfix, from userid 510) id 53E83AB58C; Tue, 14 Feb 2006 02:30:23 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id 71D254FB1B for ; Tue, 14 Feb 2006 02:30:22 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k1DFULhY017644; Mon, 13 Feb 2006 10:30:21 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 3FF7E3C8163; Mon, 13 Feb 2006 10:29:53 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id 2B9173C8161; Mon, 13 Feb 2006 10:29:53 -0500 (EST) Date: Mon, 13 Feb 2006 10:30:18 -0500 From: Greg Daley Subject: Re: [DNA] how much effort to deal with "unplanned renumbering" In-reply-to: <200602131516.k1DFGKK9006254@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <43F0A60A.2020700@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:52.36808 C:19 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <200602131516.k1DFGKK9006254@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Hi Thomas, Thomas Narten wrote: [cut] > >> Also during the absence, a router/prefix may be removed from the link >> with the RA/PIO with explicit indicaiton. Since the host didn't >> receive the explict indication such as PIO with lifetime=0, it may >> falsely assume that router/ prefix is still there. > > I think we need to think hard about how much we are going to > complicate DNA to deal with "broken renumbering attempts", which are > not supposed to happen in the first place. The IPv6 protocols do not > really support taking away a prefix prematurely, and when this > happens, things aren't guarnteed to work. Thus, this is not advisable > in general. > > So we should explicitely discuss to what degree DNA needs to support > such events, especially if they are not expected to be common. > > Thomas > This is an issue which is addressed in the draft-pentland-dna-protocol3 document (accepted as WG draft), and was resolved by the DT. The DNA protocol describes how existing ND timers are used, and also places a time limit on the retention of inappropriate prefix information. Additionally, if a trusted Complete Router Advertisement is sent, DNA systems will discard any prefix information regarding a disused address prefix, regardless of whether the host saw the prefix advertised with decreased lifetime. (It's done already - and not too complicated). Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 11:04:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gBH-0001Dz-F7 for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 11:04:05 -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 LAA03320 for ; Mon, 13 Feb 2006 11:02:17 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYXYV2EJGWAZU1DB@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 03:02:18 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C954080004; Tue, 14 Feb 2006 03:02:04 +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 DC3EA3C00E; Tue, 14 Feb 2006 03:02:03 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DG10k18295 for dna-list; Tue, 14 Feb 2006 03:01:00 +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 k1DG10u18290 for ; Tue, 14 Feb 2006 03:01:00 +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 <01LYXYTEG8ZG9C8T2B@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 03:00:44 +1100 Received: by localhost (Postfix, from userid 510) id 96B1CAB544; Tue, 14 Feb 2006 03:00:44 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id A06234FB2F for ; Tue, 14 Feb 2006 03:00:42 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k1DG0fJe023835; Mon, 13 Feb 2006 11:00:41 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 649673C8165; Mon, 13 Feb 2006 11:00:13 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id 5311D3C815D; Mon, 13 Feb 2006 11:00:13 -0500 (EST) Date: Mon, 13 Feb 2006 11:00:39 -0500 From: Greg Daley Subject: Re: [DNA] when to rerun DAD In-reply-to: <200602131512.k1DFCL8w006081@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <43F0AD27.9040106@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:6 M:4 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <200602131512.k1DFCL8w006081@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Hi Thomas, Thomas Narten wrote: > JinHyeock Choi writes: > >>> Some key questions for DNA. >>> >>> 1) when reusing "old" config, do we need to do anything special? E.g., >>> change state of ND entries to STALE? Put addresses in Optimistic >>> state? Take into account how much time has elapsed since we were >>> last attached (or just assume this happens as part of normal ND >>> timers?) >>> >>> What harm can occur from continuing to use the same information? >>> how does this compare with the harm of delaying the configuration >>> of an interface until one is more certain? > >> It may cause address conflict if a host continues to use the existing >> 'IP address' without DAD. While the host is away from the link, it's >> possible that another node happens to configure the host's IP address, >> because there was nobody to defend the address. > > IMO, we may want to think about having a separate discussion about > "when to run DAD". The blanket "rerun DAD at all times there is some > doubt" strikes me as overkill. For example, why rerun DAD if one has > been disconnected only 10 seconds? or 30? Maybe we should if we've > been disconnected for an hour (but then, do we need to bother with > DNA?). Also, why rerun DAD if one has generated an address using the > IEEE Identifier (and one has run DAD on it before)? That is, different > types of addresses have different "probability of possible collision" > risks in terms of other hosts attempting to use such addresses. Personally, I'm really loathe to introduce any situation where DAD is neglected, as it's really an all nodes or none approach. That said, we can certainly be a lot more clever about DAD and not sending DAD-NS packets inappropriately. I think it may be worthwhile to RECOMMEND that hosts do optimistic DAD if they have been away longer than a second, on the understanding that this shouldn't necessarily result in packets being sent to the link. In fact, explicitly rate-limiting active DAD NSs may be a good idea. It's notable that the collision rates for pseudo-random variables produce as low as 1 in 2^62 chance that collisions occur. Ideally with IEEE identifiers, multiple devices can't have the same address. I've worked for an organization where (in the early days) an entire box of NICs had the same MAC address. Additionally, MAC addresses may be programmed into cards (0x00FEEDABBA01) without the Layer 3 necessarily knowing. So the probability of collision is potentially higher than that for (say) CGA addresses which use SHA-1, or 3041 addresses which actually follow the recommendations of RFC1750. That said, neither of these are guaranteed either. Optimistic DAD may be useful as a passive system as it ensures that the re-arriving node doesn't displace the state held by a router. So assuming that no DAD NS is sent, the DNA host has to remain optimistic until it has performed the operation (which could be strongly rate limited, when remaining in the same link). A host which doesn't need to talk directly to neighbours (but can learn addresses of routers through RA) can still operate effectively even though it can't send multicast NS's and cannot send an NA,O=1. If the router isn't sending you packets for a while, and if the host's NCE for the router goes to PROBE (haven't worked this part out yet), the host will send a unicast NS, but won't be able to get back a response from the router, if there's an existing NCE for another device. In the case of no response, it's time to send DAD NS, if DNA still indicates the router is available. If there's no existing NCE, the router will resolve the host, which will NA O=0 to the router, and the router can send the NA based on the new NCE. If the router already had the NCE of this device, DAD NS can be delayed further until Neighbour Resolution is required, or a timer expires. So if a host is prepared to accept optimistic operation, and not send a DAD NS, it's possible to reduce the rate of messages without necessarily impinging on DAD. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 11:45:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8gph-0007rP-UD for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 11:45:50 -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 LAA06231 for ; Mon, 13 Feb 2006 11:44:03 -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 <01LYY0D0OITE9C93PG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 03:44:52 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 04A7280004; Tue, 14 Feb 2006 03:44:48 +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 927823C004; Tue, 14 Feb 2006 03:44:47 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DGiXQ18767 for dna-list; Tue, 14 Feb 2006 03:44:33 +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 k1DGiXu18763 for ; Tue, 14 Feb 2006 03:44:33 +1100 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 <01LYY0CLS7CU9AVXWI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 03:44:28 +1100 Received: by localhost (Postfix, from userid 510) id 2944880003; Tue, 14 Feb 2006 03:44:28 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 19F6F3C010 for ; Tue, 14 Feb 2006 03:44:26 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k1DGiPP2001539; Mon, 13 Feb 2006 11:44:25 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id D27713C8166; Mon, 13 Feb 2006 11:43:57 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id B32D13C8165; Mon, 13 Feb 2006 11:43:57 -0500 (EST) Date: Mon, 13 Feb 2006 11:44:23 -0500 From: Greg Daley Subject: Re: [DNA] Alternatives to "just send RS" when DNA starts In-reply-to: <200602131520.k1DFKTKi006272@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <43F0B767.802@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:13 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <200602131520.k1DFKTKi006272@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Hi Thomas, Thomas Narten wrote: > JinHyeock Choi writes: > >>> 2) Upon "link up", does DNA need to delay sending an RS per the >>> 2461/2462 rule? Are there ways to relax this that are consistent >>> with the original concerns that led to the existing wording in >>> 2461/2462? > >> I think 2461bis allows an immideate RS for mobile nodes. > > Can you cite text? And I hope they don't make an exception just for > "mobile nodes". S6.3.7 draft-ietf-ipv6-2461bis-05.txt In some cases, the random delay MAY be omitted if necessary. For instance, a mobile node, using [MIPv6], moving to a new link would need to discover such movement as soon as possible to minimize the amount of packet losses resulting from the change in its topological movement. Router Solicitations provide a useful tool for movement detection in Mobile IPv6 as they allow mobile nodes to determine movement to new links. Hence, if a mobile node received link layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's implementation depending on the level of certainty of the link layer hints and is outside the scope of this specification. Note that using this mechanism inappropriately (e.g. based on weak or transient indications) may result in Router Solicitation storms. Furthermore, simultaneous mobility of a large number of mobile nodes that use this mechanism can result in a large number of solicitations sent simultaneously. [cut] >> In case a host moves to a new link, it needs an RA for new >> configuration anyway, so it seems reasonable to send RS in >> anticipation of a link change. Also if you use unicast meessage to >> known destinations, no reply will come when you have moved to a new >> link. This will result in delay since you can't but rely on timeout to >> detect a link change. > > But one can also imagine parallel approaches. E.g, for the default > routers on the list, measure the actual observed RTTs during NS/NA > exchanges. Then, for DNA, send out an NS, using that RTT as an > estimate of how long you are willing to wait (and I'd expect this to > be very short, like 10ms or less). If that doesn't work, then fall > back to RS. One can imagine other optimizations. > Such an optimization may work, but its effectiveness is dependent on topology (single cell links would experience longer delays), and the amount of time available to upper-layer applications (for example, voip). It makes sense to mention this idea as an optimization to reduce the effect of multicasts on the link-layer. I'd suggest inclusion of a tentative link-layer address option, as the source address of the NS is likely to be considered optimistic for DAD purposes (it may not help, but may avoid the reverse NS/NA exchange if the router doesn't have the host in the NCE). How about: "... Multicast transmission has been shown to increase bandwidth consumption on certain wireless media at a rate much greater than that caused by unicast transmission. On such media, it MAY be useful to send a unicast NS transmission to the global address of one of the configured routers upon reception of a link-layer hint. This would avoid transmission of a multicast Router Solicitation if the router was available. The RS could then be delayed for an interval corresponding to the duration required to receive the unicast NA, if the router is still reachable. This optimization is dependent on topology, and increases delay and packet transmission if the link is composed of a single cell. Additionally, hosts with applications that are not able to delay for the lost NA in case of link-change SHOULD use RS instead. ..." Sending to the link-local address is insufficient, as some devices have been known to share a MAC address across different NICs, and CGAs with common public keys will be the same for two interfaces on one router, as the link-local prefix and key are the same. Actually, if the NS contained a landmark option and the router was a known DNA router, you could send to any address. Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 14:22:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jGt-0001Tu-3s for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 14:22:03 -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 OAA16875 for ; Mon, 13 Feb 2006 14:20:15 -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 <01LYY5SASIISAW3TU8@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 06:21:07 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9D9BFAB542; Tue, 14 Feb 2006 06:20:40 +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 5BD4B4FB3A; Tue, 14 Feb 2006 06:20:40 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DJKbf20638 for dna-list; Tue, 14 Feb 2006 06:20:37 +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 k1DJKbu20634 for ; Tue, 14 Feb 2006 06:20:37 +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 <01LYY5RYWWWWAW3TU8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 06:20:24 +1100 Received: by localhost (Postfix, from userid 510) id BAD9FAB58C; Tue, 14 Feb 2006 06:20:24 +1100 (EST) Received: from hotmail.com (bay106-f15.bay106.hotmail.com [65.54.161.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id ED9A74FB02 for ; Tue, 14 Feb 2006 06:20:23 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 Feb 2006 11:20:22 -0800 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 13 Feb 2006 19:20:22 +0000 (GMT) Date: Mon, 13 Feb 2006 11:20:22 -0800 From: Bernard Aboba Subject: RE: [DNA] when to rerun DAD In-reply-to: <200602131512.k1DFCL8w006081@cichlid.raleigh.ibm.com> X-Originating-IP: [208.54.41.2] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: narten@us.ibm.com, jinchoe@gmail.com Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 13 Feb 2006 19:20:22.0563 (UTC) FILETIME=[88F48730:01C630D2] Content-Transfer-Encoding: 7BIT >IMO, we may want to think about having a separate discussion about >"when to run DAD". The blanket "rerun DAD at all times there is some >doubt" strikes me as overkill. Right. DNAv4 does not require rerunning DAD. In fact, doing this every time will cause scalability problems particularly in the case of a power failure where many hosts simultaneously reboot. From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 14:23:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jIk-0003b1-2q for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 14:23:58 -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 OAA16967 for ; Mon, 13 Feb 2006 14:22:10 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYY5UW2OJ4AW3X2N@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 06:22:52 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F00A680004; Tue, 14 Feb 2006 06:22:45 +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 A3FBB3C007; Tue, 14 Feb 2006 06:22:45 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DJMgQ20694 for dna-list; Tue, 14 Feb 2006 06:22:42 +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 k1DJMgu20689 for ; Tue, 14 Feb 2006 06:22:42 +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 <01LYY5UKLWBM9AVS3P@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 06:22:30 +1100 Received: by localhost (Postfix, from userid 510) id A3147AB58C; Tue, 14 Feb 2006 06:22:30 +1100 (EST) Received: from hotmail.com (bay106-f5.bay106.hotmail.com [65.54.161.15]) by moe.its.monash.edu.au (Postfix) with ESMTP id E148D4FB07 for ; Tue, 14 Feb 2006 06:22:28 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 Feb 2006 11:22:27 -0800 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 13 Feb 2006 19:22:27 +0000 (GMT) Date: Mon, 13 Feb 2006 11:22:27 -0800 From: Bernard Aboba Subject: RE: [DNA] how much effort to deal with "unplanned renumbering" In-reply-to: <200602131516.k1DFGKK9006254@cichlid.raleigh.ibm.com> X-Originating-IP: [208.54.41.2] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: narten@us.ibm.com, jinchoe@gmail.com Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 13 Feb 2006 19:22:27.0426 (UTC) FILETIME=[D3611C20:01C630D2] Content-Transfer-Encoding: 7BIT >I think we need to think hard about how much we are going to >complicate DNA to deal with "broken renumbering attempts", which are >not supposed to happen in the first place. The IPv6 protocols do not >really support taking away a prefix prematurely, and when this >happens, things aren't guarnteed to work. Thus, this is not advisable >in general. Right. DNAv4 assumes that a DHCP lease, once given out, is valid until it expires. I agree that trying to take this into account adds needless complexity to DNAv6. From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 14:32:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jQo-0007AY-EN for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 14:32:18 -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 OAA17437 for ; Mon, 13 Feb 2006 14:30:31 -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 <01LYY615IKY8AZU2BC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 06:27:29 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0D210AB544; Tue, 14 Feb 2006 06:27:02 +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 BE0464FB2F; Tue, 14 Feb 2006 06:27:01 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DJQw420780 for dna-list; Tue, 14 Feb 2006 06:26:58 +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 k1DJQvu20776 for ; Tue, 14 Feb 2006 06:26:57 +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 <01LYY60VXUEU9AVWUT@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 06:26:49 +1100 Received: by localhost (Postfix, from userid 510) id 3F0F0AB542; Tue, 14 Feb 2006 06:26:49 +1100 (EST) Received: from hotmail.com (bay106-f6.bay106.hotmail.com [65.54.161.16]) by curly.its.monash.edu.au (Postfix) with ESMTP id 7102C4FB20 for ; Tue, 14 Feb 2006 06:26:48 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 Feb 2006 11:26:47 -0800 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 13 Feb 2006 19:26:46 +0000 (GMT) Date: Mon, 13 Feb 2006 11:26:46 -0800 From: Bernard Aboba Subject: RE: [DNA] Alternatives to "just send RS" when DNA starts In-reply-to: <200602131520.k1DFKTKi006272@cichlid.raleigh.ibm.com> X-Originating-IP: [208.54.41.2] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: narten@us.ibm.com, jinchoe@gmail.com Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 13 Feb 2006 19:26:47.0010 (UTC) FILETIME=[6E1A7C20:01C630D3] Content-Transfer-Encoding: 7BIT >But one can also imagine parallel approaches. E.g, for the default >routers on the list, measure the actual observed RTTs during NS/NA >exchanges. Then, for DNA, send out an NS, using that RTT as an >estimate of how long you are willing to wait (and I'd expect this to >be very short, like 10ms or less). If that doesn't work, then fall >back to RS. One can imagine other optimizations. DNAv4 does both DHCP and ARP in parallel -- so that the DNAv4 procedure is never slower than DHCP. From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 15:04:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jw0-0000AJ-7N for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 15:04:34 -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 PAA19441 for ; Mon, 13 Feb 2006 15:02:44 -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 <01LYY5RCWYC49AVRPE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 06:19:56 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2131BAB604; Tue, 14 Feb 2006 06:19:55 +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 CBC6B4FB05; Tue, 14 Feb 2006 06:19:54 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DJItc20605 for dna-list; Tue, 14 Feb 2006 06:18:55 +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 k1DJItu20601 for ; Tue, 14 Feb 2006 06:18:55 +1100 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 <01LYY5Q0YDKW9AVRPE@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 06:18:50 +1100 Received: by localhost (Postfix, from userid 510) id B892480002; Tue, 14 Feb 2006 06:18:50 +1100 (EST) Received: from hotmail.com (bay106-f7.bay106.hotmail.com [65.54.161.17]) by larry.its.monash.edu.au (Postfix) with ESMTP id E62313C006 for ; Tue, 14 Feb 2006 06:18:49 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 Feb 2006 11:18:48 -0800 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Mon, 13 Feb 2006 19:18:47 +0000 (GMT) Date: Mon, 13 Feb 2006 11:18:47 -0800 From: Bernard Aboba Subject: RE: [DNA] retaining current IP configuration as DNA kicks in In-reply-to: <200602131509.k1DF9c6h006070@cichlid.raleigh.ibm.com> X-Originating-IP: [208.54.41.2] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: narten@us.ibm.com, jinchoe@gmail.com Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 13 Feb 2006 19:18:48.0504 (UTC) FILETIME=[50E44380:01C630D2] Content-Transfer-Encoding: 7BIT >Why? > >I've thought about this some, and the question I ask is "what breaks >if a host does send such packets?" If that answer is "nothing", then >no harm done. In DNAv4, there is a potential issue with private addresses (e.g. a host could move from one private network to another one, resulting in an address conflict), but I don't think there is an analog here. >It may be that sending such packets is useless, but that's not a >problem. If it actually causes things to break or bad things to >happen, then yes, we should think about disallowing such behavior. But >lets evaluate the cost/benefit explicitly. At worst the host will send some packets with the wrong address, then the address will change. From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 13 15:14:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8k5m-0004HZ-Dg for dna-archive@megatron.ietf.org; Mon, 13 Feb 2006 15:14:38 -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 PAA20196 for ; Mon, 13 Feb 2006 15:12:51 -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 <01LYY7K41ODE9AVUIN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 07:11:23 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 89277AB58D; Tue, 14 Feb 2006 07:11:20 +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 4B5144FB02; Tue, 14 Feb 2006 07:11:20 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1DKB0b21309 for dna-list; Tue, 14 Feb 2006 07:11:00 +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 k1DKB0u21305 for ; Tue, 14 Feb 2006 07:11:00 +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 <01LYY7JJADDMAW41KJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 07:10:53 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A142CAB604; Tue, 14 Feb 2006 07:10:52 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 78A464FB02; Tue, 14 Feb 2006 07:10:52 +1100 (EST) Received: from [150.169.1.178] by mail-store-2.its.monash.edu.au (mshttpd) ; Mon, 13 Feb 2006 15:10:52 -0500 Date: Mon, 13 Feb 2006 15:10:52 -0500 From: Greg Daley Subject: Re: RE: [DNA] Alternatives to "just send RS" when DNA starts Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: narten@us.ibm.com, jinchoe@gmail.com, dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.05 (built Mar 3 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Hi Bernard, ----- Original Message ----- From: Bernard Aboba Date: Monday, February 13, 2006 2:26 pm Subject: RE: [DNA] Alternatives to "just send RS" when DNA starts > >But one can also imagine parallel approaches. E.g, for the default > >routers on the list, measure the actual observed RTTs during NS/NA > >exchanges. Then, for DNA, send out an NS, using that RTT as an > >estimate of how long you are willing to wait (and I'd expect this to > >be very short, like 10ms or less). If that doesn't work, then fall > >back to RS. One can imagine other optimizations. > > DNAv4 does both DHCP and ARP in parallel -- so that the DNAv4 > procedure is > never slower than DHCP. The issue which Thomas (and you) were trying to solve is exacerbation of the multicast traffic due to probing on cell change. Parallel transmission attempts which do NS+RS do not solve this. Greg > From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 04:30:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8wVZ-0003BS-CL for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 04:30:07 -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 EAA11388 for ; Tue, 14 Feb 2006 04:28:19 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYYZC3F198AW41VN@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 20:26:50 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4BF0D80005; Tue, 14 Feb 2006 20:26:36 +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 023093C008; Tue, 14 Feb 2006 20:26:36 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1E9PKj28800 for dna-list; Tue, 14 Feb 2006 20:25:20 +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 k1E9PJu28794 for ; Tue, 14 Feb 2006 20:25:19 +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 <01LYYZAEJCJKAW41VN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 20:25:14 +1100 Received: by localhost (Postfix, from userid 510) id A0875AB543; Tue, 14 Feb 2006 20:25:14 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.202]) by curly.its.monash.edu.au (Postfix) with ESMTP id 24C984FB06 for ; Tue, 14 Feb 2006 20:25:12 +1100 (EST) Received: by uproxy.gmail.com with SMTP id k40so242351ugc for ; Tue, 14 Feb 2006 01:25:10 -0800 (PST) Received: by 10.66.166.3 with SMTP id o3mr1356830uge; Tue, 14 Feb 2006 01:25:10 -0800 (PST) Received: by 10.67.24.19 with HTTP; Tue, 14 Feb 2006 01:25:10 -0800 (PST) Date: Tue, 14 Feb 2006 18:25:10 +0900 From: JinHyeock Choi Subject: [DNA] Re: retaining current IP configuration as DNA kicks in In-reply-to: <200602131509.k1DF9c6h006070@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <92e919fb0602140125k5f6efa6ble7f5abab596098dc@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UP9i7Vsa1xeCrgTLGUiDB6dHwQfBhkNYNEgbmg6eZnK7xvhzTW83lByx317TnCVJizMmrqmY8WWNEOV18B/5CN/CtxYj7R86Va+Yueefpmnw+Lv/9+sYD5AZjLF49vk2PunWZBxXGqFIDVDRuca/CpKgNUOqeVaXToCdA+k0FJo= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <92e919fb0602130646v4f7ac3c2jee852ed2a06c3f78@mail.gmail.com> <200602131509.k1DF9c6h006070@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Dear Thomas > > I'd like to make a clarification. IMO, upon "link up" event, > > though a host can keep the existing configuration information, > > it should not use the information until DNA procedure confirms > > that the host remains at the same link. > > > For example, a host can retain its current IP address but should not send > > a packet with the address as a source address till DNA comletes. > > Why? > > I've thought about this some, and the question I ask is "what breaks > if a host does send such packets?" If that answer is "nothing", then > no harm done. > > It may be that sending such packets is useless, but that's not a > problem. If it actually causes things to break or bad things to > happen, then yes, we should think about disallowing such behavior. But > lets evaluate the cost/benefit explicitly. If a host has moved, such a packets are useless and wasting up wireless bandwidth. But 'should not' may be a too strong word and 'would better not' would be better. Also I should have picked a better example. How about neighbor information? If a host immediately sends packets with the existing link-layer addresses from cache, those packets would be lost in case the host moved to a new link. In cost/ benefit comparison, what will be the benefit for a host to use the information which may not be valid? DNA will be completed just after 1 RS/ RA exchange and that will not take much time. So I think it may be better to wait for DNA completion, just a few MSs, rather than risking using the invalid information to waste up bandwidth. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 04:30:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8wWF-0003bj-Ab for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 04:30:47 -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 EAA11420 for ; Tue, 14 Feb 2006 04:29:01 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYYZFZU890AZU7V3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 20:29:57 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id ECAD280002; Tue, 14 Feb 2006 20:29:44 +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 994E93C00D; Tue, 14 Feb 2006 20:29:44 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1E9TfP28847 for dna-list; Tue, 14 Feb 2006 20:29:41 +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 k1E9Teu28841 for ; Tue, 14 Feb 2006 20:29:40 +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 <01LYYZFS18VOAZU7V3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 20:29:34 +1100 Received: by localhost (Postfix, from userid 510) id A1DFDAB543; Tue, 14 Feb 2006 20:29:34 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.205]) by curly.its.monash.edu.au (Postfix) with ESMTP id 04AC34FB03 for ; Tue, 14 Feb 2006 20:29:32 +1100 (EST) Received: by uproxy.gmail.com with SMTP id m3so439108ugc for ; Tue, 14 Feb 2006 01:29:29 -0800 (PST) Received: by 10.67.30.9 with SMTP id h9mr1661421ugj; Tue, 14 Feb 2006 01:29:29 -0800 (PST) Received: by 10.67.24.19 with HTTP; Tue, 14 Feb 2006 01:29:29 -0800 (PST) Date: Tue, 14 Feb 2006 18:29:29 +0900 From: JinHyeock Choi Subject: [DNA] Re: Alternatives to "just send RS" when DNA starts In-reply-to: <200602131520.k1DFKTKi006272@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <92e919fb0602140129r22416e21id39a8d90e5ac99c5@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ndaTVz3yUk4BIC95nPLo5XrScfVq1xHNgCVO63VPQBfuKbGOIvbbO5yMApuC+Lqn26Pvtfc+9k+bkvK35q1gqf3Uf34xtVkoYYM1/ktEJX5SMpiHPfOQFr8EZMJjFvipwoBp5C9IOiv7qtT1hhSPjfalpgNfI059HX/tVAozg2Y= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <92e919fb0602130646v4f7ac3c2jee852ed2a06c3f78@mail.gmail.com> <200602131520.k1DFKTKi006272@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Dear Thomas > > I think 2461bis allows an immideate RS for mobile nodes. > > Can you cite text? And I hope they don't make an exception just for > "mobile nodes". 9th bullet of APPENDIX F: CHANGES FROM RFC 2461 from 2461 bis o Allowed mobile nodes to be exempt from adding random delays before sending an RS during a handover. > But one can also imagine parallel approaches. E.g, for the default > routers on the list, measure the actual observed RTTs during NS/NA > exchanges. Then, for DNA, send out an NS, using that RTT as an > estimate of how long you are willing to wait (and I'd expect this to > be very short, like 10ms or less). If that doesn't work, then fall > back to RS. One can imagine other optimizations. Allow me to clarify the above. I understand that, according to your suggestion, Upon receiving link-up indication, an MN sends an unicast NS to a known router (or routers) and waits for a certain amount of time (based on measured RTT value). Upon the time expiration, the MN sends an RS to get an RA. Am I right? If so, this will certainly save packets in case the MN stays at the same link. But in case of a link change, there will be an additional delay for NS/ NA exchange and we need to measure RTT which may vary drastically in wireless environment. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 04:32:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8wXu-0003ys-QK for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 04:32:31 -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 EAA11493 for ; Tue, 14 Feb 2006 04:30:44 -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 <01LYYZI1QFEG9C9DT2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 20:31:26 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4881780004; Tue, 14 Feb 2006 20:31:24 +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 03D903C00C; Tue, 14 Feb 2006 20:31:24 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1E9VKw28885 for dna-list; Tue, 14 Feb 2006 20:31:20 +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 k1E9VJu28879 for ; Tue, 14 Feb 2006 20:31:19 +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 <01LYYZHRZA4W9C9DT2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 20:31:11 +1100 Received: by localhost (Postfix, from userid 510) id 4C00FAB58D; Tue, 14 Feb 2006 20:31:11 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.206]) by moe.its.monash.edu.au (Postfix) with ESMTP id B43494FB02 for ; Tue, 14 Feb 2006 20:31:09 +1100 (EST) Received: by uproxy.gmail.com with SMTP id c2so156239ugf for ; Tue, 14 Feb 2006 01:31:06 -0800 (PST) Received: by 10.66.243.20 with SMTP id q20mr1647105ugh; Tue, 14 Feb 2006 01:31:06 -0800 (PST) Received: by 10.67.24.19 with HTTP; Tue, 14 Feb 2006 01:31:06 -0800 (PST) Date: Tue, 14 Feb 2006 18:31:06 +0900 From: JinHyeock Choi Subject: Re: [DNA] Alternatives to "just send RS" when DNA starts In-reply-to: <43F0B767.802@research.panasonic.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Thomas Narten , dna@eng.monash.edu.au Message-id: <92e919fb0602140131i6d9ec59bmdc5c8052abdb99c7@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UjIlz7Np66WLZyYAPlvL/k2QGKyKHyNYcO6Fj0UQqskZkfngZcIqZHJk4sIa3gBLRgZXQvwchrdwSiJq0DWC0QanmI3v7ebBpZr3KAGVij+65pF/WDOzWkFSNrSEKVdYPHPRpmwy1n/eIsKWN8678bUvTDy0CzVPbhuHwiQcCTo= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <200602131520.k1DFKTKi006272@cichlid.raleigh.ibm.com> <43F0B767.802@research.panasonic.com> Content-Transfer-Encoding: 7BIT Dear Greg > Such an optimization may work, but its effectiveness is dependent > on topology (single cell links would experience longer delays), > and the amount of time available to upper-layer applications (for > example, voip). > > It makes sense to mention this idea as an optimization to reduce > the effect of multicasts on the link-layer. I'd suggest inclusion > of a tentative link-layer address option, as the source > address of the NS is likely to be considered optimistic for DAD > purposes (it may not help, but may avoid the reverse NS/NA exchange > if the router doesn't have the host in the NCE). > > How about: > > "... > Multicast transmission has been shown to increase bandwidth > consumption on certain wireless media at a rate much greater > than that caused by unicast transmission. On such media, > it MAY be useful to send a unicast NS transmission > to the global address of one of the configured routers upon > reception of a link-layer hint. This would avoid transmission > of a multicast Router Solicitation if the router was available. > The RS could then be delayed for an interval corresponding to > the duration required to receive the unicast NA, if the router > is still reachable. > > This optimization is dependent on topology, and increases delay > and packet transmission if the link is composed of a single cell. > Additionally, hosts with applications that are not able to delay > for the lost NA in case of link-change SHOULD use RS instead. > ..." The above changes the existing DNA solution procedure, so I think we'd better investigate it from the various angles. I am concerned about relying on RTT value which may be volatile in wireless environment. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 04:33:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8wZK-0004Ve-Lb for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 04:33:58 -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 EAA11582 for ; Tue, 14 Feb 2006 04:32:12 -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 <01LYYZJH2M4OAZU4Q3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 14 Feb 2006 20:32:51 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 527D8AB544; Tue, 14 Feb 2006 20:32:33 +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 0A36C4FB02; Tue, 14 Feb 2006 20:32:33 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1E9WUQ28924 for dna-list; Tue, 14 Feb 2006 20:32:30 +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 k1E9WUu28920 for ; Tue, 14 Feb 2006 20:32:30 +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 <01LYYZJCN0N6AZU4Q3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 14 Feb 2006 20:32:27 +1100 Received: by localhost (Postfix, from userid 510) id 7290880002; Tue, 14 Feb 2006 20:32:27 +1100 (EST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.196]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0152B3C005 for ; Tue, 14 Feb 2006 20:32:25 +1100 (EST) Received: by uproxy.gmail.com with SMTP id m2so77850uge for ; Tue, 14 Feb 2006 01:32:23 -0800 (PST) Received: by 10.66.220.20 with SMTP id s20mr1645082ugg; Tue, 14 Feb 2006 01:32:23 -0800 (PST) Received: by 10.67.24.19 with HTTP; Tue, 14 Feb 2006 01:32:23 -0800 (PST) Date: Tue, 14 Feb 2006 18:32:23 +0900 From: JinHyeock Choi Subject: [DNA] Re: when to rerun DAD In-reply-to: <200602131512.k1DFCL8w006081@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <92e919fb0602140132k73581233o5224b9d075a482fc@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SGd4ADMQeyuN+9Yqat1TRinhKo7gRwEdf8vqz0WywpavDeNBlKi4EVg27dOAiAwW7AEyG5ERhLRR8UW3KmAekPTXqroYVFow/3vpAKJqKLxUNHDHTMmeYMgXunJbqFPdODqlZ05SEHwk4Na6GDfxrgY7NCzxyFpKUSvx22rq6Qs= X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) References: <92e919fb0602130646v4f7ac3c2jee852ed2a06c3f78@mail.gmail.com> <200602131512.k1DFCL8w006081@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas > > It may cause address conflict if a host continues to use the existing > > 'IP address' without DAD. While the host is away from the link, it's > > possible that another node happens to configure the host's IP address, > > because there was nobody to defend the address. > > IMO, we may want to think about having a separate discussion about > "when to run DAD". The blanket "rerun DAD at all times there is some > doubt" strikes me as overkill. ok. > For example, why rerun DAD if one has > been disconnected only 10 seconds? or 30? Maybe we should if we've > been disconnected for an hour (but then, do we need to bother with > DNA?). ok but we need to measure actual detachment time with some precision, which may be complicated. For example, exactly when an L2 link is becoming down? In 802.11 case, upon completing association procedure, we can say that an L2 link is up. But a wireless link can be down without any formal procedure (such as de-association) because of deteriorating channel condition. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 12:56:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F94Pr-0003CR-4V for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 12:56:44 -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 MAA16135 for ; Tue, 14 Feb 2006 12:54:55 -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 <01LYZH45UWWS9AVB9E@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 04:55:39 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6145080006; Wed, 15 Feb 2006 04:55:36 +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 07A963C00D; Wed, 15 Feb 2006 04:55:36 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1EHrPo01567 for dna-list; Wed, 15 Feb 2006 04:53:25 +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 k1EHrOu01563 for ; Wed, 15 Feb 2006 04:53:24 +1100 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 <01LYZH1C9PMI9C8NTW@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 04:53:20 +1100 Received: by localhost (Postfix, from userid 510) id 014D380002; Wed, 15 Feb 2006 04:53:19 +1100 (EST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by larry.its.monash.edu.au (Postfix) with ESMTP id E30EE3C00E for ; Wed, 15 Feb 2006 04:53:16 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k1EHrE8u006222; Tue, 14 Feb 2006 10:53:15 -0700 (MST) 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 k1EHrD81757134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2006 09:53:14 -0800 (PST) Date: Tue, 14 Feb 2006 09:52:34 -0800 From: Erik Nordmark Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: <200602082131.k18LVYZM012621@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: dna@eng.monash.edu.au Message-id: <43F218E2.5070509@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: <200602082131.k18LVYZM012621@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > DNA requires that a host keep track of the links to which it has > recently attached. For each known link, information about that link, > such as default router addresses, prefix information, MTU, Lifetimes, > etc. are kept in what are called Link Instances (aka Candidate Link > Objects in dna-cpl). Link Instances are identified by the set of > on-link global prefixes that have been advertised on that link, as no > prefix may be assigned to different links simultaneously. At any given > time, one LI is considered the Current LI, and the parameters > associated with the CLI are what are actually configured on the link > as defined in 2461/2462. I'm not sure all the information about the link needs to be retained (default router address, MTU above). What is strictly necessary is the information to tell which link it is, i.e. the prefixes and their lifetimes. In particular, the list of default routers for a particular link might change a lot more frequently than the set of prefixes assigned to the link. I think "on-link global prefixes" above would be a bad idea; we don't want to restrict this to the case when on-link prefixes are advertised, because for media where multicast is expensive (IEEE .15.4 and .16) folks are discussing ways to avoid multicast NSes; one way to do this is to not advertise any on-link prefixes (but advertise prefixes with the A bit set) which results in the packets being unicast to the default router per standard RFC 2461. So I think DNA should operate using prefixes that have either the L (on-link), or the A (addrconf), or both bits set. > When a "link up" event is detected, a host will need to determine what > IP configuration parameters should be used. A simple (but naive) > approach would be to discard all associated information and initiate > the normal startup procedure as described in 2461/2462. However, this > has the downside of causing upper-layer protocols using the (just > discarded) addresses to possibly receive "hard errors" and terminate > connections using those addresses. In the common case where a link > goes away momentarily and then comes back up connected to the same > link (with the same associated config information) this is obviously > undesirable. The last sentence seems to say that a link is connected to a link (the link goes away and then comes back up connected to the same link). If we want to be more careful about terminology we would state that the 'link up' and 'link down' events do not signal anything about the link itself; they merely signal something about the attachment point to the link. Thus it makes sense to say the attachment point goes down ('link down' event) and them comes back up and is connected to the same link. > DNA takes the approach that upon reciept of a "link up" event, the > most-recently used configuration information should continue to be > used, and that DNA should be initiated to (quickly) determine whether > one is attached to a new link, or one to which one has been previously > attached. In the simple case, DNA will quickly determine whether one > has reattached to the current link or to another known link. > Specifically, it will do so by sending a single RS and receiving a > single RA, one containing a prefix that it has seen before, thereby > identifying the link. In such cases, DNA can declare its work done, > and any new prefixes in the received RA are added to the CLI. In the above description it isn't clear to me whether you are discussion - how CPL works - how dna-protocol works - some fundamental statement which spans the two It is clearly highly desirable to handle this with the receipt of a single RA, and that RA should arrive as soon as possible. But the "as soon as possible" requires changes to the router as specified in dna-protocol. > In some scenarios, however, things are more complex. Specifically, DNA > may receive an RA that contains only prefixes it has never seen > before. When this happens, it may not be sure whether the prefixes > correspond to a new link (i.e., one not visited before), or a > previously-visited link, but for which it has not yet seen all the > advertised prefixes. While it might be simplest to assume that receipt > of such an RA indicated attachment to a new link, that can lead to > (incorrectly) invalidating other configuration information for that > link. To handle this case, DNA takes extra steps. First, it > distinguishes between "complete" and "incomplete" LIs. Complete LIs > are those for which there is a high probability of having recieved all > prefixes being advertised on that link. Incomplete LIs are those for > which insufficient time has elapsed to conclude with reasonable > certainty that it is likely that all advertised prefixes have been > seen. > > When DNA receives an RA advertising (only) unknown prefixes, and the > CLI is not "complete", DNA waits for additional RAs before deciding > whether the link is new or not. In the above paragraphs by "DNA" you appear to mean "CPL", right? If you want to give an overview of the combination of dna-protocol* and CPL, then you need to modify the text. And the "two variants" below makes me believe that is what you are trying to accomplish. > The DNA procedure is tightly coupled with the use of 2461/2462, since > DNA uses the same messages. > > There are two variants of DNA. In the first variant, hosts interact > with routers that have implemented 2461/2462, but have not implemented > any DNA extensions. I actually don't think they are variants. I'd expect a host to send a single RS that is capable of doing the best possible whether the routers support just 2461 or support the DNA extensions. We don't want the host to have to guess which form of routers there are on a potentially new link before it sends the first RS! But due to having two separate documents, the combination isn't written down anywhere, so it isn't unreasonable for folks to think there are two variants. > Some key questions for DNA. > > 1) when reusing "old" config, do we need to do anything special? E.g., > change state of ND entries to STALE? Put addresses in Optimistic > state? Take into account how much time has elapsed since we were > last attached (or just assume this happens as part of normal ND > timers?) Good questions. For DAD I think it makes sense to always switch to optimistic state even for a short link down or when a link up arrives without a preceding link down. This is ok since doing that, and not sending any DAD probe, is not expensive. Once a RA arrives indicating that the host did not move, then the optimistic mode can be turned off. For ND state of STALE the situation is similar to the default router list and other cached information. If the host has been disconnected from the link for a fraction of a section or a few seconds, it might have missed some important packet (such as an unsolicited NA telling it that the L2 address of a neighbor has changed, or an unsolicited RA telling it that a router is going away.) But it could have missed such a packet due to bit errors even if it was connected to the link. And we have NUD as a way to recover from those cases, so why not use unmodified NUD to recover from the case when the host was disconnected for a while. Of course, if the host determines that it has moved to a different link, then the information in the neighbor cache isn't useful any more. I don't think we need extra timers for this; the existing timers (for default router list entries, NUD probing, etc) are ok, since they are (supposed to be ;-) ok when the host remains attached to the link. Thus the argument about packet loss caused by bit errors vs. packet loss caused by being detached from the link apply here as well. > What harm can occur from continuing to use the same information? > how does this compare with the harm of delaying the configuration > of an interface until one is more certain? > > 2) Upon "link up", does DNA need to delay sending an RS per the > 2461/2462 rule? Are there ways to relax this that are consistent > with the original concerns that led to the existing wording in > 2461/2462? What is important is that DNA doesn't cause a flood of packets that makes things worse. I think somebody sent a reference to a paper on a study of 802.11 using a bunch of stations moving together (think of a vehicle with many devices) and found that the L2 association meant that the 'link up' events were already spread over time. > 3) Upon "link up", what messages can host send that would help it to > quickly determine if on same link? Is it just an RS? what about > unicast? what about an NS (e.g., perhaps including a Landmark > option)? The WG has talked about NS in the past, in particular an NS to the old default router(s). This is an extra packet (a RS plus an NS instead of just an NS). And since neither the routers L2 address nor the routers link-local address need to be globally unique, the fact that the NS gets a response doesn't mean the host is still attached to the same link. > Are there other messages that can be sent that could help? Like NS > queries unicast to known routers? The host would have to know a global IPv6 address of the router, and the router MUST NOT respond on interface 1 for a NS addressed to it's global address assigned to interface 2, for the resulting NA to be a fool-proof indication that the host didn't move. > Note: on some links, like wireless ethernet, multicast is > (relatively) "expensive". Would it be better to just send a few > immediate unicast NS (or RS) messages to the routers we know about? > and send a multicast RS only if the unicast fails? Or do both in > parallel? Two things: - first sending a NS and waiting for an answer (how long?), perhaps retransmitting the NS, before sending the RS means that DNA in the case when the host did move to a different link will take a lot longer than in dna-protocol3. Note that in this case the NS would not elicit a response. (But I don't know if we've talked about sending the same RS as in dna-protocol3, but unicasting it at L2 to an old router address. That would require some tweaks to get an immediate response instead of a delayed response.) - The problem of expensive multicast/broadcast isn't unique to DNA. IEEE 15.4 will see this when I initially power on devices that do RFC 2461, since each multicasts an RS. A solution to that might be some combination of L2 and 2461 optimizations. At the recent 6lowpan interim meeting we talked about the possibility of having the 15.4 coordinator be an IPv6 router, in which case packets sent to the "all routers IPv6 multicast address" can be unicast to the coordinator's L2 address. Such things can presumably be covered in an IPv6-over-foo document that gets some careful review. > 4) When one gets an RA containing prefixes that one has not seen > before, is the algorithm in CPA sufficient or ideal? Are there > other probes one could send? E.g., upon indication that a new prefix > is available, send additional probes quickly to try and flush out > things more quickly? Or, should the host keep additional info in > LIs, e.g., keeping track of which router advertised what prefixes, > so that it can distingish "prefix from previously unknown router" > vs. "new prefix from router we've received RAs from before"? It the routers don't have the DNA extensions, then such probes would serve to purpose since the multicast RAs they trigger are rate limited to one every 3 seconds. And if the routers do implement the DNA extensions, then the host can always tell from the first RA whether it has moved or not. > 5) When DNA determines that one is no longer connected to the same > link as before, one swaps configs. Care must be taken to apply > information learned from RAs received since last "link up" get > applied to correct LI. Yes, the documents might need to be more explicit about this. CPL tries to be explicit in its rules for the candidate link objects. > 6) if DNA determines that was has reconnected to the same link, what > else needs to be done? Rerun DAD? Do nothing? Does the answer > depend on how long it has been since one was previously connected > to that link? I think the reruning of DAD needs to be a function of how long the host has been disconnected and the normal packet loss on the link. If the host is always connected to the link, DAD might still fail to find duplicates due to normal packet loss. Thus we don't need to do better than this when it comes to DNA handling being disconnected and later reconnected. In reality though, with wireless links there is a floating boundary between being disconnected and "normal" packet loss; the further away from the AP the station is, the higher packet loss. And when going even further, after some time the host NIC determines that the AP is unreachable. But I don't know if there is an upper bound on the time between the host having a 90, 99, or 100% packet loss until it declares the AP gone and the link down. So I think it is time to pull a number out of a hat. How about 30 seconds? > 7) Is there ever a time when one should discard still-valid prefix > information on a link? That is, suppose a bogus router shows up and You mean it sets the "bogus" bit in the RA? The host has no way, unless we run SEND, to tell apart the good, bad, and ugly routers. > sends out an RA with prefix information with a long Lifetime. This > information may stay associated with a link for weeks, because no > router ever advertises the prefix with a Lifetime of 0. Pre-DNA, > that info would presumably get discarded more quickly because one > doesn't keep old LI information around. But with DNA, we may find > this happens and causes problems. You seem to say DNA would make this worse, and I don't understand how. If a host remains attached to the same link forever, then the bad information will stay in its prefix list until it times out. Clearly DNA can't be worse than that; the information is only used when attached to the link where the bogus router lives. > For robustness, it seems like it > might be desirable to discard prefix information in the _absence_ > of RAs containing that prefix, in the case where other RAs continue > to be received with other prefix information. I.e., if one knows > that one has missed (say) N RAs, time out the info if one is > receiving other info from other routers. (note: the situation is > further aggrevated by having routers cache RAs learned from other > routers.) The DNA WG talked about this in the context of flash renumbering and immediate reassignment, but is is a bit problematic even in that context because we are making prefixes disappear faster than RFC 2461 intended. Thus things might become more brittle. We can't guard against malicious routers unless we run SEND, right? If we run SEND and still have a problem with bogus prefixes being advertised, the operator's setup is broken AFAIK. (When shim6 is deployed it would probably "route around" such brokenness, by discovering that the prefix/address doesn't work end-to-end, which would given some higher robustness, but still, this doesn't get any worse with DNA AFAIK.) Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 13:01:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F94U8-00049q-Tt for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 13:01:09 -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 MAA16277 for ; Tue, 14 Feb 2006 12:59:21 -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 <01LYZH8U9CHYAW474A@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 04:59:41 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B1FBDAB544; Wed, 15 Feb 2006 04:59:22 +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 6375E4FB02; Wed, 15 Feb 2006 04:59:22 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1EHxHm01633 for dna-list; Wed, 15 Feb 2006 04:59:17 +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 k1EHxHu01629 for ; Wed, 15 Feb 2006 04:59:17 +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 <01LYZH8KAFBQ9AVNWK@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 04:59:09 +1100 Received: by localhost (Postfix, from userid 510) id 63C18AB542; Wed, 15 Feb 2006 04:59:09 +1100 (EST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2927E4FB1B for ; Wed, 15 Feb 2006 04:59:07 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.226.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k1EHx6Qj016718; Tue, 14 Feb 2006 10:59:06 -0700 (MST) 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 k1EHx4wD758589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2006 09:59:05 -0800 (PST) Date: Tue, 14 Feb 2006 09:58:25 -0800 From: Erik Nordmark Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43F21A41.3050502@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: Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: > \> Are there other messages that can be sent that could help? Like NS >> queries unicast to known routers? > > This is what DNAv4 does (via unicast ARP), because this enables a > determination of whether the host has connected to a previously > encountered router, without ambiguity. Does this work if you have a router which - uses the same IEEE 802 MAC address on multiple ports (which is compliant with the IEEE specifications AFAIK) - also does NAT so that the router's IP address on multiple ports is 10.0.0.1 In that case you'd get an ARP response even though the host had moved to a different link. Because IPv6 has link-local addresses the corresponding situation can be quite common even though there is no NAT. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 13:30:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F94wF-0005qi-Op for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 13:30:14 -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 NAA18614 for ; Tue, 14 Feb 2006 13:28:24 -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 <01LYZI9O3YP29C8U3P@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 05:28:21 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2A1C8AB60E; Wed, 15 Feb 2006 05:28:17 +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 4B1624FB58; Wed, 15 Feb 2006 05:28:16 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1EIS4K01959 for dna-list; Wed, 15 Feb 2006 05:28:04 +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 k1EIS3u01955 for ; Wed, 15 Feb 2006 05:28:03 +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 <01LYZI92OJJ6AW477F@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 05:27:48 +1100 Received: by localhost (Postfix, from userid 510) id 933E8AB545; Wed, 15 Feb 2006 05:27:48 +1100 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by curly.its.monash.edu.au (Postfix) with ESMTP id 656FC4FB2F for ; Wed, 15 Feb 2006 05:27:46 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k1EIRiuf027783; Tue, 14 Feb 2006 11:27:44 -0700 (MST) 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 k1EIRgjb770530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2006 10:27:43 -0800 (PST) Date: Tue, 14 Feb 2006 10:27:03 -0800 From: Erik Nordmark Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: <200602091331.k19DV0fH027627@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: Bernard Aboba , dna@eng.monash.edu.au Message-id: <43F220F7.3000602@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: <200602091331.k19DV0fH027627@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > Why not allow inclusion of a landmark option in an NS/NA? One benefit > of an NS is that we presumably don't have to delay sending one, and > the responder doesn't delay in responding. So this can be very fast. But an NS is ignored if the target doesn't match. Are you talking about some hybrid between a RS and a NS which other routers can respond to immediately? Or are you just trying to solve the case when the link-local address of the router isn't globally unique and that's why you want to add the landmark? We want reasonable behavior both when the host has moved and when it stays on the same link. In the case when it moves, dna-protocol* has explored the optimal solutions (a single RS and a single RA), and unless we have some clue from L2 the RS must be multicast to all-routers. (As Greg pointed out, this doesn't mean it needs to go everywhere.) In the case when a host hasn't moved then (if one already know it didn't move ;-) then a unicast packet can be used to verify this. But given that the host has to work efficiently whether it has moved or not, the choices are hard. We could unicast 3 packets (and wait for 1 second after each) before sending the RS to all-routers. But that means that the case when the host moved now takes 3 more seconds. We could send a RS to all-routers, which is fast in both cases, but causes extra traffic if multicast to all-routers isn't implemented efficiently in the network (MLD snooping?) But there is no middle point: sending the RS to all-routers in parallel with the unicast NS doesn't reduce the multicast traffic. > Another thought I have. When one gets a "link up" event, one wants to > know if one is reattaching to a previously known link. The > pentland-protocol3 draft assumes that the best way do do that is by > including all prefixes in RAs. We've discussed various ways, and I still think that the single landmark is simpler. But handling the case when a most might move between a link with DNA capable routers and a link without such routers (as well as links that have some of each) is tricky. > However, this has the disadvantage that routers have to listen to > other RAs and (effectively) do a proxy advertisement for prefixes it > itself is not advertising. I have some fairly strong qualms about that > approach... Because of the prefixes or something else? These prefixes are only used for DNA; they do not effect the 2461/62 operation. The routers have to keep track of each other in any case to be able to have one of them immediately respond to an all-routers RS. > On the other hand, a lower overhead mechanism would be to be able to > ask "are you the same router on link Foo that I was talking to > previously?" But that approach optimizes only for the case of non-movement. We need a balance that also optimizes for the case of movement. > I'm also a bit worried that one time DNA will get used a lot is at, > say, IETFs where the network is barely functioning. That seems like > the wrong time to have a bunch of nodes invoke DNA at the same time > and all send out multicast RSs... I thought it was the 802.11 associate frames that were problematic on Monday's at the IETF ;-) Seriously, it is hard to optimize for the case of flaky infrastructure (like IETF on Monday morning), and at the same time also optimize for non-movement as well as movement. I think that would be an over-constrained problem. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 13:48:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F95E2-000497-HQ for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 13:48:38 -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 NAA19416 for ; Tue, 14 Feb 2006 13:46:46 -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 <01LYZIYDLNN89C93TX@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 05:48:16 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 67ED280003; Wed, 15 Feb 2006 05:48:12 +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 EDC3D3C00C; Wed, 15 Feb 2006 05:48:11 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1EIlxq02194 for dna-list; Wed, 15 Feb 2006 05:47:59 +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 k1EIlxu02190 for ; Wed, 15 Feb 2006 05:47:59 +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 <01LYZIXS7OIIAW479B@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 05:47:44 +1100 Received: by localhost (Postfix, from userid 510) id DB9C1AB58C; Wed, 15 Feb 2006 05:47:43 +1100 (EST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by moe.its.monash.edu.au (Postfix) with ESMTP id 4D19C4FB07 for ; Wed, 15 Feb 2006 05:47:42 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1EIlaSD000499; Tue, 14 Feb 2006 11:47:40 -0700 (MST) 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 k1EIlZA4779538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2006 10:47:36 -0800 (PST) Date: Tue, 14 Feb 2006 10:46:56 -0800 From: Erik Nordmark Subject: Re: [DNA] when to rerun DAD In-reply-to: <200602131512.k1DFCL8w006081@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <43F225A0.3000802@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: <200602131512.k1DFCL8w006081@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > IMO, we may want to think about having a separate discussion about > "when to run DAD". The blanket "rerun DAD at all times there is some > doubt" strikes me as overkill. For example, why rerun DAD if one has > been disconnected only 10 seconds? or 30? Maybe we should if we've > been disconnected for an hour (but then, do we need to bother with > DNA?). Also, why rerun DAD if one has generated an address using the > IEEE Identifier (and one has run DAD on it before)? That is, different > types of addresses have different "probability of possible collision" > risks in terms of other hosts attempting to use such addresses. There are two things related things in this space, and I think you touch on the one that needs discussion. But for completeness... When DNA receives a link up event, then it doesn't know whether it is re-attaching to the same link or attaching to a different link. Thus it makes sense to be conservative and mark the addresses as optimistic, and send any RS with the TSLLAO option. Should the host determine from the RA that it has moved, then it should proceed with the optimistic DAD logic to send the DAD NS and wait for 1 second. The reason for the above is that if we require that a host do DAD when it powers up the first time due to some feel for the probability of collisions, then moving to a different link has the same probability of collisions. Thus we can revise this part of DNA/DAD interaction *if* we find that the probability of collisions is different in the non-DNA case of powering up the device. The case (which I think is what you have above) of reconnecting to the same link is actually tricker, and is part of the (wireless) continuing from low packet loss to high packet loss and then loosing the attachment to the link. But independently of how long such an outage is, and whether we take packet loss percentage into account or not, we can do a first order approximation that other hosts (with potentially conflicting addresses) are unlikely to arrive at the link and do their DAD while the host doesn't receive the DAD probes. (This is different than in the movement case, when there might be a very large population of hosts on the new link, any one of which could have a duplicate.) Thus I think the time, when re-attaching to a different link, that needs to pass before the host should send a new DAD probe can be longer than 1 second. I wonder if we could benefit from some practical experiments (e.g., on 802.11) for how long it takes from the host seeing 100% packet loss until it declares the link down. If this time is commonly 10-30 seconds with current implementations we presumably need to take this into account. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 14:10:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F95ZH-0002R2-EF for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 14:10:31 -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 OAA20478 for ; Tue, 14 Feb 2006 14:08:43 -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 <01LYZJO39O6CAZUBFT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 06:09:07 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 494EFAB542; Wed, 15 Feb 2006 06:08:56 +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 056144FB2A; Wed, 15 Feb 2006 06:08:56 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1EJ6IM02393 for dna-list; Wed, 15 Feb 2006 06:06:18 +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 k1EJ6Hu02389 for ; Wed, 15 Feb 2006 06:06:17 +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 <01LYZJKIF7U2AZUBFS@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 06:06:03 +1100 Received: by localhost (Postfix, from userid 510) id 541ADAB542; Wed, 15 Feb 2006 06:06:03 +1100 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by curly.its.monash.edu.au (Postfix) with ESMTP id C11504FB1C for ; Wed, 15 Feb 2006 06:06:01 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.106.105]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1EJ60dK025314; Tue, 14 Feb 2006 11:06:00 -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 k1EJ5sAM786090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2006 11:05:56 -0800 (PST) Date: Tue, 14 Feb 2006 11:05:14 -0800 From: Erik Nordmark Subject: Re: [DNA] how much effort to deal with "unplanned renumbering" In-reply-to: <200602131516.k1DFGKK9006254@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <43F229EA.7070806@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: <200602131516.k1DFGKK9006254@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > I think we need to think hard about how much we are going to > complicate DNA to deal with "broken renumbering attempts", which are > not supposed to happen in the first place. The IPv6 protocols do not > really support taking away a prefix prematurely, and when this > happens, things aren't guarnteed to work. Thus, this is not advisable > in general. > > So we should explicitely discuss to what degree DNA needs to support > such events, especially if they are not expected to be common. Do read what dna-protocol3 proposes. But this is actually a case where DNA potentially could make things a lot worse if we didn't do anything, because DNAv6 relies on prefixes comparisons, which means it uses the prefix lifetimes *even though it is not connected to the link*. (And DNAv4 doesn't rely on prefix comparisons - it just reverifies things with the DHCP server - so it doesn't have this issue AFAIK.) Without DNA one can do reasonable flash renumbering. Assume the prefix is advertised with the default 7/30 day preferred/valid lifetimes. Somebody decides that the prefix needs to be forcibly removed from the link. Starts advertising the prefix with 0/o preferred/valid lifetimes in every RA. All the hosts will notice this - and if the prefix continues to be advertised with zero lifetimes for 30 days then even hosts that were dormant will never be confused. Such an event will be disruptive, because some connections will die, if not immediately then after the 2 hour limit in RFC 2462. Thus there might be emergency cases when this will be done. It might also be possible that somebody decides to immediately reassign that prefix to another link, and we should recommend that this is bad operational practice. But it might happen with any additional harm. Enter DNA. It is possible (but very unlikely) that a host would move from link A (which has prefix P1, P2) to link B (with prefix P3) at the same time as - P1 is forcibly removed from link A, and P1 is reassigned to link B If we didn't do anything, then the host would be confused for 30 days, because it would think - it didn't move to a different link because it hears P1 after reattaching - the prefixes assigned to the link are P1, P2, and P3 Thus the host will continue to use it's address in the P2 prefix, which will not work. The above description is longer than the fix; dna-protocol3 says to not use information that is older than 1.5 hours. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 14:11:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F95a2-0002Wp-35 for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 14:11:18 -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 OAA20525 for ; Tue, 14 Feb 2006 14:09:30 -0500 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LYZJPO7OQ4AZUBFT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 06:10:20 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D801980004; Wed, 15 Feb 2006 06:10:12 +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 8A7AF3C003; Wed, 15 Feb 2006 06:10:12 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1EJABq02465 for dna-list; Wed, 15 Feb 2006 06:10:11 +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 k1EJAAu02461 for ; Wed, 15 Feb 2006 06:10:10 +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 <01LYZJPB8RS89AVYTW@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 06:09:55 +1100 Received: by localhost (Postfix, from userid 510) id 8A4C2AB58C; Wed, 15 Feb 2006 06:09:55 +1100 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by moe.its.monash.edu.au (Postfix) with ESMTP id 550D44FB03 for ; Wed, 15 Feb 2006 06:09:54 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1EJ9rdK029573; Tue, 14 Feb 2006 11:09:53 -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 k1EJ9qbg787841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2006 11:09:52 -0800 (PST) Date: Tue, 14 Feb 2006 11:09:13 -0800 From: Erik Nordmark Subject: Re: [DNA] Alternatives to "just send RS" when DNA starts In-reply-to: <200602131520.k1DFKTKi006272@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <43F22AD9.4010403@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: <200602131520.k1DFKTKi006272@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7BIT Thomas Narten wrote: > But one can also imagine parallel approaches. E.g, for the default > routers on the list, measure the actual observed RTTs during NS/NA > exchanges. Then, for DNA, send out an NS, using that RTT as an > estimate of how long you are willing to wait (and I'd expect this to > be very short, like 10ms or less). If that doesn't work, then fall > back to RS. One can imagine other optimizations. Yes, but that one clearly doesn't satisfy the Monday morning IETF criteria. I think I saw rtt's to the router fluctuate a lot in Vancouver; up to several seconds. If that's the case, we'd see more packets with this "optimization" - first some unicast NSs from each host then a RS to all-routers. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 17:34:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F98kb-0002EI-PI for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 17:34:25 -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 RAA08657 for ; Tue, 14 Feb 2006 17:32:39 -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 <01LYZQT3WDSUAZUCGX@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 09:33:20 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C24EAB545; Wed, 15 Feb 2006 09:33:01 +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 E620D4FB21; Wed, 15 Feb 2006 09:33:00 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1EMVlx04284 for dna-list; Wed, 15 Feb 2006 09:31:47 +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 k1EMVku04280 for ; Wed, 15 Feb 2006 09:31:46 +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 <01LYZQRHIR7M9C8T25@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 09:31:43 +1100 Received: by localhost (Postfix, from userid 510) id 21332AB543; Wed, 15 Feb 2006 09:31:43 +1100 (EST) Received: from hotmail.com (bay106-f27.bay106.hotmail.com [65.54.161.37]) by curly.its.monash.edu.au (Postfix) with ESMTP id 4FF124FB21 for ; Wed, 15 Feb 2006 09:31:42 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 Feb 2006 14:31:41 -0800 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 14 Feb 2006 22:31:40 +0000 (GMT) Date: Tue, 14 Feb 2006 14:31:40 -0800 From: Bernard Aboba Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: <43F21A41.3050502@sun.com> X-Originating-IP: [131.107.0.87] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: erik.nordmark@sun.com Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 14 Feb 2006 22:31:41.0083 (UTC) FILETIME=[6D196EB0:01C631B6] Content-Transfer-Encoding: 7BIT >Does this work if you have a router which > - uses the same IEEE 802 MAC address on multiple ports (which is >compliant with the IEEE specifications AFAIK) Using the same IEEE 802 MAC address on multiple router ports will cause problems with VLAN learning operation (e.g. same MAC address would be in multiple VLANs so the interface will receive traffic on VLANs it doesn't belong to), so this is not a good idea (which is why routers or bridges do not do this). >In that case you'd get an ARP response even though the host had moved to a >different link. This wouldn't cause a problem because DHCP runs in parallel and if a different address were assigned it would over-ride. From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 17:43:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F98tZ-0006pP-5p for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 17:43:41 -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 RAA09034 for ; Tue, 14 Feb 2006 17:41:54 -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 <01LYZR43CIHCAZUCHP@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 09:42:00 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D08CAAB58D; Wed, 15 Feb 2006 09:41:52 +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 6C70E4FB11; Wed, 15 Feb 2006 09:41:52 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1EMflT04431 for dna-list; Wed, 15 Feb 2006 09:41:47 +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 k1EMfku04427 for ; Wed, 15 Feb 2006 09:41:46 +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 <01LYZR3SVRRGAW47QM@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 09:41:39 +1100 Received: by localhost (Postfix, from userid 510) id E23BAAB544; Wed, 15 Feb 2006 09:41:38 +1100 (EST) Received: from hotmail.com (bay106-f13.bay106.hotmail.com [65.54.161.23]) by curly.its.monash.edu.au (Postfix) with ESMTP id 346E24FB03 for ; Wed, 15 Feb 2006 09:41:38 +1100 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 Feb 2006 14:41:36 -0800 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Tue, 14 Feb 2006 22:41:36 +0000 (GMT) Date: Tue, 14 Feb 2006 14:41:36 -0800 From: Bernard Aboba Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: <43F220F7.3000602@sun.com> X-Originating-IP: [131.107.0.87] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: erik.nordmark@sun.com, narten@us.ibm.com Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 14 Feb 2006 22:41:36.0850 (UTC) FILETIME=[D0344320:01C631B7] Content-Transfer-Encoding: 7BIT >But there is no middle point: sending the RS to all-routers in parallel >with the unicast NS doesn't reduce the multicast traffic. I don't think the issue is multicast traffic reduction per se. The issue is the *timing* of multicast traffic. To avoid multicast storms it is necessary for multicast to involve delays and backoffs. Sending both NS and RS in parallel would remove potential ambiguities while not requiring that multicast RS be sent *immediately* as has been proposed, which would create severe scaling problems in the event of a power failure. >But that approach optimizes only for the case of non-movement. We need a >balance that also optimizes for the case of movement. Actually, I'd argue that the important thing is to make sure that performance is not impacted negatively in any scenario. Since DNA is an optimization, it is not useful unless it actually improves performance. >I thought it was the 802.11 associate frames that were problematic on >Monday's at the IETF ;-) Actually, IETF 802.11 usage shows evidence of congestive collapse due to inappropriate rate negotiation behavior. That kind of problem can be made considerably worse by multicast traffic without appropriate jittering and backoff. >Seriously, it is hard to optimize for the case of flaky infrastructure >(like IETF on Monday morning), and at the same time also optimize for >non-movement as well as movement. I believe that the effects we see at the IETF are real and occur regularly in high density 802.11 environments. They are not anomalies, since they show up in test environments regardless of the equipment that was being used. From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 18:51:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F99wx-0007SW-KV for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 18:51:15 -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 SAA12870 for ; Tue, 14 Feb 2006 18:49:28 -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 <01LYZT5XO55CAZUD1Y@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 10:40:58 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F1DBAAB542; Wed, 15 Feb 2006 10:40:37 +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 9C0084FB03; Wed, 15 Feb 2006 10:40:37 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1ENdn004994 for dna-list; Wed, 15 Feb 2006 10:39:49 +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 k1ENdnu04990 for ; Wed, 15 Feb 2006 10:39:49 +1100 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 <01LYZT4O15T69C9BI0@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 10:39:36 +1100 Received: by localhost (Postfix, from userid 510) id C078F80006; Wed, 15 Feb 2006 10:39:36 +1100 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by larry.its.monash.edu.au (Postfix) with ESMTP id 554613C007 for ; Wed, 15 Feb 2006 10:39:35 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.224.130]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k1ENdX4u010176; Tue, 14 Feb 2006 15:39:33 -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 k1ENdW5b878462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2006 15:39:33 -0800 (PST) Date: Tue, 14 Feb 2006 15:38:52 -0800 From: Erik Nordmark Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43F26A0C.8000104@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: Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: > Using the same IEEE 802 MAC address on multiple router ports will cause > problems with VLAN learning operation (e.g. same MAC address would be in > multiple VLANs so the interface will receive traffic on VLANs it doesn't > belong to), so this is not a good idea (which is why routers or bridges > do not do this). That might be a problem on the bridges themselves, but it can't be true for hosts attaching to those VLANs because if it was, we'd have a serious security problem. (Where a host which is on VLAN x can disrupt packet flow on VLAN y by choosing the source MAC address to be the same.) Come to think of it, this might have been part of the security bugs in the pre-standard VLAN bridges that some vendors shipped. >> In that case you'd get an ARP response even though the host had moved >> to a different link. > > This wouldn't cause a problem because DHCP runs in parallel and if a > different address were assigned it would over-ride. Correct for DNAv4. But for DNAv6 we have no all-knowing entity like a DHCP server which can verify the addresses; we have to cope with what the RFC 2461 conformant routers will hand us. Erik From dna-owner@webcamserver.eng.monash.edu.au Tue Feb 14 19:07:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9AD8-0004XS-4k for dna-archive@megatron.ietf.org; Tue, 14 Feb 2006 19:07:58 -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 TAA16423 for ; Tue, 14 Feb 2006 19:06:10 -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 <01LYZU2TYKBMAW48F3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 15 Feb 2006 11:06:40 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 664C3AB58D; Wed, 15 Feb 2006 11:06:22 +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 1E44B4FB03; Wed, 15 Feb 2006 11:06:22 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1F068A05311 for dna-list; Wed, 15 Feb 2006 11:06:08 +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 k1F068u05307 for ; Wed, 15 Feb 2006 11:06:08 +1100 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 <01LYZU2J1F6M9C9KIX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 15 Feb 2006 11:06:08 +1100 Received: by localhost (Postfix, from userid 510) id BBA0F80002; Wed, 15 Feb 2006 11:06:07 +1100 (EST) Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by larry.its.monash.edu.au (Postfix) with ESMTP id 0F45D3C012 for ; Wed, 15 Feb 2006 11:06:05 +1100 (EST) Received: from jurassic.eng.sun.com ([129.146.68.130]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k1F064xZ019391; Tue, 14 Feb 2006 16:06:04 -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 k1F061Nb886396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2006 16:06:02 -0800 (PST) Date: Tue, 14 Feb 2006 16:05:22 -0800 From: Erik Nordmark Subject: Re: [DNA] High-level overview of DNA, take 2 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: narten@us.ibm.com, dna@eng.monash.edu.au Message-id: <43F27042.9050702@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: Content-Transfer-Encoding: 7BIT Bernard Aboba wrote: >> But there is no middle point: sending the RS to all-routers in >> parallel with the unicast NS doesn't reduce the multicast traffic. > > I don't think the issue is multicast traffic reduction per se. The > issue is the *timing* of multicast traffic. To avoid multicast storms > it is necessary for multicast to involve delays and backoffs. Sending > both NS and RS in parallel would remove potential ambiguities while not > requiring that multicast RS be sent *immediately* as has been proposed, > which would create severe scaling problems in the event of a power failure. Are you assuming that some event would cause N stations to try to multicast at the same time? (Recall, this is a single multicast packet and not somebody streaming UDP video over multicast.) How does DNAv4 handle this? The draft says to do the ARP validation and DHCPREQUEST in parallel, and explicitly says to broadcast the DHCPREQUEST. Seems like DNAv4 as specified has as much of a problem with broadcast/multicast load... >> But that approach optimizes only for the case of non-movement. We need >> a balance that also optimizes for the case of movement. > > Actually, I'd argue that the important thing is to make sure that > performance is not impacted negatively in any scenario. Since DNA is an > optimization, it is not useful unless it actually improves performance. But in the above case you are saying that we can detect non-movement in a roundtrip time (the NS/NA exchange), but that detecting movement requires some random delay (how much? how much will VoIP cope with?) plus a RS/RA exchange. I don't think such an approach satisfies the DNA goals (RFC 4135). FWIW that document does not say that we should avoid using multicast; if multicast is so evil we should have had that discussion from the start instead of in the 11th hour. And as I said elsewhere, there is plenty of network technology where multicast is expensive (.15.4 .16) but is expensive even for the RS when the device boots. So the multicast avoidance issue isn't specific to DNA. >> Seriously, it is hard to optimize for the case of flaky infrastructure >> (like IETF on Monday morning), and at the same time also optimize for >> non-movement as well as movement. > > I believe that the effects we see at the IETF are real and occur > regularly in high density 802.11 environments. They are not anomalies, > since they show up in test environments regardless of the equipment that > was being used. Yes, but *Monday morning* at IETF is a bit special, since it is often in a place that hasn't seen that density deployment before. Thus it is quite a bit different ramp-up than some hotspot that sees a lot of traffic, because of the arrival rate in a completely new infrastructure. The rest of the week is more normal, with the usual plethora of operating systems that try to be too helpful to automagically switching to ad-hoc mode (and in some cases using the same ESSID as before they lost the AP. ;-) Erik From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 16 05:21:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9gG9-00058q-1G for dna-archive@megatron.ietf.org; Thu, 16 Feb 2006 05:21:13 -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 FAA07529 for ; Thu, 16 Feb 2006 05:19:25 -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 <01LZ1TSBYFHKAZUPZP@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 16 Feb 2006 21:20:26 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2B41EAB543; Thu, 16 Feb 2006 21:20:16 +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 CC5914FB31; Thu, 16 Feb 2006 21:20:15 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1GAI0225196 for dna-list; Thu, 16 Feb 2006 21:18:00 +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 k1GAHxu25192 for ; Thu, 16 Feb 2006 21:17:59 +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 <01LZ1TPAR29C9C9DES@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 16 Feb 2006 21:17:49 +1100 Received: by localhost (Postfix, from userid 510) id C9C76AB543; Thu, 16 Feb 2006 21:17:49 +1100 (EST) Received: from [192.168.1.101] (cust1648.vic01.dataco.com.au [202.63.56.112]) (user brett) (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 059264FB08; Thu, 16 Feb 2006 21:17:48 +1100 (EST) Date: Thu, 16 Feb 2006 21:18:00 +1100 From: Brett Pentland Subject: [DNA] Updates to dna-protocol3 Sender: owner-dna@ecselists.eng.monash.edu.au Approved: monash-smtp-auth To: Dna Message-id: <43F45158.5010504@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) Content-Transfer-Encoding: 7BIT Before submitting the draft to become draft-ietf-dna-protocol-00.txt I have some updates to reflect the feedback that we've had so far. The update can be viewed at: http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00.txt And a diff from protocol3 can be seen at: http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00-from-draft-pentland-dna-protocol3-00.diff.html Does anyone have any objections to the amendments made so far? Do they break anything? Positive ACKs are ok too. :) There's a few issues that have come up while making the edits. They don't necessarily have to be resolved before submission of the -00, but some input would be useful. - Should the explicit linkid always be in the LPO or can it be a flag in a PIO (the latter is in the draft)? - What order do the hosts treat the indications (land mark option, prefixes, linkid in the draft at present) - Given that we now have an explicit linkid, should we get rid of all of the flags in the landmark option - the no flag is not really needed and since taking that out would leave only one, we can probably get rid of that as well - LO in RA = yes (at present the flags are still there) Regards, Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Feb 16 16:21:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9qYr-0007mZ-3y for dna-archive@megatron.ietf.org; Thu, 16 Feb 2006 16:21:13 -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 QAA11002 for ; Thu, 16 Feb 2006 16:19:23 -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 <01LZ2GTWE4NI9C9FHZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 17 Feb 2006 08:19:44 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7C18A80004; Fri, 17 Feb 2006 08:19:42 +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 16BC13C007; Fri, 17 Feb 2006 08:19:42 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1GLIki31802 for dna-list; Fri, 17 Feb 2006 08:18:46 +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 k1GLIju31798 for ; Fri, 17 Feb 2006 08:18:45 +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 <01LZ2GSNB2DUAZUS9V@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 17 Feb 2006 08:18:42 +1100 Received: by localhost (Postfix, from userid 510) id 0FD4180002; Fri, 17 Feb 2006 08:18:42 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 12D2B3C00D; Fri, 17 Feb 2006 08:18:40 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k1GLIdXC011003; Thu, 16 Feb 2006 16:18:39 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 07D203C8173; Thu, 16 Feb 2006 16:18:10 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id E76CD3C816A; Thu, 16 Feb 2006 16:18:09 -0500 (EST) Date: Thu, 16 Feb 2006 16:18:36 -0500 From: Greg Daley Subject: Re: [DNA] Updates to dna-protocol3 In-reply-to: <43F45158.5010504@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Dna Message-id: <43F4EC2C.1060600@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:7.59132 C:13 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <43F45158.5010504@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Hi Brett, Thanks for the changes. Brett Pentland wrote: > Before submitting the draft to become draft-ietf-dna-protocol-00.txt I > have some updates to reflect the feedback that we've had so far. The > update can be viewed at: > > http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00.txt > > And a diff from protocol3 can be seen at: > > http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00-from-draft-pentland-dna-protocol3-00.diff.html > > > Does anyone have any objections to the amendments made so far? Do they > break anything? Positive ACKs are ok too. :) > > There's a few issues that have come up while making the edits. They > don't necessarily have to be resolved before submission of the -00, but > some input would be useful. > > - Should the explicit linkid always be in the LPO or can it be a flag in > a PIO (the latter is in the draft)? It is a significant (16 octet) cost saving to make use of a flag in the PIO to explicitly mark a link identifier. The processing is more complicated in that PIOs and Landmark options have to be checked until the identifier is found. This per prefix processing is required if there's no identifier (using CPL) though, so that's not a major problem. > - What order do the hosts treat the indications (land mark option, > prefixes, linkid in the draft at present) I'd be interested in finding out what others think. My personal thought was that the completeRA flag trumps all. > - Given that we now have an explicit linkid, should we get rid of all of > the flags in the landmark option - the no flag is not really needed > and since taking that out would leave only one, we can probably get > rid of that as well - LO in RA = yes (at present the flags are still > there) it doesn't make the option any smaller to remove. perhaps we can leave it for future extension? Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Feb 17 10:59:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA80w-00055o-OV for dna-archive@megatron.ietf.org; Fri, 17 Feb 2006 10:59:22 -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 KAA03449 for ; Fri, 17 Feb 2006 10:57:29 -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 <01LZ3JUKYDMS9C9S0K@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 18 Feb 2006 02:57:23 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 60D29AB543; Sat, 18 Feb 2006 02:57:20 +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 F183C4FB17; Sat, 18 Feb 2006 02:57:19 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1HFtJ510130 for dna-list; Sat, 18 Feb 2006 02:55:19 +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 k1HFtIu10126 for ; Sat, 18 Feb 2006 02:55:18 +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 <01LZ3JRS0V22AW4H9F@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 18 Feb 2006 02:55:05 +1100 Received: by localhost (Postfix, from userid 510) id E2BD4AB543; Sat, 18 Feb 2006 02:55:04 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by curly.its.monash.edu.au (Postfix) with ESMTP id 57C904FB03; Sat, 18 Feb 2006 02:55:03 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k1HFt0Ku014650; Fri, 17 Feb 2006 10:55:00 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id BA0D13C821A; Fri, 17 Feb 2006 10:51:55 -0500 (EST) Received: from [150.169.1.185] (unknown [150.169.1.185]) by redwood.research.panasonic.com (Postfix) with ESMTP id AAB623C8219; Fri, 17 Feb 2006 10:51:55 -0500 (EST) Date: Fri, 17 Feb 2006 10:51:34 -0500 From: Sathya Narayanan Subject: Re: [DNA] Updates to dna-protocol3 In-reply-to: <43F45158.5010504@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: Dna Message-id: <43F5F106.2050901@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:18 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) References: <43F45158.5010504@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Brett - I sent the following email to you last week (02/08). I don't know if you received it. Please see below. thanks, Sathya -------------------------------------------------------------------------------------------------------- Brett - Atlast, I got to look at the DNA soln. draft. I have the following questions/comments: Comment 1) The solicited router advertisement case as is written now seems to me as follows as: - SHOULD do completeRA (MUST include LindID even if complete RA is not possible due to length of the packet). - MAY do landmark response if the RS contains landmark question { - LinkID is not needed for "Y" response - LinkID MUST be present in "N" response with as many of the prefixes as possible (if all prefixes included then set the Complete bit). } Is this the intended recommendation? My understanding was, If landmark question in RS { SHOULD Send landmark response - LinkID is not needed for "Y" response - LinkID MUST be present in "N" response with as many of the prefixes as possible (if all prefixes included then set the Complete bit). } else SHOULD do completeRA (MUST include LinkID even if complete RA is not possible due to length of the packet). Am I missing something? (or starting the debate all over again? - my apologies if I am :-) ). I can do the changes if necessary. Comment 2) I think it makes sense to change the terminology from 'LinkID prefix' to just 'LinkID' in the text to keep it clean in terms of future compatibility as discussed in 5.1.7.1.1. Section 5.1.7 can be LinkID and the text will describe how a prefix should be selected as the LinkID. I think this will reduce any confusions. Comment 3) For host operations, Section 5.2.5: Processing Router Advertisments The conditions should be classified into two subsets, one if the 'F' bit is set and another if the 'F' bit is not set. The last condition starting "If the received RA is not complete, contains no prefixes ..." should be replaced with just the condition "If the 'F' bit is not set" and the all the other conditions before are under "If the 'F' bit is set". Comment 4) Minor changes: Section 4.1: s/flag bit/bit I couldn't understand section 5.1.10 (this is not so minor :-) ) Section 5.2.5.1: has few lower case shoulds, may be they MUST be changed to SHOULDs. I can do the changes if you ok them. thanks, Sathya > Before submitting the draft to become draft-ietf-dna-protocol-00.txt I > have some updates to reflect the feedback that we've had so far. The > update can be viewed at: > > http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00.txt > > And a diff from protocol3 can be seen at: > > http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-pre00-from-draft-pentland-dna-protocol3-00.diff.html > > > Does anyone have any objections to the amendments made so far? Do they > break anything? Positive ACKs are ok too. :) > > There's a few issues that have come up while making the edits. They > don't necessarily have to be resolved before submission of the -00, but > some input would be useful. > > - Should the explicit linkid always be in the LPO or can it be a flag in > a PIO (the latter is in the draft)? > > - What order do the hosts treat the indications (land mark option, > prefixes, linkid in the draft at present) > > - Given that we now have an explicit linkid, should we get rid of all of > the flags in the landmark option - the no flag is not really needed > and since taking that out would leave only one, we can probably get > rid of that as well - LO in RA = yes (at present the flags are still > there) > > Regards, > Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 20 06:14:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB8zX-0001zb-Ls for dna-archive@lists.ietf.org; Mon, 20 Feb 2006 06:14:07 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB8zU-00035J-3H for dna-archive@lists.ietf.org; Mon, 20 Feb 2006 06:14:07 -0500 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 <01LZ7GS30OD29ARM11@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 20 Feb 2006 22:12:16 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3619C80002; Mon, 20 Feb 2006 22:12:12 +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 CD4223C012; Mon, 20 Feb 2006 22:12:10 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1KBAIF18639 for dna-list; Mon, 20 Feb 2006 22:10:18 +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 k1KBAHu18635 for ; Mon, 20 Feb 2006 22:10:17 +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 <01LZ7GPE2LDQAZVKTU@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 20 Feb 2006 22:10:02 +1100 Received: by localhost (Postfix, from userid 510) id 00033AB58C; Mon, 20 Feb 2006 22:10:01 +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 D5F1C4FB46 for ; Mon, 20 Feb 2006 22:09:58 +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 1FB8vO-0008ST-TT; Mon, 20 Feb 2006 12:09:54 +0100 Received: from [129.13.219.108] (vpn-cl-165-207.rz.uni-karlsruhe.de [141.3.165.207]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 8052DA52B; Mon, 20 Feb 2006 12:09:50 +0100 (CET) Date: Mon, 20 Feb 2006 12:09:43 +0100 From: Christian Vogt Subject: Re: [DNA] Alternatives to "just send RS" when DNA starts In-reply-to: <43F0B767.802@research.panasonic.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Thomas Narten Cc: JinHyeock Choi , dna@eng.monash.edu.au Message-id: <43F9A377.4020300@tm.uka.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: de-DE, de, en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Spam-Level: X-Enigmail-Version: 0.92.0.0 References: <200602131520.k1DFKTKi006272@cichlid.raleigh.ibm.com> <43F0B767.802@research.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Hi Thomas, hi Greg. >>> I think 2461bis allows an immideate RS for mobile nodes. >> >> Can you cite text? And I hope they don't make an exception just for >> "mobile nodes". > > > > S6.3.7 draft-ietf-ipv6-2461bis-05.txt > > In some cases, the random delay MAY be omitted if necessary. For > instance, a mobile node, using [MIPv6], moving to a new link would > need to discover such movement as soon as possible to minimize the > amount of packet losses resulting from the change in its topological > movement. Router Solicitations provide a useful tool for movement > detection in Mobile IPv6 as they allow mobile nodes to determine > movement to new links. Hence, if a mobile node received link layer > information indicating that movement might have taken place, it MAY > send a Router Solicitation immediately, without random delays. The > strength of such indications should be assessed by the mobile node's > implementation depending on the level of certainty of the link layer > hints and is outside the scope of this specification. Note that using > this mechanism inappropriately (e.g. based on weak or transient > indications) may result in Router Solicitation storms. Furthermore, > simultaneous mobility of a large number of mobile nodes that use this > mechanism can result in a large number of solicitations sent > simultaneously. Unfortunately, there is some inconsistency with respect to exceptions for "mobile nodes" in RFC2461/2462bis. Specifically, mobile nodes should still wait for up to 1 second before they send an MLD Report message prior to DAD. RFC2462bis specifies this in section 5.4.2: If the Neighbor Solicitation is going to be the first message to be sent from an interface after interface (re)initialization, the node SHOULD delay joining the solicited-node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in [I-D.ietf-ipv6-2461bis]. This serves to alleviate congestion when many nodes start up on the link at the same time, such as after a power failure, and may help to avoid race conditions when more than one node is trying to solicit for the same address at the same time. Even if the Neighbor Solicitation is not going to be the first message to be sent, the node SHOULD delay joining the solicited-node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY if the address being checked is configured by a router advertisement message sent to a multicast address. The delay will avoid similar congestion when multiple nodes are going to configure addresses by receiving the same single multicast router advertisement. There was quite a long discussion about this on the IPv6 mailing list [1]. The conclusion was eventually to leave "real" mobility optimizations to DNA. Regards, - Christian [1] "Comment on RFCs 2461bis and 2462bis", http://www1.ietf.org/mail-archive/web/ipv6/current/msg05084.html -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Greg Daley wrote: > Hi Thomas, > > Thomas Narten wrote: > >> JinHyeock Choi writes: >> >> >>>> 2) Upon "link up", does DNA need to delay sending an RS per the >>>> 2461/2462 rule? Are there ways to relax this that are >>>> consistent with the original concerns that led to the existing >>>> wording in 2461/2462? >> >>> I think 2461bis allows an immideate RS for mobile nodes. >> >> Can you cite text? And I hope they don't make an exception just for >> "mobile nodes". > > > > S6.3.7 draft-ietf-ipv6-2461bis-05.txt > > In some cases, the random delay MAY be omitted if necessary. For > instance, a mobile node, using [MIPv6], moving to a new link would > need to discover such movement as soon as possible to minimize the > amount of packet losses resulting from the change in its topological > movement. Router Solicitations provide a useful tool for movement > detection in Mobile IPv6 as they allow mobile nodes to determine > movement to new links. Hence, if a mobile node received link layer > information indicating that movement might have taken place, it MAY > send a Router Solicitation immediately, without random delays. The > strength of such indications should be assessed by the mobile node's > implementation depending on the level of certainty of the link layer > hints and is outside the scope of this specification. Note that using > this mechanism inappropriately (e.g. based on weak or transient > indications) may result in Router Solicitation storms. Furthermore, > simultaneous mobility of a large number of mobile nodes that use this > mechanism can result in a large number of solicitations sent > simultaneously. > > > [cut] > >>> In case a host moves to a new link, it needs an RA for new >>> configuration anyway, so it seems reasonable to send RS in >>> anticipation of a link change. Also if you use unicast meessage >>> to known destinations, no reply will come when you have moved to >>> a new link. This will result in delay since you can't but rely on >>> timeout to detect a link change. >> >> But one can also imagine parallel approaches. E.g, for the default >> routers on the list, measure the actual observed RTTs during NS/NA >> exchanges. Then, for DNA, send out an NS, using that RTT as an >> estimate of how long you are willing to wait (and I'd expect this >> to be very short, like 10ms or less). If that doesn't work, then >> fall back to RS. One can imagine other optimizations. >> > > > Such an optimization may work, but its effectiveness is dependent on > topology (single cell links would experience longer delays), and the > amount of time available to upper-layer applications (for example, > voip). > > It makes sense to mention this idea as an optimization to reduce the > effect of multicasts on the link-layer. I'd suggest inclusion of a > tentative link-layer address option, as the source address of the NS > is likely to be considered optimistic for DAD purposes (it may not > help, but may avoid the reverse NS/NA exchange if the router doesn't > have the host in the NCE). > > How about: > > "... Multicast transmission has been shown to increase bandwidth > consumption on certain wireless media at a rate much greater than > that caused by unicast transmission. On such media, it MAY be > useful to send a unicast NS transmission to the global address of one > of the configured routers upon reception of a link-layer hint. This > would avoid transmission of a multicast Router Solicitation if the > router was available. The RS could then be delayed for an interval > corresponding to the duration required to receive the unicast NA, if > the router is still reachable. > > This optimization is dependent on topology, and increases delay and > packet transmission if the link is composed of a single cell. > Additionally, hosts with applications that are not able to delay for > the lost NA in case of link-change SHOULD use RS instead. ..." > > > Sending to the link-local address is insufficient, as some devices > have been known to share a MAC address across different NICs, and > CGAs with common public keys will be the same for two interfaces on > one router, as the link-local prefix and key are the same. > > Actually, if the NS contained a landmark option and the router was a > known DNA router, you could send to any address. > > Greg From dna-owner@webcamserver.eng.monash.edu.au Sat Feb 25 18:30:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8rz-0007Nm-JL for dna-archive@lists.ietf.org; Sat, 25 Feb 2006 18:30:35 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD8ry-0000dU-HG for dna-archive@lists.ietf.org; Sat, 25 Feb 2006 18:30:35 -0500 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 <01LZF60OEC7K9AT3Q1@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 26 Feb 2006 10:30:13 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EDBC180002; Sun, 26 Feb 2006 10:30:06 +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 A7E263C00F; Sun, 26 Feb 2006 10:30:06 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1PNSIA03700 for dna-list; Sun, 26 Feb 2006 10:28:18 +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 k1PNSIu03696 for ; Sun, 26 Feb 2006 10:28:18 +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 <01LZF5X8JCZCAZWXNE@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 26 Feb 2006 10:28:08 +1100 Received: by localhost (Postfix, from userid 510) id 88BB2AB542; Sun, 26 Feb 2006 10:28:07 +1100 (EST) Received: from [192.168.1.101] (cust1648.vic01.dataco.com.au [202.63.56.112]) (user brett) (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 09FD04FB21; Sun, 26 Feb 2006 10:28:05 +1100 (EST) Date: Sun, 26 Feb 2006 10:28:22 +1100 From: Brett Pentland Subject: Re: [DNA] Updates to dna-protocol3 In-reply-to: <43F5F106.2050901@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au Approved: monash-smtp-auth To: Sathya Narayanan Cc: Dna Message-id: <4400E816.5060202@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Spam-Level: References: <43F45158.5010504@eng.monash.edu.au> <43F5F106.2050901@Research.Panasonic.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Hi Sathya, Sathya Narayanan wrote: > Brett - > > I sent the following email to you last week (02/08). I don't know if you > received it. Please see below. > > thanks, > Sathya > -------------------------------------------------------------------------------------------------------- > > Brett - > > Atlast, I got to look at the DNA soln. draft. I have the following > questions/comments: > > Comment 1) > The solicited router advertisement case as is written now seems to me as > follows as: > > - SHOULD do completeRA (MUST include LindID even if complete RA is not > possible due to length of the packet). > - MAY do landmark response if the RS contains landmark question > { > - LinkID is not needed for "Y" response > - LinkID MUST be present in "N" response with as many of > the prefixes as possible (if all prefixes included then set the Complete > bit). > } > > Is this the intended recommendation? > > My understanding was, > > If landmark question in RS > { > SHOULD Send landmark response > - LinkID is not needed for "Y" response > - LinkID MUST be present in "N" response with as many of > the prefixes as possible (if all prefixes included then set the Complete > bit). > } > else > SHOULD do completeRA (MUST include LinkID even if complete RA is not > possible due to length of the packet). > > Am I missing something? (or starting the debate all over again? - my > apologies if I am :-) ). I can do the changes if necessary. The former is what's in draft-pentland-dna-protocol3-00.txt I don't remember actually having any debate on that point. :) The way it's written was an attempt to make the specification simple to follow while integrating the three identification methods: base the solution around completeRA but allow the RA size to be reduced in certain circumstances. The landmark yes response can be quite a good saving, so the sense that you have described sounds fine. Would simply changing the recommendation for the landmark response from a MAY to a SHOULD suffice? The draft would still first say that the RA SHOULD be a completeRA, but then change 6.1.5.1 from: 6.1.5.1 Space Optimized Advertisements If the Router Solicitation contains a Landmark Option whose prefix is included in DNARouterPrefixList or AdvPrefixList AND the corresponding Router Advertisement will be unicast, the router MAY send an abbreviated Router Advertisement. The abbreviated advertisement includes only the Landmark Option, with the "Y" flag set, plus the base RA header and any SEND options as appropriate. to: 6.1.5.1 Space Optimized Advertisements If the right preconditions are met, it is both possible and desirable to reduce the size of the Router Advertisement by omitting certain prefixes. If the Router Solicitation contains a Landmark Option whose prefix is included in DNARouterPrefixList or AdvPrefixList AND the corresponding Router Advertisement will be unicast, the router SHOULD send an abbreviated Router Advertisement. The abbreviated advertisement includes only the Landmark Option, with the "Y" flag set, plus the base RA header and any SEND options as appropriate. Would that work? > Comment 2) > I think it makes sense to change the terminology from 'LinkID prefix' to > just 'LinkID' in the text to keep it clean in terms of future > compatibility as discussed in 5.1.7.1.1. > Section 5.1.7 can be LinkID and the text will describe how a prefix > should be selected as the LinkID. I think this will reduce any confusions. OK, except for 5.1.10.1 which is specifically referring to the removal of a prefix that happens to be the LinkID. > Comment 3) > For host operations, > Section 5.2.5: Processing Router Advertisments > The conditions should be classified into two subsets, one if the 'F' bit > is set and another if the 'F' bit is not set. > > The last condition starting "If the received RA is not complete, > contains no prefixes ..." should be replaced with just the condition "If > the 'F' bit is not set" and the all the other conditions before are > under "If the 'F' bit is set". Is this for clarity or is something wrong with the current text logically? In either case would you be able to propose text? > Comment 4) > Minor changes: > > Section 4.1: s/flag bit/bit OK. > I couldn't understand section 5.1.10 (this is not so minor :-) ) The intention is that a router removing a prefix early should behave (from a DNA point of view) just like the other routers on the link that weren't explicitly advertising the prefix. They will have heard the prefix from the router and will have it's expiry time set to 1.5 hours after they last heard it, or at the last advertised expiry time, whichever is earlier. If the router does this, then for hosts doing DNA, the prefix disappears from all of the routers on the link at roughly the same time. Actually, the text says for the expiry time to be 1.5 hours from the new RA, but I guess it should really be 1.5 hours from the last time the router sent the prefix in a PIO. Does that make sense? If so, what does the draft need to say to convey that better? > Section 5.2.5.1: has few lower case shoulds, may be they MUST be changed > to SHOULDs. OK. I updated the draft where resolved. Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Sat Feb 25 18:36:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8xk-0002iH-IK for dna-archive@lists.ietf.org; Sat, 25 Feb 2006 18:36:32 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD8xj-0000mC-Ra for dna-archive@lists.ietf.org; Sat, 25 Feb 2006 18:36:32 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LZF67OR9N2AW5SO6@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 26 Feb 2006 10:36:08 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1F8F6AB58D; Sun, 26 Feb 2006 10:35:46 +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 DC3EF4FB05; Sun, 26 Feb 2006 10:35:45 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1PNZed03793 for dna-list; Sun, 26 Feb 2006 10:35:40 +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 k1PNZdu03789 for ; Sun, 26 Feb 2006 10:35:39 +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 <01LZF67AQT3G9CAKC2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 26 Feb 2006 10:35:27 +1100 Received: by localhost (Postfix, from userid 510) id 5149CAB58C; Sun, 26 Feb 2006 10:35:27 +1100 (EST) Received: from [192.168.1.101] (cust1648.vic01.dataco.com.au [202.63.56.112]) (user brett) (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 879034FB0D; Sun, 26 Feb 2006 10:35:26 +1100 (EST) Date: Sun, 26 Feb 2006 10:35:42 +1100 From: Brett Pentland Subject: Re: [DNA] Updates to dna-protocol3 In-reply-to: <43F4EC2C.1060600@research.panasonic.com> Sender: owner-dna@ecselists.eng.monash.edu.au Approved: monash-smtp-auth To: Greg Daley Cc: Dna Message-id: <4400E9CE.4030704@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Spam-Level: References: <43F45158.5010504@eng.monash.edu.au> <43F4EC2C.1060600@research.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi Greg, >> - Should the explicit linkid always be in the LPO or can it be a flag in >> a PIO (the latter is in the draft)? > > It is a significant (16 octet) cost saving to make use of a flag in the > PIO to explicitly mark a link identifier. The processing is more > complicated in that PIOs and Landmark options have to be checked until > the identifier is found. > > This per prefix processing is required if there's no identifier (using > CPL) though, so that's not a major problem. So leave the draft as is? I agree. >> - What order do the hosts treat the indications (land mark option, >> prefixes, linkid in the draft at present) > > I'd be interested in finding out what others think. Me too. > My personal thought was that the completeRA flag trumps all. > >> - Given that we now have an explicit linkid, should we get rid of all of >> the flags in the landmark option - the no flag is not really needed >> and since taking that out would leave only one, we can probably get >> rid of that as well - LO in RA = yes (at present the flags are still >> there) > > it doesn't make the option any smaller to remove. perhaps we can leave > it for future extension? I think it's probably not needed, but don't mind leaving it there. Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Sat Feb 25 18:51:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD9By-0003nV-BW for dna-archive@lists.ietf.org; Sat, 25 Feb 2006 18:51:14 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD9Bw-0000wy-T4 for dna-archive@lists.ietf.org; Sat, 25 Feb 2006 18:51:14 -0500 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 <01LZF6QNHIYC9CB15G@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 26 Feb 2006 10:51:06 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7640CAB604; Sun, 26 Feb 2006 10:51:03 +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 300374FB18; Sun, 26 Feb 2006 10:51:03 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1PNorS04059 for dna-list; Sun, 26 Feb 2006 10:50:53 +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 k1PNoqu04055 for ; Sun, 26 Feb 2006 10:50:52 +1100 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 <01LZF6Q4EICQ9CAJ69@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 26 Feb 2006 10:50:38 +1100 Received: by localhost (Postfix, from userid 510) id E134180004; Sun, 26 Feb 2006 10:50:37 +1100 (EST) Received: from [192.168.1.101] (cust1648.vic01.dataco.com.au [202.63.56.112]) (user brett) (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 447C43C009; Sun, 26 Feb 2006 10:50:32 +1100 (EST) Date: Sun, 26 Feb 2006 10:50:48 +1100 From: Brett Pentland Subject: Re: [DNA] Updates to dna-protocol3 In-reply-to: <4400E816.5060202@eng.monash.edu.au> Sender: owner-dna@ecselists.eng.monash.edu.au Approved: monash-smtp-auth To: Dna Message-id: <4400ED58.9030502@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Spam-Level: References: <43F45158.5010504@eng.monash.edu.au> <43F5F106.2050901@Research.Panasonic.COM> <4400E816.5060202@eng.monash.edu.au> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de The latest changes can be found at: http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-00.txt A diff from the pre00 that's been discussed lately can be seen at: http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-00-from-pre00.diff.html Cheers, Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 27 12:05:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDlnu-0007Jc-4W for dna-archive@lists.ietf.org; Mon, 27 Feb 2006 12:04:58 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDlgD-0001nf-VQ for dna-archive@lists.ietf.org; Mon, 27 Feb 2006 11:57:03 -0500 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 <01LZHKTESD989CB9TF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Feb 2006 03:55:45 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C7D3E80004; Tue, 28 Feb 2006 03:55:43 +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 6AC793C011; Tue, 28 Feb 2006 03:55:43 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1RGs2b28051 for dna-list; Tue, 28 Feb 2006 03:54:02 +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 k1RGs1u28047 for ; Tue, 28 Feb 2006 03:54:01 +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 <01LZHKR175X8AW62X5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Feb 2006 03:53:49 +1100 Received: by localhost (Postfix, from userid 510) id CF9F680005; Tue, 28 Feb 2006 03:53:48 +1100 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4BBDE3C007 for ; Tue, 28 Feb 2006 03:53:47 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k1RGrjMb024834 for ; Mon, 27 Feb 2006 11:53:45 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id E60663C8198 for ; Mon, 27 Feb 2006 11:53:08 -0500 (EST) Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (Postfix) with ESMTP id D4DAE3C816Cfor ; Mon, 27 Feb 2006 11:53:08 -0500 (EST) Date: Mon, 27 Feb 2006 11:53:44 -0500 From: Greg Daley Subject: [DNA] draft-ietf-dna-tentative-00 submitted. Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <44032E98.1050309@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Spam-Level: X-Enigmail-Version: 0.94.0.0 X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:6.87054 C:17 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Dear WG, A draft on tentative options for link layer addresses has been submitted to the Internet Drafts repository Title: Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery Abstract: The proposed IPv6 Duplicate Address Detection (DAD) Optimization "Optimistic DAD" defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Essentially, Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. This document defines a new option and procedures to replace cache polluting options, in a way which is useful to tentative nodes. These procedures are designed to be to backward compatible with existing devices which support IPv6 Neighbour Discovery Until the draft is published, it is available at: http://www.ctie.monash.edu.au/gdaley/draft-ietf-dna-tentative-00.txt Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 27 17:54:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDrG3-0003rY-7U for dna-archive@lists.ietf.org; Mon, 27 Feb 2006 17:54:23 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDpY7-0003zI-UZ for dna-archive@lists.ietf.org; Mon, 27 Feb 2006 16:04:55 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FDpMW-0002ey-GC for dna-archive@lists.ietf.org; Mon, 27 Feb 2006 15:53:01 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LZHT1F3HV0AZXETK@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Feb 2006 07:51:31 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 086DD80003; Tue, 28 Feb 2006 07:51:15 +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 BA9193C00E; Tue, 28 Feb 2006 07:51:14 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1RKoGg30620 for dna-list; Tue, 28 Feb 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 k1RKoGu30616 for ; Tue, 28 Feb 2006 07:50:16 +1100 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 <01LZHT01RLDO9AW4OS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Feb 2006 07:50:08 +1100 Received: by localhost (Postfix, from userid 510) id DDB8980003; Tue, 28 Feb 2006 07:50:08 +1100 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) (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 AC1183C014 for ; Tue, 28 Feb 2006 07:50:05 +1100 (EST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1RKo2vP023731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Feb 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FDpJi-00073o-JV; Mon, 27 Feb 2006 15:50:02 -0500 Date: Mon, 27 Feb 2006 15:50:02 -0500 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-protocol-00.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_3+e2XB+tMPQTPkU/4gvLCQ)" X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Spam-Level: X-Spam-Score: -2.6 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --Boundary_(ID_3+e2XB+tMPQTPkU/4gvLCQ) 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 : Detecting Network Attachment in IPv6 Networks (DNAv6) Author(s) : J. Kempf, et al. Filename : draft-ietf-dna-protocol-00.txt Pages : 34 Date : 2006-2-27 Efficient detection of network attachment in IPv6 needs the following two components: a method for the host to query routers on the link to identify the link (Link Identification) and a method for the routers on the link to consistently respond to such a query with minimal delay (Fast RA). Solving the link identification based strictly on RFC 2461 is difficult because of the flexibility offered to routers in terms of prefixes advertised in a router advertisement (RA) message. Similarly, the random delay in responding to router solicitation messages imposed by RFC 2461 makes to it difficult to receive an RA quickly. In this memo, an integrated solution is presented. Monitoring of prefixes by both hosts and routers is used to achieve link identification while router advertisements are sent rapidly in a deterministic order by combining router solicitation source addresses with hash-based router tokens. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-protocol-00.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-protocol-00.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-protocol-00.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_3+e2XB+tMPQTPkU/4gvLCQ) Content-type: multipart/alternative; boundary="Boundary_(ID_2131syH5hWzwYtjEZSU+eQ)" --Boundary_(ID_2131syH5hWzwYtjEZSU+eQ) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-27144714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-protocol-00.txt --Boundary_(ID_2131syH5hWzwYtjEZSU+eQ) Content-type: Message/External-body; name=draft-ietf-dna-protocol-00.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-protocol-00.txt Content-Type: text/plain Content-ID: <2006-2-27144714.I-D@ietf.org> --Boundary_(ID_2131syH5hWzwYtjEZSU+eQ)-- --Boundary_(ID_3+e2XB+tMPQTPkU/4gvLCQ)-- From dna-owner@webcamserver.eng.monash.edu.au Mon Feb 27 19:00:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsCW-0006iN-BW for dna-archive@lists.ietf.org; Mon, 27 Feb 2006 18:54:49 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDsCU-00005M-NL for dna-archive@lists.ietf.org; Mon, 27 Feb 2006 18:54:47 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LZHZBL7N3AAW5U4U@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 28 Feb 2006 10:51:33 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BA6B6AB60D; Tue, 28 Feb 2006 10:51:14 +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 632144FB46; Tue, 28 Feb 2006 10:51:14 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k1RNoIC32417 for dna-list; Tue, 28 Feb 2006 10:50:18 +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 k1RNoHu32413 for ; Tue, 28 Feb 2006 10:50:17 +1100 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 <01LZHZA72AAO9AVYCX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 28 Feb 2006 10:50:07 +1100 Received: by localhost (Postfix, from userid 510) id 9B01C80003; Tue, 28 Feb 2006 10:50:07 +1100 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) (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 881383C00A for ; Tue, 28 Feb 2006 10:50:05 +1100 (EST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1RNo2BX013760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FDs7u-0005jC-CI; Mon, 27 Feb 2006 18:50:02 -0500 Date: Mon, 27 Feb 2006 18:50:02 -0500 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-tentative-00.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_WkP8bIN3BwyFpg60zc50DA)" X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) X-Spam-Level: X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --Boundary_(ID_WkP8bIN3BwyFpg60zc50DA) 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 : Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery Author(s) : G. Daley, et al. Filename : draft-ietf-dna-tentative-00.txt Pages : 14 Date : 2006-2-27 The proposed IPv6 Duplicate Address Detection (DAD) Optimization "Optimistic DAD" defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Essentially, Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. This document defines a new option and procedures to replace cache polluting options, in a way which is useful to tentative nodes. These procedures are designed to be to backward compatible with existing devices which support IPv6 Neighbour Discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-tentative-00.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-tentative-00.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-tentative-00.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_WkP8bIN3BwyFpg60zc50DA) Content-type: multipart/alternative; boundary="Boundary_(ID_L5OZiq72LiCOdg2cFFWe5g)" --Boundary_(ID_L5OZiq72LiCOdg2cFFWe5g) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-27154835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-tentative-00.txt --Boundary_(ID_L5OZiq72LiCOdg2cFFWe5g) Content-type: Message/External-body; name=draft-ietf-dna-tentative-00.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-tentative-00.txt Content-Type: text/plain Content-ID: <2006-2-27154835.I-D@ietf.org> --Boundary_(ID_L5OZiq72LiCOdg2cFFWe5g)-- --Boundary_(ID_WkP8bIN3BwyFpg60zc50DA)--